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  |
Eclipse User |
|
|
|
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  |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 #216306 is a reply to message #215950] |
Wed, 05 October 2005 06:35 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 #217124 is a reply to message #216936] |
Sun, 16 October 2005 16:21 |
| Eclipse User |
|
|
|
> 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 |
| Eclipse User |
|
|
|
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
|
|
| | |
Goto Forum:
Current Time: Sat Jul 26 12:39:15 EDT 2025
Powered by FUDForum. Page generated in 0.06240 seconds |
Home