Java 11 #3

kaifox · 2019-06-19T18:59:04Z

Hi guys, this is a branch which makes the thing compatible with java 11 (and has to be released with java 11 as in Fontawesome there are already class files of version 55.

I would need a release of this version for my demo project for gsi ...

I see the options:

simply merge back to master and continue releasing normally (knowing that this wold be the first version for java 11)
produce some new releases from the branch: e.g. 0.0.10-11 (this would mean to change some logic in the deployment script)

Simplest would of course be option 1 .... (I will create a pull request... let me know what you think)

codecov · 2019-06-19T19:03:32Z

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #3   +/-   ##
=========================================
  Coverage     23.20%   23.20%           
  Complexity       76       76           
=========================================
  Files            51       51           
  Lines           737      737           
  Branches         76       76           
=========================================
  Hits            171      171           
  Misses          550      550           
  Partials         16       16

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 08ded24...015e38e. Read the comment docs.

andreacalia · 2019-06-20T08:31:41Z

If the problem is only the dependencies + configuration, we could use a similar approach as jmad-modelpack-fx :)

In the build.gradle you can fetch one dep or the other depending on the jdk version :)

if(JavaVersion.current() <= JavaVersion.VERSION_1_8){
    compile group: 'org.controlsfx', name: 'controlsfx', version: '8.40.14'
} else {
    compile group: 'org.controlsfx', name: 'controlsfx', version: '9.0.0'
}

This could solve it temporarily until we have a clear decision for CERN dependency..

kaifox · 2019-06-21T10:49:27Z

This sounds good ... We still need a release per java version, right? ... because this 'if' will not work for transitive projects...

andreacalia · 2019-06-21T12:30:44Z

exactly. We would still release for jdk8 for the moment if you need it for a demo. When would you need a released version of this?
I hope a decision will be made soon at CERN so we could move directly to Java 11.

Anyway, we could also have a separate repository in Bintray (not synchronized with JCenter) and fetch the Java 11 version from there. The release mechanism will be similar but the dependant projects will need to add this specific repo on the build.gradle.. Also this will be likely a new branch...

I would say if you can wait a bit would be better, but we should definitely tackle this in case the decision here takes more time then anticipated or we have to stay with jdk8..

kaifox · 2019-06-21T13:11:20Z

Mhmm .. I think I would like to get something working soon ... However, probably a new repo is a good idea.... the additional "-11" suffix you do not like too much, I assume? (This is what I am trying right now ...)... (I blocked the mavencentral sync for those for the moment)

kaifox · 2019-06-21T13:11:57Z

One point is: Even i CERN moves to java 11 .. there might still be some need for java 8 deps...

kaifox · 2019-06-21T13:23:57Z

I just messed up the releases (by typing 1.1.1 instead of 0.1.1....) ... But the principle seems to work: Having versions like 1.1.1 for java 8, 1.1.1-11 for java 11 .... Not sure what the version: '+' woould take in this case ....

Would you think something like this would be ok? (Actually it is borrowed from Fontawesome ;-) ... If it is ok, we could merge the branch ... as the same branch now can deliver both versions (via 2 travis builds)

andreacalia · 2019-06-22T13:55:27Z

Hi Kajetan, don't worry for the release, if it is not synched with maven central I think we could simply remove the artifact from bintray and the release from github :)

Anyway, ok if you need it soon then I would tend to use the -8 since is the jdk8 version that is getting behind :) What do you think?

The two repositories option is a temporary solution in order to have only one version published to the public.. so in your apps you would have to put the other repository to fetch minifx. But it would need some tests since I never did it..

andreacalia · 2019-06-22T13:59:37Z

build.gradle

@@ -25,6 +33,12 @@ buildscript {
    }
 }

+
+plugins {


Not 100% sure, but this could be removed since it is an alternative syntax of apply plugin that is done in the if jdk >= 11

I think that in the apply plugin syntax, there is no way to specify a version ... I will check

kaifox

Concerning the -8 version ... I am not sure ... it seems if the two versions exist:
1.1.1
1.1.1-10

then a 'version: "+"' picks up the 1.1.1-10 .... So i wonder if it would do the same with 1.1.1-8 (did not try) ... In the end this concept might not be ideal as there is no well defined order anymore ... so probably your proposal with 2 repos is better ... However, not sure if a temporary solution is good enough ...

I did not find the button to remove the versions.... Can you point me to it?

kaifox · 2019-06-22T18:27:28Z

build.gradle

@@ -25,6 +33,12 @@ buildscript {
    }
 }

