What I was trying to differentiate WRT options A and B, is that in one
case the the problem
was the generated code not being what acceptable to the JVM, and the
other case is when
the JVM was not quite compliant with the spec (probably due to some
vendor specific
compiler enhancement). I don't know if that clarified my intent, but
from your response it
doesn't appear to be the real cause of the problem.
So now I think I understand you to be saying that the compiler plugin
will be enhanced
in the future to better accomodate the differences between JDK
versions, using whatever
method is deemed appropriate for each situation, such as the casting
situation with
StringBuffer you referred to.
Ok, so back to my original problem. Now that we have established that
the 1.4 compiler
is generating 1.3 code, <it would be nice to have some verification of
that BTW in the debug output or something>, but that the generated
code may have some problems running in
the 1.3 JVM, I need to know if I have found another case like the
StringBuffer situation.
The existing codebase compiles and runs fine using JDK 1.3 and Ant.
However, here's what
I am seeing when using M2:
I) If I set my JAVA_HOME to 1.4 and tell M2 to generate 1.3 code, I
get this error
[INFO] Reason: Compilation failure
[INFO] -------------------------------------------------------------------------
---
[INFO] no more tokens - could not parse error message:
C:\src\mavenbuild\<truncated>\sql\PreparedStatementFacade.java:42:
com.<truncated>.sql.PreparedStatementFacade is not abstract and does
not override
abstract method getParameterMetaData() in java.sql.PreparedStatement
public class PreparedStatementFacade implements PreparedStatement {
II) If I set my JAVA_HOME to 1.5 and tell M2 to generate 1.3 code, and
rerun the same M2 command I get this error:
[INFO] Reason: Compilation failure
[INFO] -------------------------------------------------------------------------
---
[INFO] no more tokens - could not parse error message:
C:\src\mavenbuild\<truncated>\soapclient\CoverType.java:31: warning:
as o
f release 1.5, 'enum' is a keyword, and may not be used as an identifier
(try -source 1.5 to use 'enum' as a keyword)
CoverType enum = (CoverType)
This is using the exact same POM, same command line same everything.
The only thing
that changed is the JAVA_HOME setting before running "m2 verify". BTW,
I did try it in
another command line to verify there wasn't something in the env.
causing problems. I also
tried using JDK 1.5 before 1.4 and get the same error.
So, am I dealing with the same JVM versioning quirks as the
StringBuffer problem? Or am
I experiencing some other form of the Twilight Zone? <music begins...>
Please advise.
Thanks, Derek
On 8/4/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Derek Lane <[EMAIL PROTECTED]> wrote:
> > In my case, I have specified to the 1.4 compiler that I want it to
> > generate code that
> > will run in a 1.3 JVM. How am I doing so far?
>
> Correct.
>
> > A) In some circumstances, based on the specific 1.3 runtime JVM, the
> > code generated by the 1.4 compiler will not successfully run?
>
> Yep. It's not the JVM that is the problem, but the runtime class
> libraries (rt.jar).
>
> The most prevalent example:
> http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200506.mbox/[EMAIL
> PROTECTED]
>
> if you append a stringbuffer, the code compiles in both 1.4 and 1.3,
> but when compiled on 1.4 it won't run on 1.3 (because append
> StringBuffer doesn't exist), unless you cast to (Object).
>
> >
> > B) In some cases, based on the code generated by the 1.4 compiler, the
> > generated code will not successfully run in a 1.3 JVM?
>
> I don't see this as different to A?
>
> > C) There is a bug in the M2 compiler plugin that will be fixed at some
> > point, that will enable A dn/or B to work?
> >
>
> Not so much a bug, but a missing feature. To run the other compiler,
> we need to be able to fork the javac executable in a completely
> different path to the executing JDK.
>
> - Brett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
