Java version needed?

[Fencer]

Hello, I have a Java program that consists of maybe 50 classes.
Personally, I use Java 1.6.0_14 that just came out when I work on this
program. My question is: how do I find out what version is actually
needed to run it?
More specifically, I'm interested to know the Java version needed to
execute a runnable jar of this program (if that even matters).

Are there any tools that can scan your code base and say: "here you're
using the class xyz or the method foobarbaz and that was introduced in
version uvw", at least for the classes, interfaces and their methods
found in "standard" Java? The program uses Xerces2-J version 2.9.1 alot
but there I happen to know it works with older Java versions.

I didn't write the base of the code myself but I can tell you it uses
generics and, now I will probably not use the right term, "enum classes".

- Fencer

 

[Andrew Thompson]

..I have a Java program...
Personally, I use Java 1.6.0_14 that just came out when I work on this
program. My question is: how do I find out what version is actually
needed to run it?

Do a compilation specifying a -bootclasspath that
points to the earlier rt.jar from the J2SE version
of interest. It will replace the JDK's default
rt.jar with the version you supply, and report
any missing classes, methods or fields as
compilation errors. On successful compile, the
binary is guaranteed to use no member that is not
present in the -bootclasspath jar.

To actually ensure the byte code is compatible with
that version of Java, it is also necessary to specify
the -source and -target at compile time, but it is
the -bootclasspath that is *most* important.

 

[coffeymex]

program. My question is: how do I find out what version is actually
needed to run it?
More specifically, I'm interested to know the Java version needed to
execute a runnable jar of this program (if that even matters).

You *can* use:

System.getProperty("java.version")

However, if your purpose is to check if the user has a version with a
particular class, you could always just call Class.forName() and see
if the particular class you're interested in is present.

I'm not aware of a tool/database to say "what was the first version in
which class X was introduced", but I suppose you could compile one if
it was that important. I don't quite see the point-- if you're telling
the user to upgrade, you may as well just tell them to get the latest
version.

Neil

 

[Lew]

Hello, I have a Java program that consists of maybe 50 classes.
Personally, I use Java 1.6.0_14 that just came out when I work on this
program. My question is: how do I find out what version is actually
needed to run it?

As others have stated, you can use the "-bootclasspath", "-source" and
"-target" options to the compiler to force a version compatibility.

More specifically, I'm interested to know the Java version needed to
execute a runnable jar of this program (if that even matters).

Are there any tools that can scan your code base and say: "here you're
using the class xyz or the method foobarbaz and that was introduced in
version uvw", at least for the classes, interfaces and their methods
found in "standard" Java? The program uses Xerces2-J version 2.9.1 alot
but there I happen to know it works with older Java versions.

Why not use the XML parser built in to the Java distribution?

I didn't write the base of the code myself but I can tell you it uses
generics and, now I will probably not use the right term, "enum classes".

"enum classes" is a perfectly valid term, since that's what they are. Most
people just call them "enums" or "Java 5 enums".

Obviously you need at least Java 5 to run this app. Depending on the exact
API calls used, you might need Java 6. You can also use tools that look at
the class version numbers in the .class files to determine the earliest Java
version that will run them.

 

[Fencer]

As others have stated, you can use the "-bootclasspath", "-source" and
"-target" options to the compiler to force a version compatibility.

Thanks for the replies. Armed with this information I found a way in my
IDE to set compliance level to 1.5 and I got 82 errors spread out across
the project when I did that. So, I can now conclude that the project
requires Java 1.6 and that is exactly the information I needed to know.
Now I will look at these errors and see if they are worth fixing so
users of Java 1.5 can run this program too.

Why not use the XML parser built in to the Java distribution?

It doesn't seem to support the (I suppose, rahter exotic) schema parsing
that I need to do? At least I didn't see XSModel et. al. being listed at
http://java.sun.com/javase/6/docs/api/
Anyway, my main question has been answered and I'm happy.

- Fencer

 

[Arne Vajhøj]

Hello, I have a Java program that consists of maybe 50 classes.
Personally, I use Java 1.6.0_14 that just came out when I work on this
program. My question is: how do I find out what version is actually
needed to run it?
More specifically, I'm interested to know the Java version needed to
execute a runnable jar of this program (if that even matters).

Are there any tools that can scan your code base and say: "here you're
using the class xyz or the method foobarbaz and that was introduced in
version uvw", at least for the classes, interfaces and their methods
found in "standard" Java? The program uses Xerces2-J version 2.9.1 alot
but there I happen to know it works with older Java versions.

Install various Java versions on your PC and try and run
your jar file with them.

Always good to have 1.3.1, 1.4.2, 1.5.0, 1.6.0 and a 1.7.beta
on your development system.

I doubt that source not compiling on X will always will
mean that byte code will not run on X.

Arne

 

[Lew]

Always good to have 1.3.1, 1.4.2, 1.5.0, 1.6.0 and a 1.7.beta
on your development system.

Always good to have Java 5 and 6 on your dev system. Sometimes good to have
an expired version like 1.3.x or 1.4.2_x on your dev system. Occasionally
good to have 1.7beta on your dev system.

Have they fixed the feature set for Java 7 yet?

 

[Andrew Thompson]

....
Install various Java versions on your PC and try and run
your jar file with them.

For that to be successful, you would need to ensure
that the test covers all possible code paths. While
it is a good idea to have such testing available for
a project, it is far /easier/ to do version testing
against an rt.jar using the -bootclasspath option at
compile time.