+
+plugins {


I think that in the apply plugin syntax, there is no way to specify a version ... I will check

andreacalia · 2019-06-24T13:32:25Z

Link shared :)
Yes, I agree that having two release paths in the same repository can be misleading, this is the reason why I proposed another repo.. this solution will be temporary since only one can be synchronized with jcenter, so at some point we have to decide which one. Not a straight forward decision since if CERN stays with jdk8 then the external artifact importer will not work with custom repositories.. we can discuss this over skype at some point :)
I really hope we can move forward soon

kaifox · 2019-06-24T18:19:33Z

Damn! Unfortunately, it seems that the minifx-workbench version (for java 8) was synced with sonatype... So I fear, we cannot go back from there ... So I think we have to continue counting up from 1.1.1.... It is a pity, but not a tragedy... Sorry for this mistake!

kaifox · 2019-06-24T18:28:22Z

I searched a bit more and somehow it looks as a proper way to do these different jars would be a 'classifier'.
See https://maven.apache.org/pom.html (search for classifier). I think this is exactly our use-case...
what would you think?

In gradle one would then have to use:

compile group: 'org.minifx', name: 'minifx-workbench', version: '1.1.1', classifier: 'jdk11'

(I am not sure which one is picked, if the classifier is not given)

smac89 · 2019-06-26T17:04:31Z

Is this ready to be released? I just took a look at the java-11 branch and I don't see any module-info.java. The only changes seem to be in the build.gradle

kaifox · 2019-06-26T19:38:35Z

Dear @smac89, from the functionality point of view it is ready to be released. (For the moment it is a struggle with libraries, where some only work with java8, others only with java 11).
However, you are right we did not take care about the module system yet, as we still do not use it ...
Are you familiar with this? Would you like to contribute?
For the moment I am still experimenting how to correctly (or as correctly as possible ;-) release 2 different jars with qualifiers for the same version of code ;-)

classifier system property now directly queried in deployment-script

kaifox · 2019-06-26T21:46:00Z

I tell you ... again STUUPID me ;-)
classifiers will NOT work! It is not the jar which is different in our case, but the transient deps ;-).... So there is no way around a version suffix.... In the end (after some reading), there is even a name for it: It's called "qualifier" (not classifier ;-) ....
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8905

From the documentation there are 2 main things to keep in mind:

It must not be a sole number, as in this case it would be interpreted as a build number (and it behaves exactly as I described before (1.1.1-10 > 1.1.1)
versions with a qualifier are considered older than versions without .... (1.1.1-jdk8 < 1.1.1) ;-)

especially because of (2), @andreacalia s remark is totally valid: we should qualify the old version not the new one.

==> Therefore, I propose:

'-jdk8' as qualifier for the java8 compatible version
the bare version for jdk11 and above...

What do you think?

kaifox · 2019-06-26T21:50:03Z

A first trial release of this can be found in bintray with version 0.1.1 (I know it is lower than 1.1.1).

In case you all agree with this solution, I would then:

merge this branch into master
potentially delete the 0.1.1 version
re-enable sync to maven central
release v1.1.2 which would then have the right qualifiers.

Concerning the module-info.java, I created a separate issue #4 . I know it is a bit inconsistent to not do it directly, but the thing serves the urgent need for the moment ;-)

andreacalia · 2019-07-01T15:54:52Z

Ciao kajetan! Sorry for the delay..
Let's just think about the naming again haha is it possible that in jdk14 (next lts) there will be again breaking changes? Just asking because otherwise the naming convention will not work anymore since we would need a jdk11 for the previous artifacts (that we cannot rename)..

I think using -jdk8 for the old ones is only valid if then we don't want to maintain backward compatibility with the main release path.. (just aiming for the current lts jdk)

What do you think? I think we can try with what you propose kajetan

kaifox · 2019-07-05T09:21:37Z

Hi again, so Andrea, what would you propose as naming?

smac89 · 2019-07-06T17:33:54Z

If I'm understanding this naming issue correctly, you guys are looking for a way to release the jars so that you can target different java versions?

Have you considered developing something called a multi-release jar? This will allow you to continue with the current naming scheme (i.e. no changes to the name), but still target the correct java version using just one jar.

There are many nice articles online on how to do this, but this one seems the most promising:
https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/#Creating-Multi-release-JARs

kaifox · 2019-07-07T11:27:45Z

I think our problem is not only to release jars for different jdk versions, but that the tranient dependencies have to be different for different jdk versions ... this means that we need different poms for different jdks... Therefore , I think a multi-release jar would not help. Or would it?

andreacalia · 2019-07-15T16:23:36Z

Hi @smac89 , thanks! I didn't know this feature 🙂
Unfortunately this will not help us I think, as @kaifox pointed out.. but maybe I'm missing something... do you think this will help with the dependency problem?

