I'd solve your problem like this, Mark:
- Create an interface for a component, which is internally using the
JDK code in question, (say IRTUser).
- Create three implementations, each of which are targeting a
particular JDK. In what follows, I'll assume that they throw an
exception when being instantiated on the wrong JDK.
- Ideally, these implementations must be compilable with different
JDK'S. (If required, use Java reflection internally to find the right
methods, etc. (The above method would be a MethodNotFoundException, or
the like.)
- Have a factory class, with code like the following:
private static final IRTUser instance = newRTUser();
private static IRTUser newInstance() {
try {
return new JDK18RTUser();
} catch (Throwable t0) {
try {
return new JDK17RTUser();
} catch (Throwable t1) {
return new JDK16RTUser();
}
}
public static IRTUser getInstance() { return instance; }
This approach has worked fine for me on multiple occasions.
Jochen
On Thu, Nov 27, 2014 at 9:39 PM, Mark Struberg <[email protected]> wrote:
> Hi!
>
> Today I had a discussion with Robert about how we can solve a problem I had
> over at Apache OpenWebBeans:
>
> https://issues.apache.org/jira/browse/OWB-952
>
> As a short summary: the classes provided in rt.jar of Java8 are slightly
> different than the ones from Java7 and 6. Similar big differences have been
> seen in the Java4 to 5 transition.
> Thus if you compile your project with Java8 you might get different bytecode
> than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.
>
> There are 2 options: either use javac -bootclasspath and point it to the
> 'correct' rt.jar + other jdk libs, or just switch the whole environment.
>
> Roberts suggestion was to use the Maven Toolchain
> system:http://maven.apache.org/plugins/maven-toolchains-plugin/
> http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html
>
>
> We also elaborated about improving the Toolchain lookup in our
> maven-compiler-plugin:
> http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#427
>
> This could get improved to first check if a toolchain is registered for the
> <target> version used in the m-compiler-p. And if there is no toolchain
> configured especially for this version then we fallback to the one if we
> don't specify a version.
> The effective lookup path would then be
> 1.) toolchain configured via maven-toolchain-plugin
> 2.) toolchain with specified target version
> 3.) default toolchain
>
>
> I think we would need to slightly enhance the ToolchainManager, but first
> would like to get some feedback.
>
>
> LieGrue,
> strub
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
Our time is just a point along a line that runs forever with no end.
(Al Stewart, Lord Grenville)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
