On 9/30/05, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
> 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.
agreed. that's not totally reliable.
> 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.
not a huge fan of the potential confusion of two jars (wouldn't that
be four for us?), but if it worked for Turbine...
> 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".
i say we go with this option. at least, that's my first choice. for
my second, it'd be a tie between two (not 4) jars, and just putting
the JdkLogChute on the wiki. it'd be a bummer not to include it, but
since i don't actually intend to use it myself...
> 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]
