is java backwards compatible & installing many JDKS / SDKs

[jameshanley39]

is java backwards compatible & installing many JDKS / SDKs

i'm getting this message

"
C:\stuff\jswordtest\jsword-1.0.5\jsword\org\crosswire\jsword\passage\
PassageTally.java:626: warning: as of release 1.4, assert is a keyword,
and may not be used as an identifier assert verses > 0;
"

it's not my code.. And I don't know much java anyway. I laernt a little
java long ago. i'm guessing maybe it was using JUnit before there was
an Assert statement in java.
I don't know which java that code was written in. I tried runing it in
1.4, I guess i'll have to try an earlier version..

Anyhow, my question is..

is java not backwards compatible? I knwo it can give errors about
deprecated, but i figured that could be gotton around by using a
command line switch.

If indeed, java is not backwards compatible.. Then is the workaround to
install loads of different versions of JDKs/SDKS?

If so, are there issues? Is it possible for them to clash?
e.g. installing an older one after installing a newer one? or can the
other way around be a problem?

TIA

 

[Andrew Thompson]

C:\stuff\jswordtest\jsword-1.0.5\jsword\org\crosswire\jsword\passage\
PassageTally.java:626: warning: as of release 1.4, assert is a keyword,
and may not be used as an identifier assert verses > 0;

I imagine this should be relatively easy to fix,
if you have ane IDE that facilitates refactoring.
I suspect Eclipse could do it relatively easily.

...Then is the workaround to
install loads of different versions of JDKs/SDKS?

There might be other solutoins, but if it a desk-top
applicaiton, it can be launched using web-start.
That can handle the JRE versioning.

(But I would recommend investigating refactoring.)

Andrew T.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

is java backwards compatible & installing many JDKS / SDKs

i'm getting this message

"
C:\stuff\jswordtest\jsword-1.0.5\jsword\org\crosswire\jsword\passage\
PassageTally.java:626: warning: as of release 1.4, assert is a keyword,
and may not be used as an identifier assert verses > 0;
"

it's not my code.. And I don't know much java anyway. I laernt a little
java long ago. i'm guessing maybe it was using JUnit before there was
an Assert statement in java.
I don't know which java that code was written in. I tried runing it in
1.4, I guess i'll have to try an earlier version..

Anyhow, my question is..

is java not backwards compatible? I knwo it can give errors about
deprecated, but i figured that could be gotton around by using a
command line switch.

In general Java is very backwards compatible.

But it is almost impossible to add stuff without breaking
existing code when there are a name clash.

The use of assert as an identifier is obviously such a case.

Your best choice would be to fix the code.

The quick and dirty workaround is to compile it
in backwards compatible mode:

java -source 1.3 ...

Arne

PS: There are no problems having multiple Java versions
installed - in fact most IDE's support so.

 

[jameshanley39]

In general Java is very backwards compatible.

But it is almost impossible to add stuff without breaking
existing code when there are a name clash.

The use of assert as an identifier is obviously such a case.

Your best choice would be to fix the code.

The quick and dirty workaround is to compile it
in backwards compatible mode:

java -source 1.3 ...

do you mean javac?

I see that javac has -source and even a -target.
But java doesn't have a -source,

so what do do of java/the JVM?
I guess that method if it could work would mean I wouldn't need
multiple versions.

If I did have multiple versions .. considering that , as far as I
know, old libraries are retained (are they?). Then woudl it be
possible to do something like just have the latest java installed, but
different java.exe files for different versions?

 

[jupiter]

In general Java is very backwards compatible.

But it is almost impossible to add stuff without breaking
existing code when there are a name clash.

The use of assert as an identifier is obviously such a case.

Your best choice would be to fix the code.

The quick and dirty workaround is to compile it
in backwards compatible mode:

java -source 1.3 ...

do you mean javac?

------------
He meant javac -source 1.3 (and finish the args, class name, etc.)

