FWIW the current FreeMarker release runs fine on Java 11 from the testing I've done (with Moqui). Java 9 is less important in general that Java 11 as Java 9 is not a long term release as Java 8 and Java 11 are (and Java 9, 10 are already EOL). Java versioning is really confusing these days and while there are other sources of this info the Wikipedia article on Java versions is helpful:
https://en.wikipedia.org/wiki/Java_version_history IMO moving the requirement to Java 7 is fine, versions before that are no longer widely supported anyway. Whether it is a 'safe' change or a good idea for FreeMarker depends partly on those using it, ie if anyone is still using it on Java 5 or 6. The difficulty is how would we know? Unless someone speaks up on the mailing list or we do some sort of survey and hope people participate it's hard to say. It seems reasonable and conservative to use the Extended Support dates as a guideline, which right now means supporting anything before Java 7 is not needed as the Java 6 extended support period ended in Dec 2018. For Moqui we had some discussions recently around Java versions. There was a push to support Java 11 (but not require it, Java 8 is the current requirement) as Java 11 is becoming the default on many systems and even without using any Java 11 APIs running on Java 11 offers a number of performance and memory management improvements. In certain container environments there are also important improvements in Java 11 for managing heap size relative to available memory (which is weird in containers where available system memory is different from memory restrictions applied to a given container). For Moqui the decision on Java versions is very different from FreeMarker, it's not nearly as widely used and it is a high-level package as opposed to a low level library commonly included in other packages. Even so for now Moqui is stuck on Java 8 because of a lack of support for Java 11 on various platforms. On a side note by semantic versioning rules (or at least my interpretation of them from semver.org) any non-backward compatible change requires a major version bump as a warning that in some cases the new version will not work as a drop-in replacement for the prior version. I don't know if the move to require Java 7 is significant enough to require a bump from major version 2 to 3, but something to consider. On the other hand it seriously messes up the version plans for FM3 so maybe better not to a bump from 2.3.29 to 3.0.0 but maybe from 2.3.29 to 2.4.0 with a release note about the dependency change (Java 5 to Java 7). I don't know that this is a must, semantic versioning is commonly enough used that most people understand the implications about version bumps so it is a way to communicate things, but with some communication/documentation on versioning policy variations on it are also used a lot. Anyway, some thoughts on the topic as it is fairly fresh on my mind from recent research and discussions. -David On Sun, Jan 12, 2020 at 7:55 AM Daniel Dekany <[email protected]> wrote: > * It's just my routine to not increase the minimum Java version, if it > doesn't make work significantly simpler on our side, because that can make > upgrading a problem in "legacy" systems. Using Java 8 doesn't help much in > 2.3.30, but it will once we start support Java 8 time API-s. But, > supporting anything before Java 7 in 2020 is totally pointless (I hope...), > and 7 helps us somewhat right now. Probably support anything before Java 8 > is totally pointless too... I'm not absolutely sure about the impact > though. > > * We are Java 8 compliant of course (also Java 9 compliant, as far as I > could test). Java 5 compliant in fact. > > * It removes some excludes, but some are to support different version of > other libraries. The less the better though. > > On Sun, Jan 12, 2020 at 9:49 AM Siegfried Goeschl < > [email protected]> wrote: > > > Good morning, > > > > so the upcoming 2.3.30 release is a sort of transition to the 2.3.31 > > release using JDK 8 finally? > > > > * What are the reasons not to switch to JDK 8 for 2.3.30? Please note > that > > I'm sure you have good reason to so but I want them to make more explicit > > :-) > > * I guess we should also migrate the existing code to be JDK 8 compliant? > > * Does this also remove the manual source file excludes when setting up > > FreeMarker in the IDE? Basically the stuff mentioned in README.md ... > > > > Thanks in advance, > > > > Siegfried Goeschl > > > > > > > > > On 11.01.2020, at 20:10, Daniel Dekany <[email protected]> > wrote: > > > > > > Anybody sees a problem with increasing the minimum Java version fro 5 > to > > 7 > > > in the coming release, 2.3.30? (But at least to 6. I again need to > access > > > some 6 API-s, and while I could do it with reflection, I think it's > > > pointless to support Java 5 at this point. And, not having proper > > > @Override, and diamonds, and try-with-resource is annoying.) > > > > > > Also, in 2.3.31, or something like that, we should really add Java 8 > > > date/time support. Starting from that, 1.8 will be the minimum > > requirement > > > anyway. Otherwise it would be way too complicated to add support for > > that, > > > because, the Java 8 classes will have to appear in the corresponding > new > > > TemplateModel sub-interfaces, not just in its implementations. > > > > > > -- > > > Best regards, > > > Daniel Dekany > > > > > > -- > Best regards, > Daniel Dekany >
