[
https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534760
]
Joerg Schaible commented on IO-127:
-----------------------------------
There's no magic involved here, it's simply the runtime library. Using a JDK 6
compiler to produce JDK 1.3 code does not hide the classes and methods of the
JDK 6 runtime library and the compiler does not check the version of the byte
code it compiles against. Obviously you're getting in trouble running the
result with a runtime lib of JDK 1.3 if you have used methods only available in
later Java versions, since they're simply missing. However there are two
pitfalls with such an approach:
1/ A programmer might use newer functionality without recognizing it. Typical
trap is e.g.
new RuntimeException("Rethrow", ex);
JDK 1.3's RuntimeException has no constructors taking a causing exception.
2/ The compiler selects a different overloaded method in a newer JDK. Prominent
example is
new StringBuffer(stringBuffer);
JDK 1.3's StringBuffer has only a constructor with a String, while in JDK 1.4
it also has a constructor taking a StringBuffer. Therefore compiling with a
newer JDK it will select the new constructor, while compiling with JDK 1.3 will
convert the argument first to a String before creating the StringBuffer.
Both problems can be avoided if we use a CI to compile the JDK 1.3 compatible
classes only with JDK 1.3. That's the way we do with XStream:
http://bamboo.ci.codehaus.org/browse/XSTREAM-JDK13. In XStream we even used a
two-phased compile step for JDK 5 dependent code (annotation, enums) and JDK
1.3 compatible source code. All is delivered in one artifact. Works quite well
now for years.
> Move to a minimum of JDK 1.4
> ----------------------------
>
> Key: IO-127
> URL: https://issues.apache.org/jira/browse/IO-127
> Project: Commons IO
> Issue Type: Task
> Reporter: Niall Pemberton
> Priority: Minor
> Fix For: 1.4
>
> Attachments: commons-io-jdk-1_3-check.patch
>
>
> There was a discussion a while back on moving Commons IO to a minimum JDK
> version of 1.4 - see [1] below. The majority view was this was a good idea.
> Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so
> that, apart from new JDK 1.4 dependant features, Commons IO would still
> operate under JDK 1.3. This seems like a good idea and resolves the issue of
> whether this would require a major version change.
> There was also a view that we should move to JDK 1.5 instead - I have no
> issue with that, but would advocate that theres no point in doing so until
> there are people wanting to commit JDK 1.5 dependant features.
> This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has
> been created for anyone still desiring future JDK 1.3 only releases.
> [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL
> PROTECTED]
> [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
