| ANT and JDK classpath for ANT based compilations [message #30060] |
Mon, 19 May 2003 15:27  |
Eclipse User |
|
|
|
Hi there,
I just recognized a problem with the JDK classpath used during ANT based
compilations. I'm running eclipse itself with jdk 1.4.1 (the IDE startup)
but have jdk 1.3.1 based application projects (using the preferences from
Java/Installed JREs). Despite having set ANTs runtime classpath explicitly
to the jdk1.3.1 jars, compilation runs seem to mix with classes from the jdk
1.4.1 (the JRE under which the eclipse IDE itself is running). Application
classes with direct reference to jdk classes/interfaces (i.e. through
inheritance) get a different serial version UID when compiled from within
eclipse (where the preferences configured JRE with jdk 1.3.1 is used)
compared to the class files which are created when I compile through ANT
scripts (invoked with the eclipse ANT runner, of course with the
JDTCompilerAdapter correctly set).
When I start the Eclipse IDE with a 1.3.1 JRE as well, the "normal" eclipse
compile and the compile with ANT scripts through the eclipse ANT runner
produce identical class results with identical serial version UID (which is
what we need). For other reasons, I normally need to run the Eclipse IDE
with jdk 1.4.1 but still have to work on application projects under jdk
1.3.1.
This currently prevents using the eclipse ANT runner when the eclipse IDE
and the application projects have to be based on different jdk's.
The problem is new since eclipse 2.1. - we did the same things (mixing IDE
used jdk 1.4.1 and "Installed JREs "settings jdk 1.3.1) with eclipse 2.0 and
the related ANT runner without any problem (always had identical classes
from compilations with both compilation methods)!
Have I overlooked a 2.1. parameter or preferences setting or any other idea?
Thanks for feedback.
Regards
Andreas
|
|
|
|
|
|
|
|
| Re: ANT and JDK classpath for ANT based compilations [message #35948 is a reply to message #34945] |
Thu, 22 May 2003 17:19  |
| Eclipse User |
|
|
|
You found it meanwhile as I've seen on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37940
For all others who may be interested in this case, please look at the above
bug link - there is a solution through setting the javac target parameter to
"1.1" or adapting the eclipse preferences as explained in comments No. 6/7
within above bug link.
Many thanks to all who helped!
Andreas
"Philippe Mulet" <philippe_mulet@fr.ibm.com> schrieb im Newsbeitrag
news:bai3np$4dh$1@rogue.oti.com...
> Did you enter a bug report for further investigation ?
>
> "Zimmer" <zitecs@t-online.de> wrote in message
> news:bagici$1vf$1@rogue.oti.com...
> >
> > "Dave Wegener" <wegener@cboenospam.com> schrieb im Newsbeitrag
> > news:bag3a9$k60$1@rogue.oti.com...
> >
> > > You can only serialize classes that implement the java.io.Serializable
> > > interface. Are you able to compile the class that is implementing the
> > > marker interface seperately from the rest of your project. If not,
you
> > > can try to strip it down so that it doesn't depend on any other
classes.
> > > The serialVersionUID is computed at run time based on the
> characteristics
> > > of the .class file. Different compilers will produce different .class
> > > files. The algorythm used by the runtime VM to calculate the
> > > serialVersionUID uses elements of the class file that are likely to be
> > > different for different compilers. This produces the incompatible
> > > serialVersionUIDs. This is a known limitation of using the runtime VM
> to
> > > calculate serialVersionUIDs. The best solution is to explicitly add
the
> > > serialVersionUID field to each of your serializable classes.
> > >
> > Well, we're just implementing java.io.Serializable for the purpose to
make
> > the class serializable. Because the problem class is only one example
and
> I
> > still believe the underlying Problem belongs to any class with
references
> > into the jdk, explicitly setting serialVersionUID is not a solution.
I've
> > isolated the problem to the one sample problem class which implements
> > Serializable and the problem can now be easily reproduced by compilng
just
> > this one class. See my additional comments later on ...
> >
> > > However, a given compiler should always produce compatible class
files.
> > > If the classes compiled within Eclipse produce different IDs than
> classes
> > > compiled with and ant script using the JDTCompilerAdapter, it would be
a
> > > bug and you should submit a bug report with a reproducable test case.
> > >
> > I most probably have to do so - the reproducable test case is now
> > available - the problem persists.
> >
> > >
> > > You can use the command line tool serialver to compute the
> > > serialVersionUID for a given class. You can use this to compare the
IDs
> > > obtained when compiling using different JDKs to start Eclipse.
> > >
> > > Start Eclipse up with a 1.3.1 VM and use the internal compiler to
> compile
> > > the class. Run serialver against the class. Run the ant build script
> to
> > > compile the file. Re-run serialver to compare results. Stop Eclipse
and
> > > restart it. Repeat the steps.
> > >
> > Done. The serialVersionUIDs differ when I compile with the Eclipse
> internal
> > compiler compared to the class from the compile run through ANT.
> > JDTCompilerAdapter correctly set and used (also according to your
> > explanation below). The different serialVerionUIDs only happen, if I
start
> > eclipse IDE with jdk1.4.1 and have an application project JRE setting in
> the
> > eclipse preferences to JRE 1.3.1. If eclipse startup and preferences JRE
> > setting is both on jdk1.3.1 everything's fine and serialVersionUIDs are
> > identical.
> >
> > >
> > > Are you sure that the ant script is using the JDTCompilerAdapter. If
> you
> > > look at the output in the Debug view, the JDTCompilerAdapter produces
> > > different messages than the standard javac compiler.
> > >
> > > On my system the javac compiler only displays the number of classes
> being
> > > compiled. The adapter displays additional lines indicating how many
> lines
> > > were compiled and how long the compile took.
> > >
> > Checked again and definitely OK.
> >
> >
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04980 seconds
Home