Actually a Multi-Release JAR if we found that useful (with a new JDK every 6 
months it seems tempting or even inevitable) is not built with Java 9 or 10, 
the plugin states it should be with Java 8, but thanks to the Multi-release 
feature and META-INF it’ll work with different versions. 

I am not sure, how it deals with e.g. a class that relies on entirely new 
language Features of Java 10 or 11 like „var“ etc. that someone has to find 
out. I tried to build JARs with a module-info under JDK9 and it would no longer 
run on a JVM before Java 9. 

I don’t think we want to be trapped in a Java „Version-Hell“ so at least Java 8 
should still work for some time as the Minimum Version.

Werner

From: Aaron Coburn
Sent: Tuesday, March 6, 2018 21:01
To: dev@tamaya.incubator.apache.org
Subject: Re: Java 9 & 10

Hi,

Travis-CI currently supports Java 9 builds, which would be simple to add to the 
current .travis.yml configuration. It is possible to test Java 10 on Travis but 
it requires some acrobatics (find the latest EA version by parsing some HTML, 
download the JDK artifact and then install it). Including CI support for JDK 10 
is most likely not worth the effort in the context of Travis.

For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both 
available: 
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix 
<https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix>

Regards,
Aaron

> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o.b.fisc...@swe-blog.net> 
> wrote:
> 
> Hi Aaron,
> 
> as far I know we don't have any CI job for Java 9 or 10. So it would be 
> difficult to maintain such changes without breaking it.
> 
> I could check Apache's Jenkins if both JDK versions available on Jenkins.
> 
> Best,
> Oliver
> 
> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>> Hi,
>> I am a bit new to Tamaya, so apologies if this has already been discussed. 
>> It is clear that the codebase targets Java 8. It is also entirely _usable_ 
>> on newer (jdk9 & jdk10) platforms. However, it is not currently possible to 
>> build Tamaya on jdk9 or jdk10. My first question is: should it be possible 
>> to build Tamaya on the latest JDK?
>> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. 
>> In particular, some Java EE libraries are no longer on the classpath by 
>> default: javax.xml.bind and javax.activation. With jdk10, these libraries 
>> will no longer be included in the Java SE at all. Adding those dependencies 
>> directly to the plugin configuration or upgrading to the latest (milestone) 
>> Karaf release makes it possible to build on jdk9.
>> Building on jdk10 has the additional problem of the javadoc plugin not being 
>> able to parse the JVM version string with commons-lang 3.5 release. Forcing 
>> the use of commons-lang 3.7 for the plugin solves that.
>> Is this something you all would like to support? I can provide a pull 
>> request for that.
>> The other, related, issue has to do with the Java 9 module system (JSR-376). 
>> Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly 
>> simple thing that can be done to make the Tamaya codebase easier to use with 
>> the Java 9 module system. Basically, it involves adding a 
>> "Automatic-Module-Name: <module-name>" entry in the MANIFEST.MF file. 
>> Practically, this means adjusting the various bnd.bnd files in the codebase. 
>> For instance, the tamaya-core JAR would likely have a module name of: 
>> org.apache.tamaya.core (typically, this would align with the existing OSGi 
>> Export-Package). The tamaya-api JAR currently exports two packages (o.a.t 
>> and o.a.t.spi), so perhaps the module name would simply be 
>> org.apache.tamaya? I suspect that the various extensions would make use of 
>> the current OSGi export naming convention for this, as with tamaya-core. If 
>> this is something you'd like to have for the 0.4 release, I can also supply 
>> a pull request for that.
>> Also, I am happy to open JIRA issues for either or both of these items, 
>> though I wasn't sure if you'd like to discuss either of these first.
>> Thanks,
>> Aaron Coburn


Reply via email to