There is also the new HTTP client (there is still use of the EOL apache
httpclient 3.x in some places) and new String and Collection methods would
probably make it possible to reduce the number of dependencies as well.
Dropping Java 8 as a runtime makes it possible to upgrade the EE modules to
I am neutral on this; geocat can make the change for our customers to Java
11 (but are presently using Java 8).
It seems odd to limit the geotools build if their is no technical reason
feature we wish to take advantage of. The key language feature I am looking
forward to is inline classes (for
On Mon, Feb 21, 2022 at 12:39 PM Nuno Oliveira <
nuno.olive...@geosolutionsgroup.com> wrote:
> Hi Andrea,
> I'm assuming you are suggesting this for the upcoming GeoServer 2.22.x and
> GeoTools 28.x branches?
>
I did not have a specific target in mind. The code builds with Java 11
today, so Java
Hi Andrea,
I'm assuming you are suggesting this for the upcoming GeoServer 2.22.x and
GeoTools 28.x branches?
If my math is right, this means that we will have until:
- September 2022 2.21.x stable supporting Java 8
- February 2023 2.21.x maintenance supporting Java 8
Taking into account
Hi all,
recently I've been wondering multiple times if we should just switch to
Java 11
as the minimum supported versions.
Reasons/benefits:
- I believe most deployments are on Java 11 anyways
- It simplifies our build, one less JDK to handle (we now try to support
Java 8, 11 and 17)
