Here’s the offending code:
vassalengine.svn.sourceforge.net … threv=3512
If I comment out lines 227-253, the block containing Mac-specific stuff,
it works on my wife’s XP box (she says).
I don’t get it. This code should never run on a Windows machine, so those
classes should never be loaded.
On May 1, 2008, at 4:19 PM, uckelman wrote:
It may be the case that classes referenced will get loaded anyway.
I’m not really up on the details of the class loading part of Java,
but I’m pretty sure the class loader doesn’t wait until run-time to
load the referenced classes. That could lead to some very slow
performance the first time through a new block of code.
I’m pretty sure that is why the sample code on the Apple web site went
through contortions to use the reflection API to access the classes
and build the methods, etc. The whole point was so that there weren’t
any references to the potentially missing classes until runtime. I
suspect that is what will have to happen here.
I’m not quite sure how the construction of the listener is supposed to
work, though.
http://developer.apple.com/samplecode/OSXAdapter/index.html
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake Thomas Russ:
I thought they did that for compilation reasons. We get around the
same problem by including a JAR of stubs for compiling on non-Mac
systems.
Oh, wait—something occurred to me just now, w/r/t conditional
code compilation. There’s a good reason not to use a method for
Info.MacOSX() and instead use a public static final boolean: Nothing
inside an “if (false)” block will be loaded… I’m not sure why
this worked before in other classes, as this isn’t the only place
where the apple.eawt classes are used.
I’ll have to check this out in the morning. Thanks.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake Joel Uckelman:
Windows testers: Try this build:
nomic.net/~uckelman/tmp/vass … indows.exe
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Could not find the main class. Program will exit.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
How about now:
nomic.net/~uckelman/tmp/vass … indows.exe
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake Joel Uckelman:
I think what I said here is not correct. These Mac-specific blocks
aren’t compiled out, because the value of Info.isMacOSX isn’t known
at compile-time.
It perplexes me why the code in MacOSXMenuManager doesn’t also cause
the Windows build to fail to run. Is it because that class is never
loaded?
On the hunch that this is the case, I moved the Mac-specific code
out of ModuleManager and into a subclass of StartUp, so this is
(uperficially) similar to how MacOSXMenuManager is. If I’m right,
the MacOSXStartUp class won’t be loaded on a non-Mac, and so the
problem will be solved.
Are there any rules that the JVM observes w/r/t when to load classes?
If this works, am I just taking advantage of incidental behavior of
this particular JVM, or am I relying on something standard and
documented?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
On May 2, 2008, at 9:19 AM, Joel Uckelman wrote:
There are some rules from the language specification, but they allow a
fair bit of leeway. In particular I found the following at <Java SE Specifications.
“The loading process is implemented by the class ClassLoader and its
subclasses. Different subclasses of ClassLoader may implement
different loading policies. In particular, a class loader may cache
binary representations of classes and interfaces, prefetch them based
on expected usage, or load a group of related classes together. These
activities may not be completely transparent to a running application
if, for example, a newly compiled version of a class is not found
because an older version is cached by a class loader. It is the
responsibility of a class loader, however, to reflect loading errors
only at points in the program they could have arisen without
prefetching or group loading.”
Now this seems to say that the class loader shouldn’t generate errors
through any sort of prefetch or grouped loading, but I’m not sure how
iron-clad that guarantee really is.
There is more detail in the JVM spec, but I must confess that I
haven’t really read this in detail or worked at all with Class Loaders.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Tim McCaron”:
Great. I thought it would.
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Tim McCaron”:
Great. On Saturday, I’ll get the .vsav and .vlog associations working,
and then I think we’ll be ready for 3.1.0-beta1.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake Thomas Russ:
Well, it appears that hiding the Mac-specific stuff in a class which
is never instantiated on non-Macs does the trick. I’m satisfied with
that solution until such time as it stops working.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
As I recall, the Java spec specifically states that if(false) statements don’t get optimized out by the compiler. Can’t remember the justification, though. It’s quite possible that just the ‘import’ statements in a class can cause the referenced classes to be loaded, so wrapping the Mac-specific code in a Mac-specific class is probably going to be the preferred way of doing this kind of thing.
rk
Post generated using Mail2Forum (mail2forum.com)
On May 5, 2008, at 7:56 PM, Rodney Kinney wrote:
Actually, the specification states that an if(false) statement doesn’t
render the statements in that branch of the IF to be “unreachable” –
which is a compile-time error. A compiler is allowed (but not
required) to omit the code for such branches.
The reason for this is because unreachable code is considered a Java
error, and they wanted to preserve the ability to use constant tests
in IF statements for a feature like conditional compilation.
The example from the specification is that
while (false) n = 3;
is an error, since “n = 3” is unreachable, but
if (false) n = 3;
is allowed, since “n = 3” is not treated as unreachable by the
algorithm used to trigger the error.
That sounds like the safe strategy to follow.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)