-source only warns the compiler to run "as if" it's version 1.3,
which allows assert as keyword, which is obviously backward
compatible.

But like Andrew said, just refactor the project and change the
asserts as your best solution. The possibility exists that
somebody used assert as a "regular ole keyword", and it's not a
JUnit issue at all. If you load the project into Eclipse you will
be able to see the members in the tree, and it has a nice Refactor
capability.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

do you mean javac?
Yes.

I see that javac has -source and even a -target.
But java doesn't have a -source,

so what do do of java/the JVM?
I guess that method if it could work would mean I wouldn't need
multiple versions.

Yes.

It should run fine with the 1.4/1.5/1.6 JVM.

Arne

 

[jameshanley39]

Yes.

It should run fine with the 1.4/1.5/1.6 JVM.

but there's that issue of java not having a -source tag.
when you say "it" are you referring to my proposal of many java.exe
files for different JVMs, e.g. 1.2 1.4 1.5 1.6, all on a JVM 1.6 +
installation, hence using the most complete library .

you only said 1.4/1.5/1.6 Do you mean prior to 1.4 too ?

Or are you implying that java.exe 1.2 or earlier will not work when
everything else is 1.6 JVM , Whereas java.exe 1.4,1.5 will work when
everything else is JVM 1.6 ?
I don't see why that'd be. the different java.exe files should cater
for the assert issue..

 

[jameshanley39]

but there's that issue of java not having a -source tag.
when you say "it" are you referring to my proposal of many java.exe
files for different JVMs, e.g. 1.2 1.4 1.5 1.6, all on a JVM 1.6 +
installation, hence using the most complete library .

you only said 1.4/1.5/1.6 Do you mean prior to 1.4 too ?

Or are you implying that java.exe 1.2 or earlier will not work when
everything else is 1.6 JVM , Whereas java.exe 1.4,1.5 will work when
everything else is JVM 1.6 ?
I don't see why that'd be. the different java.exe files should cater
for the assert issue..

it's alright, i'll test it when i get some time and report back

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

but there's that issue of java not having a -source tag.

You do not need it.

when you say "it" are you referring to my proposal of many java.exe
files for different JVMs, e.g. 1.2 1.4 1.5 1.6, all on a JVM 1.6 +
installation, hence using the most complete library .

No.

I mean run it with Java 1.6 java command.

you only said 1.4/1.5/1.6 Do you mean prior to 1.4 too ?

I did not find it necesarry to say that -source 1.3 compiled code
would run on 1.3.

Or are you implying that java.exe 1.2 or earlier will not work when
everything else is 1.6 JVM , Whereas java.exe 1.4,1.5 will work when
everything else is JVM 1.6 ?
I don't see why that'd be. the different java.exe files should cater
for the assert issue..

If you want to run it on a 1.2 I think you would need
javac -target 1.2 ...

Arne

 

[Lew]

I did not find it necesarry to say that -source 1.3 compiled code
would run on 1.3.

It won't always. If you compile a class with a J6 javac set "-source 1.3" it
might still reference JARs from the J6 bootclasspath, possibly invoking
methods that did not exist in 1.3, which will raise a runtime error. It has
happened to me more than once.

- Lew

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

It won't always. If you compile a class with a J6 javac set "-source
1.3" it might still reference JARs from the J6 bootclasspath, possibly
invoking methods that did not exist in 1.3, which will raise a runtime
error. It has happened to me more than once.

The discussion is about building old code (that worked
with 1.3 and have compile errors with 1.6) and running it
with a new Java version.

Arne

 

[Lew]

The discussion is about building old code (that worked
with 1.3 and have compile errors with 1.6) and running it
with a new Java version.

Good point, but sometimes statements deep into a thread take on generality
beyond the original post, and I just did my usual nitpicking thing to keep
other readers from deriving the wrong principle. What applies to a particular
project's codebase that never changed since its 1.3 days should not be
construed to apply to all code being retrocompiled. Once burned, twice shy.

- Lew