Just to be clear, I am not suggesting the addition of any Java 9 or 10 features
to Tamaya. I suspect that it makes much more sense for the source code to
continue to target Java 8. I am just interested in making the source code
*buildable* on the newer JDKs.
> On Mar 6, 2018, at 3:07 PM, Werner Keil <werner.k...@gmail.com> wrote:
> 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.
Correct. If the source code itself targets Java 9 (e.g. with the
module-info.java file), then it becomes runnable only on Java 9+, unless you
make use of a Multi-Release JAR. And the Maven tooling for Multi-Release JARs
is still catching up (at least it was when I last checked into this).
> 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.
Yes, exactly. Quite a few Apache projects are staying on Java 8 at least until
there is another LTS version available (i.e. Java 11), and from the perspective
of making Tamaya easy to adopt in other projects, there are good arguments for
remaining on Java 8 for now.
> From: Aaron Coburn
> Sent: Tuesday, March 6, 2018 21:01
> To: firstname.lastname@example.org
> Subject: Re: Java 9 & 10
> 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
> For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both
>> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer <o.b.fisc...@swe-blog.net>
>> 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.
>> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>>> 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.
>>> Aaron Coburn