Hi everybody, this is Nicolai - the guy with the Java 9 pull request. Things are a little crazy at the moment but I hope to be able to get back to you on GitHub tomorrow afternoon or over the weekend.
I'm in process of getting the CLA signed. I'm happy to answer any question in that Skype call Jody mentioned. When is the next one? so long ... Nicolai On 29.08.2017 20:04, Jody Garnett wrote: > 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 > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx ------------------------------------------------------------------------------ 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
