Thanks, Michael for the clarification. I agree to all your points.
On Fri, May 8, 2009 at 11:43 PM, Michael Glavassevich <[email protected]> wrote: > 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. > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [email protected] > E-mail: [email protected] -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
