[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi All,
If we do stay on java8 it is still important to change the javac invocation.
There is now a flag called release and if set to "8" then it is not just
language features but also making sure you don't use methods not in JDK8
etc...
While officially it is not in javac8 it will just generate a warning in
the recentish builds.
On the other hand, the choice for java8 and java11 does not need to be
fully exclusive there are Multi-Release jars now.
https://www.javaworld.com/article/3184029/java-9s-other-new-enhancements-part-4-multi-release-jar-files.html?page=2
Not sure how hard that will be to maintain and test.
On the other hand Java11 is now relatively widely available e.g. in
RedHat 7.6+ and the people building and using triplestores are somewhat
less "legacy" bound than average. That it might be an idea to shift to
11 for 3. Especially considering how long you might want to support the
3 branch. Do you really want to miss out on the improvements for an
other 2 years?
Regards,
Jerven
On 3/6/19 12:30 PM, Håvard Ottestad wrote:
I presume Streams from java 8 weren’t very compatible with java 7.
Could we do a 3.0 release with java 8 and maintain it as a 3.x for a year, back-porting as much as possible. And make 4.0 a java 11 version.
If we release 3.0 by june, and 4.0 by september it would then be 2 years since the release of java 9.
Håvard
PS. reasoning behind 4.0 and not 3.1 is that we have semantic versioning, so the number has nothing to do with release cadence or feature set and only dependant on backwards compatibility. Change on method signature to return an optional instead of a null and boom, new major version.
On 6 Mar 2019, at 11:14, Bart Hanssens (BOSA) <bart.hanssens@xxxxxxxxxxxx> wrote:
There's a reason we had a java7 backport for a while... 😊
Bart
-----Original Message-----
From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> On Behalf Of Håvard Ottestad
Sent: woensdag 6 maart 2019 11:09
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: Re: [rdf4j-dev] Java > 8
I see. That sucks. So if we move to java 11, and start using any of the new features, then we exclude those still stuck on 8. And “those still stuck on 8” is probably 100% of our users.
Would still really like to move to java 11. At the moment though I’ve got a bit disheartened with just getting rdf4j to compile on java 9, stuck on some javadocs complaints about elasticsearch.
Håvard
On 6 Mar 2019, at 10:52, Bart Hanssens (BOSA) <bart.hanssens@xxxxxxxxxxxx> wrote:
Hi,
Well, simply fiddling with source and target in maven won't cut it
according to the maven docs because of some APIs not available anymore
/ not yet available :-/
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-co
mpiler-source-and-target.html
Also, I guess that new language constructs (like 'var') in code are
not automatically converted when targeting older JDKs, but merely
flagged as incompatible (haven't checked...)
The docs do mention the AnimalSniffer maven plugin, which is already
included in the RDF4J poms, but I'm not sure if it also checks for things like Java9+ modules.
Best regards
Bart
-----Original Message-----
From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> On
Behalf Of Håvard Ottestad
Sent: woensdag 6 maart 2019 10:31
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: Re: [rdf4j-dev] Java > 8
Do you know how Java handles it if we use 11 and start using newer language features and new classes/methods? Will users using java 8 not be able to use rdf4j?
Håvard
On 6 Mar 2019, at 10:20, Bart Hanssens (BOSA) <bart.hanssens@xxxxxxxxxxxx> wrote:
Hi Håvard,
Ah yes, starting with 9, JAXB is part of EE instead of SE, and IIRC removed completely from JavaEE in 11...
I've created a ticket for JDK 11 LTS support, but I'm not sure we
should jump to 11 as default
Perhaps ask for input on the rdf4j-users mailing list, and more
specifically the companies (Ontotext, Semantic Web Company...),
because at least on Redhat OpenJDK 8 will be supported until june
2023, and organizations might be reluctant to "already" upgrade to
JDK
11
If that would indeed be the case, then we would still need to check if the JDK-11-by-default builds on JDK 8...
(of course, now we have to check if JDK-8-by default builds on
JDK-11, Law of Conservation of Issues at work...)
Best regards
Bart
-----Original Message-----
From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx>
On Behalf Of Håvard Ottestad
Sent: woensdag 6 maart 2019 9:55
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: [rdf4j-dev] Java > 8
Hi,
I was wondering if maybe it was time to leave behind java 8 in our next 3.0 release? By “leave behind” I mean, make default development on java 11, the latest LTS version.
The reason I bring it up is because maven will currently only build java on version 8. When I use java 9 I get the following error:
[ERROR] Failed to execute goal
com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default)
on project rdf4j-sail-api: Execution default of goal
com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp failed: A
required class was missing while executing
com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp:
javax/xml/bind/JAXBException
I believe the reason I’m seeing this error is mainly because we (developers) are probably all using java 8 and jenkins is also using java 8. So no one is really bothered by old plugins without java > 8 supports.
Wrt. jenkins, what are the chances that eclipse supports java 11?
Any thoughts?
Cheers,
Håvard
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev
