Include Test for JRE version in TASServer (Patch inside)

koshi · Post by **koshi** » 24 Sep 2007, 02:13

to prevent irritations like this one in the future (I know requirement is in the readme)

maybe something along the line of

Code: Select all

if (!testJvmVersion)
	JOptionPane.showMessageDialog(null, "You need a JRE newer than version 1.6 to run TASServer.\n"+
					"Go to http://java.com to download one");

at the beginning of TASServer.java's main with a test function like

Code: Select all

private static boolean testJvmVersion(){
		char[] version = System.getProperty("java.version").toCharArray();
		int major = Character.getNumericValue(version[0]);
		int minor = Character.getNumericValue(version[2]);
		return ((major > 1) || ((minor > 5) && (major > 0)));
	}

Note that I have only verified that Sun JRE >= 1.6 actually pass it. I don't have the nerve to install an older one on my ubuntu.

AF · Post by AF » 24 Sep 2007, 08:48

Some users have ancient Java runtimes, runtimes older than even Windows ME.

At some point around Java 1.4 the JAR package format changed. As a result users who cba to update their Java runtimes beyond 1.4 minimum are unable to load new JAR packages. This shouldn't be an issue as this new packaging system has been in use for a long time, years and years.

We cant expect TASServer to run on Java run times released when windows 98 and 95 were the dominant Operating systems.

To clarify this, this is not a java code issue this is a problem with Java runtimes. Old run times cannot load the package nm execute the code you propose inside them.

koshi · Post by **koshi** » 24 Sep 2007, 12:06

Well I didn't know that the actual packiging format changed. But the test could still work for users with JRE >= 1.4, yes? Possibly include a test for the JRE vendor if TASserver runs on sun's one exclusively.
The whole thing would be a non-issue if people really read the readme, but then somebody who is running that old a version would probably not know its version number (or care)...

AF · Post by AF » 24 Sep 2007, 16:10

No because if the user can run the test then the problem cannot occur to begin with.

A->B->C

A is package loading

B is opening loaded package

C is running package contents

The problem is at B
The test is at C
B comes before C
therefore the test will not be runnable if the system is capable of producing that error.

Think of it like this:

A man speaks a language. You dont know what language he speaks. You have 1 question. You ask him "Can you understand my language".

If the man cannot understand your language then he cant answer your question.

Analogy 2:

You have a P123 form to fill in but you need the form. The P123 form is in a tray at the Big building on the right but to get into the building you need a P123 form.

Thus the test is pointless because if the user has this problem then the user can never reach the test and the test can never run.

koshi · Post by **koshi** » 24 Sep 2007, 16:28

