Increase minimum Java version in 2.3.x?

[Daniel Dekany <da...@gmail.com>]

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

Re: Increase minimum Java version in 2.3.x?

[Daniel Dekany <da...@gmail.com>]

I went for Java 7 for now. So 2.3.30 will need that at least, unless
someone questions the decision. (Probably we would be fine even with
requiring Java 8, but, we don't need that yet, not that much.)

On Sun, Jan 12, 2020 at 8:31 PM Daniel Dekany <da...@gmail.com>
wrote:

> I wouldn't increase the 1st (major) version number because of higher
> required dependency versions. That just happens too often with libraries, I
> think. In fact it already happened with 2.3.x for at least 2 times in the
> past. As the API of FreeMarker itself didn't change in an incompatible way,
> I didn't treat that as incompatible change.
>
> BTW, FreeMarker 2 historically doesn't use the now commonly accepted form
> of semantic versioning. In modern semantic versioning, a 2nd version number
> increase indicates significant new features, so with that we would be at
> 2.<somewhatHighNumber>.0, not at 2.3.<highNumber>. But, in FreeMarker 2
> convention (which is communicated in our download page, and maybe elsewhere
> too), a 2nd version number change indicates non-backward compatible
> changes, and a 1st version number change indicates deeper redesign, as is
> the case with FM 3.0.0 (after which, if it's ever released, I would switch
> to modern semantic versioning).
>
> On Sun, Jan 12, 2020 at 8:07 PM David E Jones <de...@dejc.com> wrote:
>
>> 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 <da...@gmail.com>
>> 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 <
>> > siegfried.goeschl@gmail.com> 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 <da...@gmail.com>
>> > 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
>> >
>>
>
>
> --
> Best regards,
> Daniel Dekany
>


-- 
Best regards,
Daniel Dekany

Re: Increase minimum Java version in 2.3.x?

[Daniel Dekany <da...@gmail.com>]

I wouldn't increase the 1st (major) version number because of higher
required dependency versions. That just happens too often with libraries, I
think. In fact it already happened with 2.3.x for at least 2 times in the
past. As the API of FreeMarker itself didn't change in an incompatible way,
I didn't treat that as incompatible change.

BTW, FreeMarker 2 historically doesn't use the now commonly accepted form
of semantic versioning. In modern semantic versioning, a 2nd version number
increase indicates significant new features, so with that we would be at
2.<somewhatHighNumber>.0, not at 2.3.<highNumber>. But, in FreeMarker 2
convention (which is communicated in our download page, and maybe elsewhere
too), a 2nd version number change indicates non-backward compatible
changes, and a 1st version number change indicates deeper redesign, as is
the case with FM 3.0.0 (after which, if it's ever released, I would switch
to modern semantic versioning).

On Sun, Jan 12, 2020 at 8:07 PM David E Jones <de...@dejc.com> wrote:

> 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 <da...@gmail.com>
> 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 <
> > siegfried.goeschl@gmail.com> 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 <da...@gmail.com>
> > 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
> >
>


-- 
Best regards,
Daniel Dekany

Re: Increase minimum Java version in 2.3.x?

[David E Jones <de...@dejc.com>]

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 <da...@gmail.com>
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 <
> siegfried.goeschl@gmail.com> 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 <da...@gmail.com>
> 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
>

Re: Increase minimum Java version in 2.3.x?

[Daniel Dekany <da...@gmail.com>]

* 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 <
siegfried.goeschl@gmail.com> 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 <da...@gmail.com> 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

Re: Increase minimum Java version in 2.3.x?

[Siegfried Goeschl <si...@gmail.com>]

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 <da...@gmail.com> 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