Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

And I hope Josh Bloch also hates checked exceptions, which are the only reason AutoCloseable was required and Closeable could not be used for try-with-resources (because the exception specification was too narrow). On 07/06/18 14:48, Ben Caradoc-Davies wrote: I hate checked exceptions so

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

The one thing I am still thinking about is the impact of checked exceptions. Our interfaces that include dispose() without throws should probably end up with close() without throws after stage two and keep dispose() without throws during stage one to maintain backwards compatibility (so client

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Jody, the problem is that doing it this way will break any third-party code that already implements an interface with dispose(). Their implementation will override dispose() and fail to implement close(). What we could do is provide default implementations for *both* close() and @Deprecated

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Yes we should, we should always be driving our library towards "mainstream" java conventions when we can. We have had a couple goes of making sure closable things are closable (feature readers, etc...). Thanks for taking this next step. -- Jody Garnett On Wed, 6 Jun 2018 at 19:32, Ben

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Good thinking. This will require more work, but will most likely be best in the long term. We should probably deprecate the proposed Disposable class as well for good measure. Should we change all uses in GeoTools from dispose() to close()? This makes sense but will be a widespread change

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Thanks for the regex. I would also like to update all classes with dispose, not just interfaces. On 07/06/18 08:08, Nuno Oliveira wrote: Hi Ben, I also used the support of the find command: find . | grep -E "\.java$" | xargs -i grep -l -E "((public)|(^))\s*interface" {} | xargs -i grep -l

Re: [Geotools-devel] [Geoserver-devel] API changes to add AutoCloseable for try-with-resources

Agreed, and Java generics are erased at compile time and offer no run time benefits. Kind regards, Ben. On 07/06/18 08:06, Nuno Oliveira wrote: Hi Ben, +1 for the NON generics option, my felling is that usually generics bring more harm than good in the long run :( On 06/06/2018 03:44 AM,

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Ah! Good one Jody, +1 On 06/06/2018 11:41 PM, Jody Garnett wrote: You could swap this around, rename the dispose implementations to close, and provide a deprecated default implementation of dispose that calls close. This way you can manage eventually remove dispose() from the API. On Wed, Jun

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

You could swap this around, rename the dispose implementations to close, and provide a deprecated default implementation of dispose that calls close. This way you can manage eventually remove dispose() from the API. On Wed, Jun 6, 2018 at 3:09 PM Nuno Oliveira wrote: > Hi Ben, > > I also used

Re: [Geotools-devel] API changes to add AutoCloseable for try-with-resources

Hi Ben, I also used the support of the find command: find . | grep -E "\.java$" | xargs -i grep -l -E "((public)|(^))\s*interface" {} | xargs -i grep -l -E "void\s+dispose" {} +1 for the proposal. On 06/06/2018 02:11 AM, Ben Caradoc-Davies wrote: Thanks, Nuno. How did you make the list? I

Re: [Geotools-devel] [Geoserver-devel] API changes to add AutoCloseable for try-with-resources

Hi Ben, +1 for the NON generics option, my felling is that usually generics bring more harm than good in the long run :( On 06/06/2018 03:44 AM, Ben Caradoc-Davies wrote: Or with generics: public interface ThrowingDisposable extends AutoCloseable {     /** * @see

Re: [Geotools-devel] Thoughts on WFS filter handling

On Wed, Jun 6, 2018 at 5:01 PM, Ian Turton wrote: > I asked this a while ago, and got no response so I went ahead and fixed > GEOT-5920 by > modifying like filters to take an Expression rather than the strictly > correct

Re: [Geotools-devel] Thoughts on WFS filter handling

I asked this a while ago, and got no response so I went ahead and fixed GEOT-5920 by modifying like filters to take an Expression rather than the strictly correct PropertyName (see commit

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

On Wed, Jun 6, 2018 at 4:46 PM, Ian Turton wrote: > +1 from me. > Thanks! > PS now I'm worried I should have done a proposal for the change to like > filters to take expressions instead of propertynames (but I thought it was > just a bug :-)) > Why don't we discuss it on a separate mail,

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

+1 from me. Ian PS now I'm worried I should have done a proposal for the change to like filters to take expressions instead of propertynames (but I thought it was just a bug :-)) On Wed, 6 Jun 2018 at 15:38, Andrea Aime wrote: > We already discussed in on the mailing list a bit, here is the

[Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

We already discussed in on the mailing list a bit, here is the format proposal: https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName Votes welcomed (and discussion too, in case you missed it previously) :-) Cheers Andrea == GeoServer Professional Services