RPTools.net

How come he can run b67 on the machine and not b70?

According to the b71 thread, the question came up, "How come the move to Java 5?"

To which Craig responded:



B71 issues aside... The above exchange seems to indicate that b71 was compiled to Java 5... apparently like b67 and those before. Was there, or was there not, a change recently to compile to Java 6 that is causing b70 to fail for pre-Leopard Mac users?

My guess is, given what I've read elsewhere, that since compiling to Java 5 was throwing a bunch of errors that concerned Az, he moved to Java 6. The result of which has left some users behind.

If that's the case, the question still remains: Can a Java5 version be compiled for those people?

As far as I know, he never said it would not run. My take was that he noticed the documentation which said 1.6 is required and that is what prompted his comments.

umm don't know.

Not as far as I know. The current project file is set to compile as 1.5 and has been for as long as I can remember. Unfortunately, it appears that the java compiler does not check the source libraries for binary comparability( and I don't know that I would expect it to) and I don't believe we have the licences to compile all of the libraries used by Maptool which might correct the issue. I think that the problem with String.isEmpty() that somehow slipped into the actual Maptool code a few builds ago(and was then removed) was that Azhrei may have overridden his project file setup to compile under 1.6 instead of 1.5 and he has since reverted I guess. (or perhaps Eclipse has a setting that forces a specific builder for all projects??)

Then what changed between b67 and b70 that causes the newer versions to not work on 1.5 at all whereas the older versions (seemed to|did)?

Are we certain it is the MapTool build that is the issue and not something to do with the the construction of the DMG file? As Joe noted, the MT project specifies Java 1.5 compatibility.

In a quick scan of the included libraries I don't see any that have changed since before the release of b67. This would imply that if MT b67 worked on a Mac with only 1.5 that later versions would as well.

Has the Mac user in question tried running off Webstart or by downloading the zip version and using that?

Ok.. real simple. one of the developers accidentally used a java method that only exists in Java 1.6 in a recent build. This caused someone to have a problem with whatever code part that method was added to. Once the error was tracked down to being due to an incorrect version of Java being used to build, the bad method was removed so all was as it was before. However, Azhrei then checked all of the third party libraries for that same method and found quite a few instances of it being used.

Perhaps the current code just happens to never use certain parts of those libraries at this moment which will cause a problem OR perhaps there is some existing Maptool code that will cause the third party libraries to break under Java 1.5 and it breaks under a very specific set of circumstances. I don't know. What I do know is that those third party libraries are used in TONS of places throughout the Maptool code and there really is no replacement for those libraries that would work under java 1.5 AND be easy to swap in(if they even exist, which I doubt they do).

I just found out that this does not matter. When I first installed Eclipse, it picked up the latest JDK which was java 1.6. I latter installed Java 1.5. So, now, when I check the build properties and check the libraries, it shows it using JRE from 1.6 libraries, so even though we tell the project compatibility to be 1.5, at compile time and design time(where the missing method would have yelled at us in Eclipse if using a 1.5 JRE) it seems to work just fine.


See my previous post on the "issue"

It shouldn't matter if Eclipse is using a 1.6 or even 1.7 JRE. When the project is built and Eclipse issues the javac command it should be including the -target option with 1.5 to make sure the generated class files are compatible with Java 1.5 Note this isn't checking each method to see if it is available in the target version but merely ensures that the class files can be read by Java 1.5.

The end result will be a MT that loads and runs but then crashes when the missing method is hit. The poster is saying it doesn't load at all (at least that is my interpretation).

Off the top of my head I don't know if Eclipse will generate warnings about using methods not supported by the selected target. Given the zillion warnings that Eclipse throws up for the MT project you might never see them if they are there.

Heh. It's amazing that this conversation has lasted this long!

Let me say it one last time: there is no known code in MapTool that requires Java 1.6.

If you skipped over that last sentence, please go back and read it again.

It was postulated that perhaps the .dmg file is the problem. That seems very likely. [time passes] Okay, I just checked the Info.plist file that is inside the app bundle under the Contents directory. It specifies JVMVersion 1.6+ in the XML configuration.

@kkragenbrink: Have your Mac user try editing that file (using TextEdit, for example) and changing the setting to 1.5 and try again.

I didn't build the .dmg but I'm betting that the Apple Xcode application may not support generating a plist file with an older JVMVersion in it. I don't know. The Web Start version specifies Java 1.5 so if that works, perhaps he should use it instead?

At some point you'll need to break the news to your Mac user that the PowerPC chip is dead. In just five short years Apple has introduced three versions of their OS on Intel and another is due soon. That would be like a Windows user still being on Win98 when Win7 comes out.

Will do. Thanks for the suggestion/hopeful fix. They're on vacation right now but I'll let you know if this works when they're back.



Yeah, I completely understand. But I can't force a player to ugprade their entire system just for a bi-weekly D&D game. At some point, I'm sure MT will require 1.6, at which point I will have to stop upgrading.

Thanks for checking that Az!

Not amazing to me. Given that I, too, just recently ran into a user having this problem for the first time (not being able to install b70) and then after seeing what was said in the B71 build thread, and given that there has certainly been indications that some things have been recently changed with how the project was built (to avoid certain errors), it was fairly obvious to people actually experiencing the problem that *something* changed. Only the developers, though, knew exactly what, and while we rely on them to make the best decisions possible we also don't just assume they are infalible.

While you guys couldn't understand from the language that kkragenbrink used that b70 would NOT run on the Mac (all 3 times), I could because of my perspective. In the same manner that a simple, "Nothing has changed since b67" would have been a heck of a lot clearer than the responses he was getting to the issue.

At any rate, it sounds like we're all speaking the same language again, and hopefully Az has nailed down the issue so some dark-age players can continue to game.



No offense, but that statement, like kkragenbrink's use of "hoaked" is about as clear as mud to someone experiencing the problem. It doesn't explain why it doesn't work for people. It just assumes they're all to stupid to understand something that doesn't address the issue so they best read the sentence twice to "get it."



I just want to know when are we going to get backward compatibility for the Amiga. Isn't there a check-box you guys can click to make that happen?

*taps foot impatiently*

Amiga!!!

You made me snort hot coffee!

We could port MT from Java to AREXX and run it on the Amiga. Just think of the cool things you could do with AREXX hooks into MT!

Oh, cool idea!! I'll have to pull my A500 and/or A3000 out of the attic and try that out! I should have something working by tomorrow evening although I'll have to blow away Amix (Amiga Unix SVR4) and reinstall AmigaDOS...

It is times like this that I wish for a facepalm smiley.