If I understood the intention correctly, one of the design decisions for the Generic Java compiler was to maintain backwards compatibility with old JVMs. This decision was seemingly abandoned as of the latest (1.3) prototype release of the generic compiler, and I hope it's not intentional.
It appears that the new way to indicate to the compiler that code contains generics is to use the "-source 1.5" flag instead of -gj.
I have intentionally used the "-target 1.1" flag to the compiler to make sure that my code works with older JVMs. This worked fine for the last couple of years. This no longer works, as this causes the compiler to abort immediately with the error message"
Of course, I used "1.5" as the source so this error message is in itself a bug.
Why and when was backwards compatibility dropped? If Sun is going to eliminate backward compatibility, are you also going to make some of the changes that are used in other compilers (such as Pizza) that would benefit the language?
Needless to say, this is a complete showstopper for me--I can no longer use the Generic Java compiler and maintain backwards compatibility with older JVMs. If this error message is caused by some overzealous, incorrect check, can it be removed as soon as possible and a new prototype released?
I cannot underestimate the importance of backward compatibility and the ability to use the Generic compiler for my Frink project, which has been using the generic compiler happily for almost 2 years. I'm very worried that backward compatibility was silently dropped.
By the way, I don't have a big problem being forced to use a 1.4.1 compiler to compile my code (as is hinted at in the release notes,) but if the new compiler can't produce backward-compatible classfiles, that's where I'm doomed.
Re: Generic compiler abandons backwards compatibility?
Nov 8, 2002 11:53 AM
(reply 2
of 12) (In reply to
#1 )
To follow up, I got an e-mail from Neal Gafter (from Sun's compiler team) that said that said that he will file a bug and fix this; forward compatibility will be respected in the compiler. Woo hoo! Thanks!
No word on the timeframe before the next prototype release. He hinted that com.sun.tools.javac.v8.code.Source could be manually patched to eliminate this problem if one wishes to use the new prototype and support old VMs.
Backward compatibility is the ability to use old sources and binaries
in newer versions of the JDK. We will continue to support that. What
you're describing is forward compatibility, which allows newer language
features to be run on old VMs. We can't support that in general because
new language features often require VM support. Nevertheless, generics
code will interoperate with old code run on the same (newer) VM.
We are adding a number of language features in the 1.5 timeframe
that will require platform support. Even generics will get some platform
support in the released product, in the form of extended reflection
interfaces. In 1.4 we added assertions, and the generated code uses
features of the platform only available in 1.4. Therefore, if you
enable assertions you must have -target 1.4. Similarly in 1.5 we
are considering (among other things) enumeration types, which require
platform support.
In order to bring sanity to the language, we do not allow users to pick
and choose individual language features to enable and disable. You can
only select the language level you're writing for, and if you use a
feature that requires platform support at a certain level, you will simply
have to use a target VM that has that level of support.
But I was wrong to abandon forward compatibility.
The way I implemented this constraint was incorrect. I caused -source 1.4
(or later) to imply -target 1.4 (or later), the logic being that if you are
enabling new language features you will have to have VM support for them.
But I really should only require a recent -target version if the program
actually uses a language feature in a way that causes code to be generated
that invokes new VM features. For example, if you set -source 1.5, but happen
to use no assertions in your source, then you should be free to set -target 1.1.
I think you'll find that fixing the immediate problem requires changing
just one line of class com.sun.tools.javac.v8.code.Source to get the effect
you want. I have filed 4776214 against the compiler and hope to have it fixed
(i.e. implemented properly, by depending on which language features you actually
use) in a refresh of the prototype in a couple of months.
Re: Generic compiler abandons backwards compatibility?
Feb 24, 2003 2:29 AM
(reply 6
of 12) (In reply to
#5 )
Achtung! Don't get confused! Sun's re-reversal as of February 20, 2003 is that Sun isn't going to maintain forward compatibility. Please note the (old) dates on the messages above. Sun's position has changed since then.
The letter from Neal Gafter ( Feb. 20, 2003 says:)
---begin message from Neal Gafter, dated Feb. 20, 2003
Alan-
You reported a problem with the last generics prototype that it could
not be used with generics enabled (-source 1.5) to generate code to run
on an older VM (-target 1.1, for example). We debated this issue at
great length yesterday, and our decision is that the product (Tiger,
1.5) will not support that kind of forward compatibility. Consequently,
I will not add support for that into the generics prototype.
I have closed the corresponding bug report (4776214) as "will not fix".
If you want to use generics, we encourage you to migrate to the latest
version of the platform. When 1.5 is released, code compiled with
generics enabled will require a 1.5 VM to run.
Regards,
Neal
-----end message from Neal Gafter --------
Unfortunately, the problem is much worse than requiring -target 1.5 or not. Code that uses generics simply won't run on any platform before Java 1.5. A huge mistake, in my opinion, and not what we've all been hoping for.
Re: Generic compiler abandons backwards compatibility?
Feb 26, 2003 10:04 AM
(reply 8
of 12) (In reply to
#6 )
I'm amazed. Why shouldn't generics work with old VMs? The prototype
I have been using seemed to work well.
OK, so there are features that require a new VM (e.g. reflection)
but if I don't use them, why shouldn't my code compile? If I always
need the new JVM, why have two switches: -source and -target?
I'm happy to upgrade to 1.5 when it comes out but upgrading all the
lap-tops we have out in the field... it just won't happen.
Re: Generic compiler abandons backwards compatibility?
Mar 7, 2003 6:43 AM
(reply 9
of 12) (In reply to
#8 )
Why won't volitile images work before JDK 1.3? I think they are justified in saying that certain features of the language are just not going to be available to JVM implementations before a certain version. There's loads of classes that were introduced in 1.4 that if you compile using those classes, they aren't going to work in 1.3 or below. This is the same thing. I think it's good that they know when to draw the line at what can be made forward compatable and what can not. This is one of those cases where it can not. Re-builg your app against 1.5 and get over it. That's the nature of using 'bleeding edge' features.
Re: Generic compiler abandons backwards compatibility?
Jul 28, 2004 2:58 PM
(reply 10
of 12) (In reply to
#9 )
In his original post, eliason lamented that using the "-target 1.1" flag to the compiler to make sure his code would work with older JVMs only generated the error message:
I am using JDK 1.4.1 and am getting the same message. Has this been fixed in a more recent verison of the compiler? I want to compile some code to be an applet, but my understanding is IE won't run 1.4 code. I'd compile with 1.3, but I removed it from my system, and Sun no longer provideds it for download. (What's up with that???)
Re: Generic compiler abandons backwards compatibility?
Jul 29, 2004 7:41 AM
(reply 11
of 12) (In reply to
#10 )
In his original post, eliason lamented that using the
"-target 1.1" flag to the compiler to make sure his
code would work with older JVMs only generated the
error message:
I am using JDK 1.4.1 and am getting the same message.
Has this been fixed in a more recent verison of the
compiler? I want to compile some code to be an applet,
but my understanding is IE won't run 1.4 code.
The IE virtual machine, assuming people are using it and not the Java Plugin instead, only supports JDK 1.1.8 (minus JNI and RMI).
To compile to target this VM with the 1.4 version of javac, you should use
As you've realized, you cannot use -source 1.4, because 'assert' is not supported in 1.1. You can use -source 1.1, 1.2 or 1.3 however (which is pretty much the same thing, anyway).
I'd
compile with 1.3, but I removed it from my system, and
Sun no longer provideds it for download. (What's up
with that???)
Email this Topic
Edit this Topic