I got that the package loading is the problem in that specific case. Lets go a bit beyond that. Say user has jre >= 1.4 but < 1.5 therefore can load the package and execute some test (needn't be the one I proposed). Yet he'll get errors when trying to run TASServer which uses feature x introduced in 1.5 (generics were introduced then, right?) due to the fact that his jre doesn't understand it. If a suitable test and error message would have been implemented he would not think that something is wrong with TASServer itself, but rather see that he needs to update his jre.

Would that scenario be possible/make sense?

By the way I appreciate the work you put in the analogies, but they're really not necessary for me. I handle abstractions quite well (*cough* math-major *cough*)

AF · Post by AF » 24 Sep 2007, 18:20

You'll find a working implementation in AFLobby starting in CreateGUI() of Main.java near its beginning. Its currently setup to detect Java 6 not 5 though. If java 4 or 5 is found it prints out a message to System.out and then opens http://www.java.com in the browser.

koshi · Post by **koshi** » 25 Sep 2007, 15:02

I've created a patch that implements the following:
- tests if system.property java.vendor contains "sun"
- tests if version number is higher or equal to 1.5 (test proposed in first post)
- if one of the tests fails a message is printed to console (headless machine) or message box pops up + browser with java.com opens

TASServer Patch

I've used an unmodified version of the browserlauncher from http://www.centerkey.com/.
Again I didn't test it on older jres, but if AF's code for identifying version works, so should this test.

Could it be included in the current form? Some modification needed? No one else cares?

@AF: I've looked at your code. Is there a particular reason that you test the java.vm.name property instead of java.vendor?

Post by **ILMTitan** » 25 Sep 2007, 15:49

Why would you limit it to only vm's produced by sun? Although somewhat rare, there are non-sun virtual machines that fully implement the java byte code specification.

Also, generics did nothing to the byte code because they were implemented by type erasure. They were a compile time only feature. I did think there was some small change with the byte code in 1.5, but I know it did not have anything to do with generics.

koshi · Post by **koshi** » 25 Sep 2007, 16:06

I (somewhat naive) assumed that because the readme stated sun that there is a reason for it. Can i get from your statement that TASServer runs fine on other jres? Also is there even a problem with the server running on sun jre 1.4? Again I assumed 1.5 was needed.

If someone would compile a real list of requirements, we could see how the test could be modified or if it is even useful.

From the package format change i get that if you use sun jre, 1.4 is minimum.

If indeed TASServer runs fine on other jvms there would be multpile possibilities of version incompabilities. So instead of testing all of the combinations a simple message on startup could do. Something like "non-sun jvm detected, if problems occur update it or get one from sun".

AF · Post by AF » 25 Sep 2007, 16:08

I wasnt aware of that at the time...

koshi · Post by **koshi** » 25 Sep 2007, 16:18

Additionally could the exception java.lang.UnsupportedClassVersionError from the problem in the first post be caught? Or is it impossible because an old jvm simply cannot handle the jar?

AF · Post by AF » 25 Sep 2007, 16:23

I believe its the .class file itself causing the exception in the class loader

koshi · Post by **koshi** » 25 Sep 2007, 16:34

so aside from a custom class loader there is not much possible there. I'll do search, maybe there's something free we could use

koshi · Post by **koshi** » 25 Sep 2007, 18:42

I found a flaw in using a custom classloader. In order for it to excecute on old jres it would have to be compiled with appropiate compability level while keeping the rest compiled with a level that supports the used features.
That just seems wrong to me...
Instead I propose that TASServer be compiled with 1.5 as a target (possible via command line flag if used jdk > 1.5). Which brings me back to if that really is the minimum.

That would take care of users that run sun jre (1.5 <= user version <= current installed jdk on build system)
A test could then catch users with (1.4 <= user version < 1.5) and inform users of non-sun jre of possible problems (if there are any).

Am I making sense and or thinking about this too much?

AF · Post by AF » 25 Sep 2007, 20:13

bare minimum 1.4, ideally 1.5 or 1.6.

There's just far too much that's not supported in 1.3 and below.

koshi · Post by **koshi** » 29 Sep 2007, 12:29

Changed my patch so it just issues a warning if using non-Sun JRE. TASServer will now terminate only if there's a Sun JRE < 1.5. Also made the test optional. For now there's a global variable SkipJreTest that if set to anything other than 0 skips the test. It could be set within commandline parsing, but I didn't want to mess with that.

Here's the Patch

Post by **Betalord** » 29 Sep 2007, 15:01

No sorry, this is all unnecessary. On the download page TASServer comes in 2 packages - one exe and one jar. The exe one detects automatically if you have an outdated jre and points you to a download page automatically. The jar one is meant for linux users, who can (hopefully) understand java error output saying the class file are compiled with different version of java.

Also, your patch uses some gui element which would make server not run in console mode, which is the preffered "environment" for a server.
Another thing I don't see is how can that code be reached at all since the class is compiled with 1.5/1.6 jre?

koshi · Post by **koshi** » 29 Sep 2007, 15:27

Betalord wrote:Also, your patch uses some gui element which would make server not run in console mode, which is the preffered "environment" for a server.

Well, I didn't know about the exe part, but there is a test for a headless enviroment.
If one is detected it should only print a message to console, no gui calls.

Betalord wrote:The jar one is meant for linux users, who can (hopefully) understand java error output saying the class file are compiled with different version of java.

I agree on the the hopefully part, but if TASServer is not started from console the user would never even see that output.

Betalord wrote:Another thing I don't see is how can that code be reached at all since the class is compiled with 1.5/1.6 jre?

AF said that his implementation in AFLobby works. If he's correct my test should be reachable, being not that different.

Post by **Betalord** » 29 Sep 2007, 16:16

Very well, I will test it. Headless test should do it I guess, but I'll print something out to the console too just in case. I still don't see how the test could work though as class is compiled with 1.5, but I'll try it.

AF · Post by AF » 29 Sep 2007, 16:56

my mechanism detects Java 1.6 not 1.5 and 1.6 classes can be loaded by 1.5 runtimes.

Spring RTS Engine

Include Test for JRE version in TASServer (Patch inside)

Include Test for JRE version in TASServer (Patch inside)