Okay we have a really good pull request from Nicolai Parlog for Java 9
compatibility:
- https://github.com/geotools/geotools/pull/1670
- https://osgeo-org.atlassian.net/browse/GEOT-5289
This was intended to be the thrust of the code sprint at foss4g, but due to
infrastructure challenges we missed our opportunity :(
Checking Java8 EOL (http://www.oracle.com/technetwork/java/eol-135779.html)
we there is Java 8 support from Oracle until Sep 2018 (or later,
depending). So for the GeoTools 18 supported/maintenance timeline of a year
Java 8 will remain supported.
That said I fully expect users to start trying to switch to Java 9, and
indeed this pull request shows that to already be the case.
Given that this release is delayed on GeoWebCache I am going to do my level
best to try out the Java 9 compatibility pull request.
1) The PR is blocked on a CLA
2) I have invited the author to our next meeting (no response yet)
3) The PR starts with some design decisions that want confirmation
ServiceRegistry --> FactoryRegistry
- I like the rename it makes things a bit more clear since that is how we
use SPI in GeoTools (to dynamically look up factories)
- focused only the methods used in geotools
- I like that it breaks code that used ServiceRegistry, this is a clear
break and having a compile error is better than failing at runtime (as
happens when using Java 9 now)
Exceptions
- Has a request to improve exception handling consistency, do not view that
as a showstopper but as a good nice to have
RegisterableService expecting a service registry as a parameter
- Author made RegisterableService --> RegisterableFactory - seems clear
enough
- This change is actually backwards incompatible (sad)
- Author recommends noticing if RegisterableService is ever found and
throwing a warning/error
- bad idea: make an adapter that calls that method with a null
ServiceRegistry (to force a failure in the client code at the right stage
of the lifecycle). Or at least log a warning at the right stage of the
lifecycle.
- If we have a solid abstract class or something we should be able to use
deprecations+overloads
Naming
- discussion on breaking method compatibility, given that FactoryRegistry
is mostly used inside GeoTools I am totally fine with that
Filter --> Predicate
- makes sense
Reuse of PartiallyOrderedSet
- made this into a public class
- found & fixed two bugs
--
Jody Garnett
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
