> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED]
<snip/> > > Some things to note about targeting a different JDK: > * rt.jar is not enough - JDKs provide a number of other classes in extra > libraries, and it isn't called rt.jar on some platforms. In fact, this actually varies from vendor to vendor on the same platform. For example, the Harmony ClassLibrary is separated into about a dozen "module" JARs for both Windows an Linux. [1] None of which is named "rt.jar". [1] http://people.apache.org/dist/incubator/harmony/snapshots/ > * -source and -target are not enough (but still useful to target > something not installed) I think the problem that you're trying to point out with these two points is that the compiler settings alone are not enough to appropriately target a platform. You can setup your compiler settings for Java 1.4 compliant class files, but if the JDK you're using is a Java 5, then your code may inadvertently link to Java 5-specific APIs because that's what's in bootclasspath. A great example that always happens is when Java 1.3 code that's using StringBuffer.append() with a StringBuffer passed to append. If you're compiling against Java 1.3 libraries, this resolves to StringBuffer.append(Object) [2], but if you're compiling against Java 1.4/5/6, this resolves to StringBuffer.append(StringBuffer) [3]. Then when you run on a Java 1.3 JVM it blows up with a no method error. Eclipse 3.2's JDT takes an interesting approach to this by using the OSGi Execution Environment concept. There are a defined set of Execution Environments, such as J2SE-1.4, J2SE-1.5, CDC-1.0/Foundation-1.0, etc. Then, each configured JRE is associated with an Execution Environment that is can support and those that are "perfect matches". A similar concept could be used within Maven and setup in the user's settings to point to the various JDKs on the system. A project could then declare a target environment and Maven could use the best match and warn users of any inexact matches. The other piece that can be borrowed from Eclipse is the concept of plugging in JRE (JDK in Maven's case) configurations, so you can have a plugin for Sun JDKs, IBM JDKs, BEA JDKs, Harmony JDKs, etc. Sun, IBM and BEA currently follow the same "defacto" layout, but Harmony doesn't, so there's a Eclipse Plug-in for enable Harmony VMs as a JRE. An interesting side effect of taking an approach like this is that Maven 2.1 could require a Java 5 JRE to run, but could support any execution environment, as long as a JDK and the applicable plugins were available. -Nathan [2] http://java.sun.com/j2se/1.3/docs/api/java/lang/StringBuffer.html#append(jav a.lang.String) [3] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuffer.html#append(j ava.lang.StringBuffer) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
