Closed GoogleCodeExporter closed 9 years ago
Here is some more detailed info about the Java and OS versions, from our
application's log file:
[07:51:55] Java Version : 1.5.0_19
[07:51:55] os name : Mac OS X
[07:51:55] os arch : i386
[07:51:55] os version : 10.4.11
[07:51:55] VM version : 1.5.0_19-138
Original comment by jerith666
on 12 Jan 2010 at 6:30
Here are those same lines for the working .app bundle:
[13:42:49] Java Version : 1.5.0_19
[13:42:49] os name : Mac OS X
[13:42:49] os arch : i386
[13:42:49] os version : 10.4.11
[13:42:49] VM version : 1.5.0_19-138
And for the working webstart on OS X 10.5:
[13:38:48] Java Version : 1.6.0_17
[13:38:48] os name : Mac OS X
[13:38:48] os arch : x86_64
[13:38:48] os version : 10.6.2
[13:38:48] VM version : 14.3-b01-101
Original comment by jerith666
on 12 Jan 2010 at 6:51
That last is clearly OS X 10.6, not 10.5; apologies. This next one is webstart
on OS
X 10.5 with the java preferences changed to use Java 1.5; it still works.
[13:56:38] Java Version : 1.5.0_22
[13:56:38] os name : Mac OS X
[13:56:38] os arch : ppc
[13:56:38] os version : 10.5.8
[13:56:38] VM version : 1.5.0_22-147
Original comment by jerith666
on 12 Jan 2010 at 7:02
Using a remote debugging connection, I have confirmed that the byte array that
URLClassLoader.defineClass(String,Resource) passes in to
URLClassLoader.defineClass(String,byte[],int,int,CodeSource) is 5030 bytes long,
which is about the size of the Finalizer.class in the google collections jar
file.
But the string argument is "com.google.common.base.internal.Finalizer$ShutDown"
(it's
.class file is only 666 bytes in the jar file).
The Resource argument is a URLClassPath$Loader$1. I don't have source for
URLClassPath so I'm not sure exactly what that is, but it has the following
fields
(as visible in the eclipse debugger):
cis, a JarVerifier$VerifierStream
this$0, a URLClassPath$Loader
val$name, a String: "com/google/common/base/internal/Finalizer$ShutDown.class"
val$uc, a JNLPCachedJarURLConnection:
"com.sun.jnlp.JNLPCachedJarURLConnection:jar:http://webstart-qa.carnegielearning
.com/2010/114262/trunk/jars/ct/google-collect.jar!/com/google/common/base/intern
al/Finalizer.class"
val$url, a URL:
"jar:http://webstart-qa.carnegielearning.com/2010/114262/trunk/jars/ct/google-co
llect.jar!/com/google/common/base/internal/Finalizer$ShutDown.class
The val$uc field seems suspicious ...
Original comment by jerith666
on 13 Jan 2010 at 3:56
Sorry -- the connection that I skipped in comment 4 is that the byte array
comes from
a call to Resource.getBytes(). So that's why I'm interested in the Resource.
Original comment by jerith666
on 13 Jan 2010 at 3:58
Here's a debugger screenshot that looks suspicious, too. The Resource discussed
above is created by calling URLClassPath.getResource (in
URLClassLoader.findClass(),
line 192). Looking at that URLClassPath in the debugger, I see that it has a
handler
buried in it that has a reference directly to the Finalizer.class file.
Original comment by jerith666
on 13 Jan 2010 at 4:04
Attachments:
This sounds like a bug in URLClassLoader on your platform. Specifically, it
chokes on
the '$' character and retrieves 'Finalizer.class' instead of
'Finalizer$ShutDown.class'. We
could probably work around the bug by making ShutDown a top-level class.
Original comment by crazybob...@gmail.com
on 13 Jan 2010 at 10:15
Thanks for the suggestion. I've made that change and will report back once our
QA
department has tested it.
Original comment by jerith666
on 18 Jan 2010 at 2:19
No luck. :( Here's the updated stack trace:
java.lang.NoClassDefFoundError: com/google/common/base/internal/ShutDown (wrong
name:
com/google/common/base/internal/Finalizer)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getMethod0(Class.java:2642)
at java.lang.Class.getMethod(Class.java:1579)
at com.google.common.base.FinalizableReferenceQueue.getStartFinalizer(Unknown Source)
at com.google.common.base.FinalizableReferenceQueue.<clinit>(Unknown Source)
at com.google.common.collect.MapMaker$QueueHolder.<clinit>(Unknown Source)
at com.google.common.collect.MapMaker$SoftValueReference.<init>(Unknown Source)
at com.google.common.collect.MapMaker$Strength$2.referenceValue(Unknown Source)
at com.google.common.collect.MapMaker$StrategyImpl.setValue(Unknown Source)
at com.google.common.collect.MapMaker$StrategyImpl.setValue(Unknown Source)
at com.google.common.collect.CustomConcurrentHashMap$Impl$Segment.put(Unknown Source)
at com.google.common.collect.CustomConcurrentHashMap$Impl.put(Unknown Source)
Original comment by jerith666
on 20 Jan 2010 at 1:37
Can you please confirm whether or not this is still occurring?
Original comment by fry@google.com
on 13 Jan 2011 at 8:18
I made the following change to our local copy of Google collections back in
February 2010, and we've since stopped supporting OS X 10.4. So unfortunately
I can't easily test whether it's still happening. :(
Index: trunk/lib/src/com/google/common/base/FinalizableReferenceQueue.java
===================================================================
--- trunk/lib/src/com/google/common/base/FinalizableReferenceQueue.java
(revision 116187)
+++ trunk/lib/src/com/google/common/base/FinalizableReferenceQueue.java
(revision 116188)
@@ -98,7 +98,7 @@
private static final Method startFinalizer;
static {
Class<?> finalizer = loadFinalizer(
- new SystemLoader(), new DecoupledLoader(), new DirectLoader());
+ new SystemLoader() /*new DecoupledLoader()*/, new DirectLoader());
startFinalizer = getStartFinalizer(finalizer);
}
Original comment by jerith666
on 13 Jan 2011 at 8:35
Since this looked like a problem outside of MapMaker, and a workaround has been
found. I'm closing this bug.
Original comment by yrfselrahc@gmail.com
on 13 Jan 2011 at 9:07
Cf. #1505.
Original comment by jgl...@cloudbees.com
on 14 Aug 2013 at 12:52
This issue has been migrated to GitHub.
It can be found at https://github.com/google/guava/issues/<id>
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:16
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:10
Original issue reported on code.google.com by
jerith666
on 12 Jan 2010 at 5:59