can't cross-compile from 1.5 to 1.4
We have lot number of java source files written using Java 1.5 specific features such as templates, enums etc.. But we have urgent need to
compile and run them with JVM 1.4.
Java compiler (javac) says it provides an option to cross-compile the sources and generate class files to be compatible with any specific JVM version.
For example, the javac from JDK 1.5 provides an option (-target) to compile and generate class files that will run on 1.4 JVM. See the Cross-Compilation options section in http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
But, we are not able to compile java sources to 1.4 VM class files using javac from jdk1.5.
We are getting below ERRORs:
javac: target release 1.4 conflicts with default source release 1.5
javac: source release 1.5 requires target release 1.5
Commands:
C:\> java -version
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)
C:\> javac -target 1.4 GetEntV4.java
javac: target release 1.4 conflicts with default source release 1.5
C:\>javac -source 1.5 -target 1.4 GetEntV4.java
javac: source release 1.5 requires target release 1.5
Not sure whether java really supports compiling java 1.5 sources to 1.4 jvm compatible classes ?
OR is it that the above link is merely a documentation - but not supported ?
Appreciate any help to resolve this issue..
thanks,
-Satya
[1580 byte] By [
satya25a] at [2007-10-2 9:00:26]
You can't compile things for older runtimes that use features only supported on later runtimes.
There may be some 3rd party products that can do somehow transpile your source to something that may work, but the compiler can't do it for you.
It's the same as with using packages and classes that don't exist in old JVMs, anything depending on them will never work on those JVMs.
Either get your customers to install 5.0 JVMs or rewrite your stuff to not use 5.0 language features.
[url= http://forum.java.sun.com/thread.jspa?threadID=586602]source 1.5 and target 1.4[/url][url= http://retroweaver.sourceforge.net/]Retroweaver[/url]
Sun, are you insane? Things compiled under 1.2 work fine on some versions JVM, but not others. Same code compiled under 1.5 works on some other versions of JVM, but not the lesser versions.Did I add new features that only exist under 1.5 - no obviously not, because I can still compile and run under 1.2.
You've created a nightmare with all your different version requirements. And do you know how much control I have over what version web users have of their machine? Obviously none. You've made Java useless. No wonder why Microsoft dropped your @$$!
(And don't give me some crap answer that I'm a Newbie. I've been doing this for many years and am probably one of the most prolific Java coders out there.)
> Sun, are you insane? Things compiled under 1.2 work
> fine on some versions JVM, but not others. Same code
> compiled under 1.5 works on some other versions of
> JVM, but not the lesser versions.Did I add new
> features that only exist under 1.5 - no obviously
> not, because I can still compile and run under 1.2.
>
> You've created a nightmare with all your different
> version requirements. And do you know how much
> control I have over what version web users have of
> their machine? Obviously none. You've made Java
> useless. No wonder why Microsoft dropped your @$$!
>
> (And don't give me some crap answer that I'm a
> Newbie. I've been doing this for many years and am
> probably one of the most prolific Java coders out
> there.)
In javac 1.4 and javac 1.3, the default value for the -target flag was 1.2
You could still have the same javac problems in 1.4 as you do with 1.5, if you specified -target 1.4
For 1.5 the default value for -target was changed to 1.5 and not 1.2. So you can have the same javac 1.4 behavior in 1.5 if you specify -target 1.2. Just don't use any of the new features of 1.5, 1.4, or 1,3 and it will run in a 1.2 vm just fine.
"Retrotranslator is a Java bytecode transformer that translates Java classes compiled with JDK 5.0 into classes that can be run on JVM 1.4" http://retrotranslator.sourceforge.net/
> Sun, are you insane? Things compiled under 1.2 work
> fine on some versions JVM, but not others. Same code
> compiled under 1.5 works on some other versions of
> JVM, but not the lesser versions.Did I add new
> features that only exist under 1.5 - no obviously
> not, because I can still compile and run under 1.2.
>
things you compiled under 1.2 work under later JVMs.
Things compiled under 1.5 should also work under later JVMs (except those exist only as betas right now).
Things you compile under 1.2 won't work without extra work under 1.0, and so things compiled under 1.5 won't work without extra work (and care to avoid new language features) under 1.4 and earlier.
> You've created a nightmare with all your different
> version requirements. And do you know how much
> control I have over what version web users have of
> their machine? Obviously none. You've made Java
> useless. No wonder why Microsoft dropped your @$$!
>
No nightmare, except your misunderstanding of the world which shows only your own ignorance.
If you don't want to use new features, stick with old compilers.
> (And don't give me some crap answer that I'm a
> Newbie. I've been doing this for many years and am
> probably one of the most prolific Java coders out
> there.)
You're a newbie if you think pure code volume is the mark of an experienced person.
I'd rather have someone who can write a program in a thousand lines than someone needing a hundred thousand lines and still isn't finished.
I have the same problem. It is indefensible that 1.5 does not support a 1.4 or 1.3 compile. Is there any question about this? Also, of what value is the -target compiler option if it does not compile to older version? Sounds like a bug to me...
funka at 2007-7-16 23:07:23 >
It does. You just have to specify the same source and target versions.You can't rationally expect code that will only compile under 1.5 to run on an older JVM.
ejpa at 2007-7-16 23:07:23 >
I have used Retroweaver for a larger project.I can highly recommend it.
I would like to be able to make use of new language features
without having to change the format of the bytecodes output
by the compiler. Compatibility is of paramount importance,
as Java is supposed to be reliable.
Now users go to my webstart applications and find
class file formats are 49, not 47. I tell them that they
need to update, and I loose my user base. This kills
the business model.
The realization that I have a need for a retroweaver feature to be
integrated into the javac command is just beginning to
dawn on me.
Retroweaver is such a useful feature, why not take a performance
hit in favor of compatibility?
If the trade is reliability vs. performance, I pick reliability.
If the trade is compatibility vs perforamcne, I pick
compatibilty.
If I don't care about reliability and compatibility, I use C++!
- DocJava.
> I would like to be able to make use of new language
> features
> without having to change the format of the bytecodes
> output
> by the compiler. Compatibility is of paramount
> importance,
> as Java is supposed to be reliable.
And it is. But you're assuming that all new features can be implemented without changing the bytecode, and that's not the case.
ejpa at 2007-7-16 23:07:23 >
> I would like to be able to make use of new language
> features
> without having to change the format of the bytecodes
> output
> by the compiler. Compatibility is of paramount
> importance,
> as Java is supposed to be reliable.
>
It's quite reliable. No language is upwards compatible like you desire.
How would Sun have known 10 years ago what they'd need in the bytecode format today?
But if you don't use the new language constructs and new methods and constructors added in later versions you can generate older bytecode formats just fine.
> Now users go to my webstart applications and find
> class file formats are 49, not 47. I tell them that
> they
> need to update, and I loose my user base. This kills
> the business model.
>
Tough luck. You should adapt to your customers. If they refuse to use a more modern runtime than 1.3 you should code to that rather than complain that your more modern compiler doesn't automagically translate your code into something that works with a language version that doesn't support the core features you were using.
> The realization that I have a need for a retroweaver
> feature to be
> integrated into the javac command is just beginning
> to
> dawn on me.
>
No, you need to learn to use the language properly. That means coding to the 1.3 spec if the customer wants that.
> Retroweaver is such a useful feature, why not take a
> performance
> hit in favor of compatibility?
>
There is no compatibility in using something like those tools. There's only self-delusion.
> If the trade is reliability vs. performance, I pick
> reliability.
> If the trade is compatibility vs perforamcne, I pick
> compatibilty.
>
Compatibility comes out of the box, you just need to learn to use the tools at your disposal properly (which you seem paramount to refuse to do).
Performance is of far greater importance.
> If I don't care about reliability and compatibility,
> I use C++!
>
And run into the same problems.
Try compiling code written for the 1.0 C++ spec with a 3.0 compliant compiler and it will fail as well.
Or try linking code compiled by a new C++ compiler with code compiled by an older compiler. Or by a C++ compiler from a different vendor. Good luck.
ejpa at 2007-7-16 23:07:23 >
This is all fine. So I can't compile 1.5 code to 1.4....what I'm having trouble with is what good the cross compilation options do ? If I have to have 1.4 code, why wouldn't I just use the 1.4 jdk ?
Because you mightn't want to have every JDK since the year dot installed on your machine? and you might still be able to generate bytecode for the corresponding JREs? from a single product? which Sun have kindly given us? Like me?
Nobody's forcing you to use the feature but please let's not pretend it is useless. It is invaluable.
ejpa at 2007-7-20 19:59:39 >
hmm, not all that valuable. You can still run into problems even if things compile with the -source and -target flags set when attempting to run it on an older JVM.
Think of classes that call overloaded methods core library classes where new overloaded methods were added in the version you compiled with. It's quite possible (I've seen it happen) that the compiler (especially with autoboxing/unboxing) will pick one that's not available in the older core library version, and you're screwed.
That's why I keep 1.3, 1.4, 5.0 and 6.0 installed for projects requiring each of them.
if you really don't use features from 1.5 in your sourcecodejavac needs 2 parameters:-source 1.4-target 1.4I had the same problem ...
JSaara at 2007-7-20 19:59:39 >
Congratulations on restating something that the OP was already doing in the original post. You could have bothered to read the thread before adding to it.
ejpa at 2007-7-20 19:59:39 >
and that for his second post in like 7 years on these forums...
