Hi Mukul, Mukul Gandhi <[email protected]> wrote on 05/08/2009 12:20:47 PM:
> On Fri, May 8, 2009 at 9:28 PM, Hiranya Jayathilaka > <[email protected]> wrote: > > All the newly developed systems will run on new JREs. Such > applications can surely harness > > the power of our improved code base. But the important thing is to keep > > supporting our users on old JREs. > > I have a feeling, at this point of time we must support JDK 1.3 users. > We also need to take care that Xerces should run on JRE 1.6 also, as > all new developments now take place on JDK 1.5 and above. > > We as Xerces developers, need to be careful while using APIs, in a > sense that the APIs we use should be available in all JDKs from 1.3 > upto 1.6. There's a difference between producing releases which work on Java 6 and releases which *only* work with Java 6. Xerces releases today work on every Java release: 1.3 and above (including Java 6). What I think we've been discussing in this thread is the possibility of creating (from a branch perhaps) releases of Xerces targeted specifically for Java 5 and 6, presumably to exploit features only available in those Java releases. This would be in addition to having the Java 1.3 based release we have today. I see nothing particularly wrong with that, though think it would be wise to discuss this with the larger community before making any decisions. We also need to consider that a large number of users (possibly the majority) never download Xerces directly but get it bundled in some other package: Xalan, FOP, Forrest, Ant, Axis2, Geronimo, Harmony, Eclipse, JBoss, etc... and that leapfrogging the JDK requirements of the bundling applications may severely limit the distribution of these Xerces releases, especially if they require Java 6. I agree with Ludger about not moving to higher levels of Java unless we actually have a need to. We shouldn't just be doing it just for the sake of it being newer or having a long list of new features (many of which probably aren't even relevant to this project). Before heading down this path we should have an idea of what capability we think we need to use, and I think for those features we would need a compelling case for using them that would benefit our users. The other day I came across an application that would have otherwise ran on Java 5 but can't because it's using java.lang.String.isEmpty(), a method that was only introduced in Java 6. In my opinion, that's not a good reason to have a Java 6 dependency (String.isEmpty() vs. String.length() == 0). So I think we should wait until think we have a case for using newer APIs and then evaluate at that point, rather than jumping to a later release on a branch without a particular reason for doing so. > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected]
