Re: Single JDK14 compile model? (patch attached)

[Andrew McIntyre <mc...@gmail.com>]

On Mar 6, 2005, at 7:50 AM, Daniel John Debrunner wrote:

> No, we require the class files modified to be sub-classed (see my other
> long e-mail from this morning) and there is no issue with it.

For some reason I had it in my head that any subclass would know that 
its superclass was abstract, and that subclassing a class that was once 
abstract, but now concrete, would lead to problems. This is not the 
case, of course, since the subclass has no record of the superclass' 
abstract status.

Attached is a patch to build with JDK 1.4.2 only. This works as 
expected when running under JDK 1.4.2. However, when I attempt to use 
the jars created with this build with JDK 1.3.1, I get a 
NoSuchMethodError on a select (create table and insert works fine). 
What have I missed here?

andrew

Re: Single JDK14 compile model? (patch attached)

[Jeremy Boynes <jb...@apache.org>]

Andrew McIntyre wrote:
> 
> On Mar 8, 2005, at 6:00 AM, Jeremy Boynes wrote:
> 
>> I ran into something similar where by compiling under 1.4 one of the 
>> classes in ij uses the new StringBuffer.append(StringBuffer) method.
>>
>> Here's how I fixed it in the mavenized version.
>> <snip>
> 
> 
> Yep! That fixed the problem. Thanks, Jeremy!
> 
> With the addition of that snippit, the jars built with the previous 
> patch using jdk142 only (compiled with javac on Mac OS X, btw), work on 
> jdk131 as well.
> 

NP. I'm still not keen on the class file modification approach though.

--
Jeremy

Re: Single JDK14 compile model? (patch attached)

[Andrew McIntyre <mc...@gmail.com>]

On Mar 8, 2005, at 6:00 AM, Jeremy Boynes wrote:

> I ran into something similar where by compiling under 1.4 one of the 
> classes in ij uses the new StringBuffer.append(StringBuffer) method.
>
> Here's how I fixed it in the mavenized version.
> <snip>

Yep! That fixed the problem. Thanks, Jeremy!

With the addition of that snippit, the jars built with the previous 
patch using jdk142 only (compiled with javac on Mac OS X, btw), work on 
jdk131 as well.

andrew

Re: Single JDK14 compile model? (patch attached)

[Jeremy Boynes <jb...@apache.org>]

Andrew McIntyre wrote:
> 
> On Mar 6, 2005, at 7:50 AM, Daniel John Debrunner wrote:
> 
>> No, we require the class files modified to be sub-classed (see my other
>> long e-mail from this morning) and there is no issue with it.
> 
> 
> For some reason I had it in my head that any subclass would know that 
> its superclass was abstract, and that subclassing a class that was once 
> abstract, but now concrete, would lead to problems. This is not the 
> case, of course, since the subclass has no record of the superclass' 
> abstract status.
> 
> Attached is a patch to build with JDK 1.4.2 only. This works as expected 
> when running under JDK 1.4.2. However, when I attempt to use the jars 
> created with this build with JDK 1.3.1, I get a NoSuchMethodError on a 
> select (create table and insert works fine). What have I missed here?
> 
> andrew
> 

I ran into something similar where by compiling under 1.4 one of the 
classes in ij uses the new StringBuffer.append(StringBuffer) method.

Here's how I fixed it in the mavenized version.

--
Jeremy

Index: 
modules/tools/src/main/java/org/apache/derby/tools/JDBCDisplayUtil.java
===================================================================
--- 
modules/tools/src/main/java/org/apache/derby/tools/JDBCDisplayUtil.java 
     (revision 156382)
+++ 
modules/tools/src/main/java/org/apache/derby/tools/JDBCDisplayUtil.java 
     (working copy)
@@ -556,7 +556,7 @@
                                 for (int k=blanks.length(); k<w; k++)
                                         blanks.append(' ');

-                               buf.append(blanks);
+                               buf.append((Object)blanks);
                                 // REMIND: could do more cleverness, 
like keep around
                                 // past buffers to reuse...
                         }

Re: Single JDK14 compile model? (patch attached)

[Daniel John Debrunner <dj...@debrunners.com>]

Andrew McIntyre wrote:

> Attached is a patch to build with JDK 1.4.2 only. This works as expected
> when running under JDK 1.4.2. However, when I attempt to use the jars
> created with this build with JDK 1.3.1, I get a NoSuchMethodError on a
> select (create table and insert works fine). What have I missed here?

This is basically what I was doing. Were you using jikes or javac? Jikes
1.14 has some issues, in that it creates abstract methods in an abstract
class from its declared interfaces. This was fixed by jukes 1.22 though
from their change history I couldn't see any explanation for the change
in the Jikes release files. I sent a query to the jikes list asking for
clarification around this issue.

Dan.