Well, after some googling, my brain came out of deprecation mode and I
actually found the reference I was looking for:
JDK 1.3.1 contains
public class StringBuffer {
public void append(Object o) {...}
}
and then JDK 1.4.2 went ahead and added
public class StringBuffer {
public void append(StringBuffer sb) {...}
public void append(Object o) {...}
}
So compiling the source code works on both JDK 1.3 and JDK 1.4 but if
you compiled on 1.4, a sb.append(anotherStringBuffer) would be mapped to
append(StringBuffer sb) and that would bomb out with a
MethodNotFoundException on a 1.3 JRE.
I neither know whether this bug would affect Velocity nor if there are
other changes like this in JDK 1.3 -> 1.4. Datapoint: If I compile the
classes using JDK 1.4.2 and then run the unit tests on 1.3.1 it works
fine. But as we don't have 100% code coverage, I wouldn't rely on that.
One possible way to go here would be to add another compile test as we
did for javax.sql.DataSource and only compile the JDK 1.4 logging if JDK
1.4 is present. And then release two jars sets for Velocity 1.5, one for
Java 1.3, one for Java 1.4/1.5. We did this for Turbine 2.3.1 and it
worked well.
Another alternative would be to state "runs under JDK 1.4, might run
under JDK 1.3, if you want to be sure, grab the source and recompile the
jar".
Best regards
Henning
On Thu, 2005-09-29 at 15:59 -0700, Nathan Bubna wrote:
> On 9/29/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
> > "Will Glass-Husain" <[EMAIL PROTECTED]> writes:
> >
> > >------=_NextPart_000_0035_01C5C4E8.0EFF3430
> > >Content-Type: text/plain;
> > > charset="iso-8859-1"
> > >Content-Transfer-Encoding: quoted-printable
> >
> > >Hi,
> >
> > >Nathan's proposed adding a compile time requirement for JDK 1.4. (as =
> > >part of VELOCITY-403).
> >
> > >This would allow us to use include JDK 1.4 features (like JDK logging) =
> > >as pluggable options. Velocity would still run under JDK 1.3 as long as =
> > >the feature was pluggable and not the default (like JDK Logging).
> >
> > Hm. I'm not really sure about this. There _are_ known
> > incompatibilities with JDK 1.4 compiled jars under 1.3.
>
> really? hmm. i hadn't heard this. what's the nature of the
> incompatibilities? i'm just curious if this is something that our
> users who still run 1.3 and yet want to upgrade to 1.5 (probably not
> too many, but i'm sure there will be some) will actually run into if
> one of their libraries is compiled with jdk1.4.
>
> > However, the only other package that implements JSR47 for JDK 1.3 that
> > I know of (Lumberjack Logging) is LGPL, so it is out of the question
> > to use for compiling. :-(
> >
> > I do see the advantage of having JDK 1.4 logging in Velocity 1.x. I
> > know that JDK 1.3 is pretty outdated and no one should use it. But I'm
> > scared to go to JDK 1.4 here, because our users will expect Vel 1.5 to
> > be a drop in replacement for 1.4.
>
> yeah, but if JDK 1.4 compiled stuff doesn't run reliably on JDK 1.3,
> then time is getting pretty short for JDK 1.3 users who want to keep
> upgrading their open source libraries. i see more and more moving to
> 1.4 or 1.5/5 (at least for compile-time, if not runtime) all the time.
> they really should upgrade their JDK.
>
> > >I'm okay with doing this as long as we're careful. Any other comments?
> >
> > I'm basically -0 on this but I'd like to hear more opinions. It (on a
> > different level) the same issue as with having a javax.sql.DataSource
> > dependency (with the difference that there is a jdbc-2.0.jar for JDK
> > 1.3).
> >
> > Best regards
> > Henning
> >
> > --
> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
> >
> > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> > Linux, Java, perl, Solaris -- Consulting, Training, Development
> >
> > 4 - 8 - 15 - 16 - 23 - 42
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
