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]
