* 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
