Brent,
Thanks for all the quick replies.
So what I hear you saying now, is that I won't be able to use M2 until
the compiler forking
feature is added. Bummer.
I was really hoping to avoid converting this codebase to M1, only to
have to conver the
build again to M2 soon thereafter. Please tell me if I've missed what
you are saying and
let me know what options I have for resolving this with the current
alpha-3 M2 release.
Thanks again for all the really great responses.
Derek
On 8/4/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Derek Lane <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Ok, I understand. We are only talking about the first one: because
> each new JVM changes the format of the classfiles. So setting -target
> 1.3 makes sure it writes the 1.3 class file format, so it can be read
> by 1.3 + (but you can't use 1.4 language features like assert).
>
> > 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.
>
> No, we just plan to support the properties Joerg mentioned - to fork a
> 1.3 javac to ensure you get what you are targetting.
>
> > I need to know if I have found another case like the
> > StringBuffer situation.
>
> Similar cause, but luckily you get it at compile time. The
> stringbuffer problem is that it compiles fine, but throws a
> NoSuchMethodException at runtime.
>
> > [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 {
>
> This is because the JDBC API changed in 1.4, so yes - this is a
> similar issue. I'm not sure if there is a workaround for this - you
> may find help on the Java site.
>
> > 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:
>
> This should just be warning about using an enum variable name, but
> there is a bug in the last release (since fixed) that interprets it as
> an error. If it got past this, you'd probably hit the same error as
> above.
>
> Hope this helps, and we'll certainly look into that forking compiler
> for the next release.
>
> - Brett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