kaifox · 2020-04-23T20:24:23Z

Not needed anymore, as we desided to go to java11 directly.
The potential useful module-info.java description is tracked in issue #4

kaifox added 5 commits June 19, 2019 19:53

preparing for java 11

9844c9a

travis for openjdk 11

0b45c88

oraclejdk11

77db592

changed jacoco tool version so that it works for java 11

76ec99e

removed unnecessary task

e75c8b9

kaifox added 3 commits June 21, 2019 13:33

next try to get one script to work for all jdks...

ef32ed8

trying to fix java8 build (by disabling javafx plugin)

fdcd1e0

moving javafx plugin configuration into if branch

182e99a

andreacalia reviewed Jun 22, 2019

View reviewed changes

kaifox commented Jun 22, 2019

View reviewed changes

kaifox added 3 commits June 26, 2019 12:10

jdk as classifier

ffeff91

switching to openjdk

0ec2154

switching to jcenter

de0f8e6

kaifox added 2 commits June 26, 2019 23:04

publish jar only for jdk 8

70cec53

classifier system property now directly queried in deployment-script

using version qualifiers now!

e85e175

kaifox mentioned this pull request Jun 26, 2019

Java 9+ compatibility #1

Closed

kaifox added 3 commits April 23, 2020 20:45

first try to build with java 11.

33660d7

trying to reenable SONATYPE sync

f759381

updated dependency for minifx-fxml to 2.0.0

015e38e

kaifox closed this Apr 23, 2020

kaifox deleted the java-11 branch April 23, 2020 20:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Java 11 #3

Java 11 #3

kaifox commented Jun 19, 2019

codecov bot commented Jun 19, 2019 •

edited

Loading

andreacalia commented Jun 20, 2019 •

edited

Loading

kaifox commented Jun 21, 2019

andreacalia commented Jun 21, 2019

kaifox commented Jun 21, 2019

kaifox commented Jun 21, 2019

kaifox commented Jun 21, 2019

andreacalia commented Jun 22, 2019

andreacalia Jun 22, 2019

kaifox Jun 22, 2019

kaifox left a comment

kaifox Jun 22, 2019

andreacalia commented Jun 24, 2019

kaifox commented Jun 24, 2019

kaifox commented Jun 24, 2019

smac89 commented Jun 26, 2019 •

edited

Loading

kaifox commented Jun 26, 2019

kaifox commented Jun 26, 2019 •

edited

Loading

kaifox commented Jun 26, 2019 •

edited

Loading

andreacalia commented Jul 1, 2019 •

edited

Loading

kaifox commented Jul 5, 2019

smac89 commented Jul 6, 2019

kaifox commented Jul 7, 2019

andreacalia commented Jul 15, 2019 •

edited

Loading

kaifox commented Apr 23, 2020

Java 11 #3

Java 11 #3

Conversation

kaifox commented Jun 19, 2019

codecov bot commented Jun 19, 2019 • edited Loading

Codecov Report

andreacalia commented Jun 20, 2019 • edited Loading

kaifox commented Jun 21, 2019

andreacalia commented Jun 21, 2019

kaifox commented Jun 21, 2019

kaifox commented Jun 21, 2019

kaifox commented Jun 21, 2019

andreacalia commented Jun 22, 2019

andreacalia Jun 22, 2019

Choose a reason for hiding this comment

kaifox Jun 22, 2019

Choose a reason for hiding this comment

kaifox left a comment

Choose a reason for hiding this comment

kaifox Jun 22, 2019

Choose a reason for hiding this comment

andreacalia commented Jun 24, 2019

kaifox commented Jun 24, 2019

kaifox commented Jun 24, 2019

smac89 commented Jun 26, 2019 • edited Loading

kaifox commented Jun 26, 2019

kaifox commented Jun 26, 2019 • edited Loading

kaifox commented Jun 26, 2019 • edited Loading

andreacalia commented Jul 1, 2019 • edited Loading

kaifox commented Jul 5, 2019

smac89 commented Jul 6, 2019

kaifox commented Jul 7, 2019

andreacalia commented Jul 15, 2019 • edited Loading

kaifox commented Apr 23, 2020

codecov bot commented Jun 19, 2019 •

edited

Loading

andreacalia commented Jun 20, 2019 •

edited

Loading

smac89 commented Jun 26, 2019 •

edited

Loading

kaifox commented Jun 26, 2019 •

edited

Loading

kaifox commented Jun 26, 2019 •

edited

Loading

andreacalia commented Jul 1, 2019 •

edited

Loading

andreacalia commented Jul 15, 2019 •

edited

Loading