fineract-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [fineract] ptuomola commented on pull request #820: FINERACT-846: Migrating to Java 11
Date Thu, 07 May 2020 10:23:14 GMT

ptuomola commented on pull request #820:

   Many thanks @vorburger for your feedback and comments
   > @ptuomola wow, great job, nice find re. JDK!!! I'm just curious, did you notice this
by comparison of Travis's VS local JDK version numbers, or do you have a link to a OpenJDK
bug about this?
   I found it by turning on the SSL debug logging and stepping through the SSL handshakes
/ negotiation. But once I worked out what's going on, it was easy to find a JDK bug that someone
else had raised on the same issue and that has been fixed in a later JDK minor version (
- TLS 1.3 resumed session does not retain peer certificate chain)
   > Using JDK 12 instead of 11 can't stay long, because even though Gradle specifies 11,
that will only cause javac to allow only 11 SYNTAX, but it will still allow to build with
use of 12 LIBRARIES - I've dealt with related problems in other projects, over the years.
But what I think we should do due to OpenJDK bug is still do this, for now, merge, but then
change it "soon". I volunteer to look into it for Travis later. Perhaps create a new JIRA
dedicated to "Switch Travis from Java 12 to Java 11" (and assign it to me)?
   That makes sense. There are some possible ways suggested on how to get a specific version
of OpenJDK on different sites - e.g.
However none of them seemed particularly "clean". 
   I also considered upgrading the whole Linux distro being used by Travis to a newer version
(probably a good idea anyway). But unfortunately the newer distro version still uses the same
script to pull OpenJDK, and hence seemed to end up with the same JDK version. 
   > As for javac compiler warnings, let's fix in follow up PRs. Personally I may even
have left the warning instead of suppressing, as a reminder, but it really doesn't matter,
   I've left this for now. 
   > I was also going to suggest that this could have been broken up into separate PRs
first for all the code changes, while still on Java 8, and then figure out make the Java 11
build changes, but seeing your breakthrough, I'll get this in ASAP; so more of a suggestion
for future smaller PRs.
   Thanks for the suggestion - will in the future submit smaller PRs. There are still a couple
of cleanups I think would make sense - e.g. there's still a depreciation warning from Gradle,
and some of the Gradle plugins are not at their latest versions - but I can submit those as
separate PRs. 
   Thanks again

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

View raw message