Skip to main content



      Home
Home » Language IDEs » Java Development Tools (JDT) » Source 5.0, Target < 5.0 ?
Source 5.0, Target < 5.0 ? [message #215866] Thu, 29 September 2005 09:54 Go to next message
Eclipse UserFriend
Hi,

what exactly is the reason that classfile compatibility has to be 5.0 when
source compatibility is 5.0 in the eclipse compiler settings? As far as I
understand, a substantial part of the new JDK1.5 features are "just"
features handled by preprocession (e.g. generics, foreach-loop,
autoboxing, ...) which end up "blown-up" to traditional code in bytecode.
I noticed that when tweaking eclipse to produce 1.4 bytecode from 1.5
sourcecode, it will run just fine in 1.4 vm's...

I agree that handling new classes like Enum, StringBuilder, etc. can get
messy...
Couldn't there be sort of a "backwards compatible 1.5" mode for the source
level...

oliver
Re: Source 5.0, Target < 5.0 ? [message #215874 is a reply to message #215866] Thu, 29 September 2005 10:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

Why use 1.5 if you want to be 1.4 compatible? It would be easier to just
use 1.4. Then it would automatically be compatible with 1.5. Also the
new features of 1.5 do produce some different bytecode.

It would be very difficult in 1.5 mode to not use any of the features
that would cause different bytecode. You wouldn't know. In fact you
could accidently use new methods (which are not bytecode) from older
classes in 1.5 which are not available in 1.4. You wouldn't know this
until runtime. The compiler would be complicated tremendously if it had
to check that the methods used on a class were also available in 1.4.


Oliver Masutti wrote:
> Hi,
>
> what exactly is the reason that classfile compatibility has to be 5.0
> when source compatibility is 5.0 in the eclipse compiler settings? As
> far as I understand, a substantial part of the new JDK1.5 features are
> "just" features handled by preprocession (e.g. generics, foreach-loop,
> autoboxing, ...) which end up "blown-up" to traditional code in
> bytecode. I noticed that when tweaking eclipse to produce 1.4 bytecode
> from 1.5 sourcecode, it will run just fine in 1.4 vm's...
>
> I agree that handling new classes like Enum, StringBuilder, etc. can get
> messy...
> Couldn't there be sort of a "backwards compatible 1.5" mode for the
> source level...
>
> oliver
>
>

--
Thanks,
Rich Kulp
Re: Source 5.0, Target < 5.0 ? [message #215903 is a reply to message #215874] Thu, 29 September 2005 16:22 Go to previous messageGo to next message
Eclipse UserFriend
Rich Kulp wrote:

> Why use 1.5 if you want to be 1.4 compatible? It would be easier to just

Well, Java 1.5 definitely has some nifty features that can make life
easier (generics etc.). However, not too many products support 1.5 yet.

> use 1.4. Then it would automatically be compatible with 1.5. Also the
> new features of 1.5 do produce some different bytecode.

imho this is not the case for all the features. e.g. the retroweaver
documentations says
( http://retroweaver.sourceforge.net/guide/retroweaver-guide.h tml):
'“Wait,”, you say, “I thought Retroweaver also supports static imports,
varargs, and generics, but I saw no mention of them, here.”
It is true that Retroweaver does support these features, it's just that
these features require no special support from Retroweaver.'

> It would be very difficult in 1.5 mode to not use any of the features
> that would cause different bytecode. You wouldn't know. In fact you
> could accidently use new methods (which are not bytecode) from older
> classes in 1.5 which are not available in 1.4. You wouldn't know this
> until runtime. The compiler would be complicated tremendously if it had
> to check that the methods used on a class were also available in 1.4.

well of course you would have to be very careful in what you are doing...
for example, eclipse already now offers the possiblity to use source=1.4
and target=1.3.

cheers,
ollie
Re: Source 5.0, Target < 5.0 ? [message #215909 is a reply to message #215903] Thu, 29 September 2005 16:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.us.NO_SPAM.ibm.com

But that's what I'm saying. The new features DO use new bytecodes.
That's why it is not compatible. If you want to use the new features you
will need to run under 1.5.

--
Thanks,
Rich Kulp
Re: Source 5.0, Target < 5.0 ? [message #215950 is a reply to message #215909] Thu, 29 September 2005 19:50 Go to previous messageGo to next message
Eclipse UserFriend
Rich Kulp a écrit :
> But that's what I'm saying. The new features DO use new bytecodes.
> That's why it is not compatible. If you want to use the new features you
> will need to run under 1.5.
New bytecodes, not really. One bytecode has been extended (ldc or
ldc_w). It has been extended to support the class literal (X.class in
the source code) in order not to initialize the class X. This was a long
standing bug in javac.
1.5 introduced some new attributes that are used by the compiler to
recognize a generic type. These new attributes could be generated with
target 1.4 as they would simply have no effect. Unknown attributes are
ignored when read by the VM. And these attributes would be considered as
unknown for a 1.4 VM.
Technically the biggest issue is the usage of methods/types/fields
defined only in 1.5. The compiler doesn't check when the method has been
defined. It simply checks the libraries used to compile. So in order to
use generics, you would need the 1.5 libraries, but this could be
problematic then at runtime when you run on 1.4 libraries. You can get
potential NoSuchFieldError, NoClassDefFoundError or NoSuchMethodError.
Adding that check would have a huge performance hit.
--
Olivier
Re: Source 5.0, Target < 5.0 ? [message #216306 is a reply to message #215950] Wed, 05 October 2005 06:35 Go to previous messageGo to next message
Eclipse UserFriend
Olivier is right. Retroweaver is some sort of a woraround the limitation on
compilers.
It would take a significant amount of work to ensure a viable story for
users, i.e. handle 2 class libraries (like retroweaver does), and as a
compiler tool we would become some sort of outlaws, as there is no such
compliance level as source 1.5 with target 1.4 (as defined by the JLS 3rd
edition and JCK compliance test suites); thus we could loose our 100% pure
Java sticker by playing such a game.
As it is, either the Java spec is revised to allow these settings, and then
we will comply; or it is not, and legally we cannot move. Providing a
separate tool doing bytecode manipulation (a la retroweaver) is one way to
solve this issue; and some could look at providing some add-on to our
compiler to do something similar, but this would be time permitting, and we
don't have much to burn on this topic; especially considering this is an
issue only while transitionning to 1.5. The longer you wait, and the less it
becomes real.

As you noticed, we internally support -source 1.5 -target 1.4, and will spit
out valid 1.4 classfiles, but as long as user code refrain from using enums,
annotations and 1.5 specific libraries (i.e. StringBuilder for instance).


"Olivier Thomann" <olivier_thomann@ca.ibm.com> wrote in message
news:dhhukm$cut$1@news.eclipse.org...
> Rich Kulp a
Re: Source 5.0, Target < 5.0 ? [message #216532 is a reply to message #216306] Thu, 06 October 2005 16:15 Go to previous messageGo to next message
Eclipse UserFriend
Thanks Olivier and Philippe for your valuable input.

> don't have much to burn on this topic; especially considering this is an
> issue only while transitionning to 1.5. The longer you wait, and the less it
> becomes real.

The Application Server I'm supposed to work with is still based on JDK1.3
so I'm happy to invest some time here ;-).

> As you noticed, we internally support -source 1.5 -target 1.4, and will spit
> out valid 1.4 classfiles, but as long as user code refrain from using enums,
> annotations and 1.5 specific libraries (i.e. StringBuilder for instance).

I've got a bit further with my investigations and found a solution/hack
that is much easier to implement than beefing up (or crippling) the
compiler: I started "porting" the collection classes I need, taking the
1.4 source, delete the method bodies* and any non-public stuff and adjust
the remaining constructor/method signatures so that match their 1.5
counterpart (including all the generics information!!!). In the eclipse
project, which is based on a 1.4 JDK, I put these new classes at the top
of the build path list (in any case in front of the ordinary jdk classes).
This way, the compiler (-source1.5 -target1.4) considers them first, but
produces perfectly valid 1.4 code, as no type/method/field that arrived in
1.5 can accidentially be used. Of course, these special classes may not be
on the classpath when running the whole thing, for this the ordinary
jdk1.4 classes must do!! Btw, foreach works fine with these classes, too,
as they implement Iterable.
Also, by adding the Annotation classes in the same way, the
@SuppressWarnings Annotation works fine in a 1.4 project as well. I
haven't checked other than "source only" retained annotations, though...
What's more, autoboxing is NOT working with this approach, as the compiler
generates a Integer.valueOf(int) which did not exist in <=1.4. I'll need
to invest some more time here looking for a workaround.

Ciao!
- Ollie

*Inside every public method body, I put a "throw new
UnsupportedOperationException()" for simplicity and for making sure people
find out quickly when accidentially putting these dummy classes on the
classpath.
Re: Source 5.0, Target < 5.0 ? [message #216548 is a reply to message #216532] Thu, 06 October 2005 17:03 Go to previous messageGo to next message
Eclipse UserFriend
Oliver Masutti a écrit :
> Also, by adding the Annotation classes in the same way, the
> @SuppressWarnings Annotation works fine in a 1.4 project as well. I
> haven't checked other than "source only" retained annotations, though...
Annotations in general are not an issue in the resulting .class file as
they end up in class file attributes. They would then simply be ignored
by a 1.4 VM because they will be unknown.

> What's more, autoboxing is NOT working with this approach, as the
> compiler generates a Integer.valueOf(int) which did not exist in <=1.4.
> I'll need to invest some more time here looking for a workaround.
You can tweak the compiler code generation in this case to use something
compatible on a 1.4 VM.
--
Olivier
Re: Source 5.0, Target < 5.0 ? [message #216755 is a reply to message #216548] Mon, 10 October 2005 17:15 Go to previous messageGo to next message
Eclipse UserFriend
I suppose we could add this for him. It feels a small and reasonable change.

"Olivier Thomann" <olivier_thomann@ca.ibm.com> wrote in message
news:di43et$fgj$1@news.eclipse.org...
> Oliver Masutti a
Re: Source 5.0, Target < 5.0 ? [message #216819 is a reply to message #216755] Tue, 11 October 2005 10:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: olivier_thomann.NOca.ibm.comSPAM

Philippe Mulet a écrit :
> I suppose we could add this for him. It feels a small and reasonable change.
You want us to change the code gen of boxing/unboxing to use methods
available in 1.4?
--
Olivier
Re: Source 5.0, Target < 5.0 ? [message #216914 is a reply to message #216819] Wed, 12 October 2005 05:03 Go to previous messageGo to next message
Eclipse UserFriend
Olivier Thomann wrote:

> Philippe Mulet a écrit :
>> I suppose we could add this for him. It feels a small and reasonable change.

great idea ;-). Especially since I don't seem smart enough to do the
change myself. I was trying to find a workaround in
generateBoxingConversion(int) using the detour over
invokeStringValueOf(int typeID). (whether this is efficient is different
question). can someone help?

> You want us to change the code gen of boxing/unboxing to use methods
> available in 1.4?

If I'm looking at the correct code (CodeStream), UNboxing should already
be backwards compatible (eg. Integer.intValue()).

It feels like a reasonable change since you do this in other locations as
well, e.g. use StringBuilder or StringBuffer for String concatenation.
Shall I add a feature request in bugzilla?

- ollie
Re: Source 5.0, Target < 5.0 ? [message #216936 is a reply to message #216914] Wed, 12 October 2005 10:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: olivier_thomann.NOca.ibm.comSPAM

Oliver Masutti a écrit :
> great idea ;-). Especially since I don't seem smart enough to do the
> change myself. I was trying to find a workaround in
> generateBoxingConversion(int) using the detour over
> invokeStringValueOf(int typeID). (whether this is efficient is different
> question). can someone help?
I'll have a look at the code gen in this case to see if I can change it
according to the target value. So in target 1.5, it would do what is is
doing right now and in target 1.4, it would use 1.4 methods.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=107783

> It feels like a reasonable change since you do this in other locations
> as well, e.g. use StringBuilder or StringBuffer for String
> concatenation. Shall I add a feature request in bugzilla?
Sounds doable. I need to see what is available in 1.4 to do the boxing
conversion.
--
Olivier
Re: Source 5.0, Target < 5.0 ? [message #217124 is a reply to message #216936] Sun, 16 October 2005 16:21 Go to previous messageGo to next message
Eclipse UserFriend
> I'll have a look at the code gen in this case to see if I can change it
> according to the target value. So in target 1.5, it would do what is is
> doing right now and in target 1.4, it would use 1.4 methods.

after lots of trial&error, this seems to do the job:
case T_int :
if ( this.targetLevel >= JDK1_5 ) {
this.invoke(
OPC_invokestatic,
1, // argCount
1, // return type size
ConstantPool.JavaLangIntegerConstantPoolName,
ConstantPool.ValueOf,
ConstantPool.IntIntegerSignature); //$NON-NLS-1$
} else {
newWrapperFor( unboxedTypeID );
dup_x1();
swap();
this.invoke(
OPC_invokespecial,
1, // argCount
0, // return type size
ConstantPool.JavaLangIntegerConstantPoolName,
ConstantPool.Init,
ConstantPool.ExitIntSignature); //$NON-NLS-1$
}
break;

I'll have to do some more testing and also handle the other base types. I
assume short, float etc. will be easy, whereas double and long will
require some slightly different behaviour.

- ollie
Re: Source 5.0, Target < 5.0 ? [message #217155 is a reply to message #217124] Mon, 17 October 2005 08:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: olivier_thomann.NOca.ibm.comSPAM

Oliver Masutti a écrit :
> after lots of trial&error, this seems to do the job:
> case T_int :
> if ( this.targetLevel >= JDK1_5 ) {
> this.invoke(
> OPC_invokestatic,
> 1, // argCount
> 1, // return type size
> ConstantPool.JavaLangIntegerConstantPoolName,
> ConstantPool.ValueOf,
> ConstantPool.IntIntegerSignature); //$NON-NLS-1$
> } else {
> newWrapperFor( unboxedTypeID );
> dup_x1();
> swap();
> this.invoke(
> OPC_invokespecial,
> 1, // argCount
> 0, // return type size
> ConstantPool.JavaLangIntegerConstantPoolName,
> ConstantPool.Init,
> ConstantPool.ExitIntSignature); //$NON-NLS-1$
> }
> break;
Thanks for this code. I'll have a look.
--
Olivier
Re: Source 5.0, Target < 5.0 ? [message #217163 is a reply to message #217155] Mon, 17 October 2005 09:54 Go to previous messageGo to next message
Eclipse UserFriend
>> ConstantPool.ExitIntSignature); //$NON-NLS-1$

Shite. I'm afraid I made a mistake. This last line should read
"ConstantPool.IntConstrSignature";

>> }
>> break;
> Thanks for this code. I'll have a look.

Thank you! I made the other primitve types, including 'long' and 'double',
work as well in the meantime, so I could provide you a patch (or a whole
listing for copy&pasting) which should fix all cases.

Ciao!
- ollie
Re: Source 5.0, Target < 5.0 ? [message #217171 is a reply to message #217163] Mon, 17 October 2005 10:52 Go to previous message
Eclipse UserFriend
Originally posted by: olivier_thomann.NOca.ibm.comSPAM

Oliver Masutti a écrit :
> Thank you! I made the other primitve types, including 'long' and
> 'double', work as well in the meantime, so I could provide you a patch
> (or a whole listing for copy&pasting) which should fix all cases.
Attach your patch to the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=107783
I'll check it anyway.
--
Olivier
Previous Topic:Filtering in 'Open Type' dialog
Next Topic:Running single ant target
Goto Forum:
  


Current Time: Fri Jul 25 01:50:29 EDT 2025

Powered by FUDForum. Page generated in 0.14516 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top