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

2018-06-06 Thread Ben Caradoc-Davies
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 much.


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Ben Caradoc-Davies
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 code using the interface does not get a compile 
failure with an unhandled exception during the transition). We might 
need two interfaces because we have dispose() without throws and 
dispose() with throws.


I hate checked exceptions so much.

On 07/06/18 14:29, Ben Caradoc-Davies wrote:

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 dispose() that call each other. All implementations with 
dispose() will work fine, and will work just the same when dispose() is 
renamed to close().


I think we need a deprecation cycle:

Stage one (GeoTools 20): introduce @Deprecated interface Disposable 
(extends AutoCloseable) with @Deprecated default dispose() that calls 
close() and default close() that calls dispose(). All implementations 
have dispose() marked @Deprecated. All implementations can now have 
their dispose() renamed to close() as convenient, with @Deprecated 
removed. The default dispose() will provide backwards compatibility.


Stage two (GeoTools 21): remove Disposable entirely, replacing it with 
AutoClosable. Any remaining dispose() methods renamed to close(). 
Third-party code that ignored the deprecation warnings is now broken.


Is one release cycle enough deprecation before removal?

Kind regards,
Ben.

On 07/06/18 10:41, 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.




--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Ben Caradoc-Davies

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 dispose() that call each other. All implementations with 
dispose() will work fine, and will work just the same when dispose() is 
renamed to close().


I think we need a deprecation cycle:

Stage one (GeoTools 20): introduce @Deprecated interface Disposable 
(extends AutoCloseable) with @Deprecated default dispose() that calls 
close() and default close() that calls dispose(). All implementations 
have dispose() marked @Deprecated. All implementations can now have 
their dispose() renamed to close() as convenient, with @Deprecated 
removed. The default dispose() will provide backwards compatibility.


Stage two (GeoTools 21): remove Disposable entirely, replacing it with 
AutoClosable. Any remaining dispose() methods renamed to close(). 
Third-party code that ignored the deprecation warnings is now broken.


Is one release cycle enough deprecation before removal?

Kind regards,
Ben.

On 07/06/18 10:41, 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.


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Jody Garnett
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 Caradoc-Davies  wrote:

> 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 with impact on pull requests
> and future backports.
>
> Kind regards,
> Ben.
>
> On 07/06/18 10:41, 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.
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
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


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

2018-06-06 Thread Ben Caradoc-Davies
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 with impact on pull requests 
and future backports.


Kind regards,
Ben.

On 07/06/18 10:41, 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.


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Ben Caradoc-Davies
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 -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 have been using things like:
find . -name "*.java" -exec grep -l 'void dispose()' {} \; | sort

Instead of editing your list, I would like to make a change proposal 
on the wiki.


Kind regards,
Ben. 


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Ben Caradoc-Davies
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, Ben Caradoc-Davies wrote:

Or with generics:


public interface ThrowingDisposable extends 
AutoCloseable {

    /**
 * @see java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() throws T {
    dispose();
    }
    void dispose() throws T;
}
public interface Disposable extends ThrowingDisposable {
    /**
 * @see java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() {
    dispose();
    }
    @Override
    void dispose();
}


Or just keep it simple and have dispose throw Exception like 
java.lang.AutoCloseable#close() and let implementers narrow the return 
type to no exception if they like. Impact will be minimal as client 
code will likely use an implementer not a bare Disposable:



public interface Disposable extends AutoCloseable{
    /**
 * @throws Exception
 * @see java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() throws Exception{
    dispose();
    }
    void dispose() throws Exception;
}


Preference?

Kind regards,





--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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


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

2018-06-06 Thread Nuno Oliveira

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 6, 2018 at 3:09 PM 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 -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 have been using things like:
> find . -name "*.java" -exec grep -l 'void dispose()' {} \; | sort
>
> Instead of editing your list, I would like to make a change proposal on
the wiki.
>
> Kind regards,
> Ben.
>
> On 05/06/18 22:17, Nuno Oliveira wrote:
>> You can count on me, I can dedicate some spare during WE to this.
>>
>> I guess before deciding on an attack plan, it would be good to have a
list of
>> the concerned interfaces, I have started to put a list together here:
>>
>>

https://docs.google.com/spreadsheets/d/1u3488JvSs34IMZ1TLjJ5FYQBAFHhQ4QHqfHfULH_k1s/edit?usp=sharing

>>
>>
>> Feel free to ask me edition permissions ...
>>
>> On 06/05/2018 09:17 AM, Andrea Aime wrote:
>>> On Tue, Jun 5, 2018 at 10:05 AM, Ian Turton mailto:ijtur...@gmail.com>
>>> >> wrote:
>>>
>>>
>>>     - Who is interested in participating in this work?
>>>
>>>
>>>     I'd be up to do some of it.
>>>
>>>
>>> Same here. As spare time contribution, if we are a group, we do the
>>> deprecation, and attack one interface at a time.
>>> As a code sprint if we want to do all toghether (though, in a week
long code
>>> sprint, we might want to look into more
>>> "urgent yet too big" stuff, like running the whole project stack on Java
>>> 10-11).
>>>
>>> Cheers
>>> Andrea
>>>
>>> == GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information. == Ing. Andrea


Aime @geowolf
>>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>> --- /Con riferimento
>>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che
ogni
>>> circostanza inerente alla presente email (il suo contenuto, gli 
eventuali
>>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei
>>> comunque grato se potesse darmene notizia. This email is intended only
for
>>> the person or entity to which it is addressed and may contain 
information
>>> that is privileged, confidential or otherwise protected from
disclosure. We
>>> remind that - as provided by European Regulation 2016/679 “GDPR” -
copying,
>>> dissemination or use of this e-mail or the information herein by anyone
>>> other than the intended recipient is prohibited. If you have received
this
>>> email by mistake, please notify us immediately by telephone or e-mail./
>>>
>>>
>>>
>>>

--
>>> 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
>>
>>
>>
>>

--
>> 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
>>
>

-- 
Regards,

Nuno Oliveira
==
GeoServer Professional Services from the 

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

2018-06-06 Thread Jody Garnett
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 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 have been using things like:
> > find . -name "*.java" -exec grep -l 'void dispose()' {} \; | sort
> >
> > Instead of editing your list, I would like to make a change proposal on
> the wiki.
> >
> > Kind regards,
> > Ben.
> >
> > On 05/06/18 22:17, Nuno Oliveira wrote:
> >> You can count on me, I can dedicate some spare during WE to this.
> >>
> >> I guess before deciding on an attack plan, it would be good to have a
> list of
> >> the concerned interfaces, I have started to put a list together here:
> >>
> >>
> https://docs.google.com/spreadsheets/d/1u3488JvSs34IMZ1TLjJ5FYQBAFHhQ4QHqfHfULH_k1s/edit?usp=sharing
> >>
> >>
> >> Feel free to ask me edition permissions ...
> >>
> >> On 06/05/2018 09:17 AM, Andrea Aime wrote:
> >>> On Tue, Jun 5, 2018 at 10:05 AM, Ian Turton  >>> > wrote:
> >>>
> >>>
> >>> - Who is interested in participating in this work?
> >>>
> >>>
> >>> I'd be up to do some of it.
> >>>
> >>>
> >>> Same here. As spare time contribution, if we are a group, we do the
> >>> deprecation, and attack one interface at a time.
> >>> As a code sprint if we want to do all toghether (though, in a week
> long code
> >>> sprint, we might want to look into more
> >>> "urgent yet too big" stuff, like running the whole project stack on
> Java
> >>> 10-11).
> >>>
> >>> Cheers
> >>> Andrea
> >>>
> >>> == GeoServer Professional Services from the experts! Visit
> >>> http://goo.gl/it488V for more information. == Ing. Andrea
> 
> Aime @geowolf
> >>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa
> >>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> >>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> >>> --- /Con
> riferimento
> >>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> >>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che
> ogni
> >>> circostanza inerente alla presente email (il suo contenuto, gli
> eventuali
> >>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> >>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto
> per
> >>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei
> >>> comunque grato se potesse darmene notizia. This email is intended only
> for
> >>> the person or entity to which it is addressed and may contain
> information
> >>> that is privileged, confidential or otherwise protected from
> disclosure. We
> >>> remind that - as provided by European Regulation 2016/679 “GDPR” -
> copying,
> >>> dissemination or use of this e-mail or the information herein by
> anyone
> >>> other than the intended recipient is prohibited. If you have received
> this
> >>> email by mistake, please notify us immediately by telephone or e-mail./
> >>>
> >>>
> >>>
> >>>
> --
> >>> 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
> >>
> >>
> >>
> >>
> --
> >> 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
> >>
> >
>
> --
> Regards,
> Nuno Oliveira
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
>
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati
> personali (Reg. UE 

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

2018-06-06 Thread Nuno Oliveira

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 have been using things like:
find . -name "*.java" -exec grep -l 'void dispose()' {} \; | sort

Instead of editing your list, I would like to make a change proposal on the 
wiki.

Kind regards,
Ben.

On 05/06/18 22:17, Nuno Oliveira wrote:

You can count on me, I can dedicate some spare during WE to this.

I guess before deciding on an attack plan, it would be good to have a list of 
the concerned interfaces, I have started to put a list together here:


https://docs.google.com/spreadsheets/d/1u3488JvSs34IMZ1TLjJ5FYQBAFHhQ4QHqfHfULH_k1s/edit?usp=sharing 



Feel free to ask me edition permissions ...

On 06/05/2018 09:17 AM, Andrea Aime wrote:
On Tue, Jun 5, 2018 at 10:05 AM, Ian Turton > wrote:



    - Who is interested in participating in this work?


    I'd be up to do some of it.


Same here. As spare time contribution, if we are a group, we do the 
deprecation, and attack one interface at a time.
As a code sprint if we want to do all toghether (though, in a week long code 
sprint, we might want to look into more
"urgent yet too big" stuff, like running the whole project stack on Java 
10-11).


Cheers
Andrea

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf 
Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa 
(LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 
http://www.geo-solutions.it http://twitter.com/geosolutions_it 
--- /Con riferimento 
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - 
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, gli eventuali 
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i 
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per 
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei 
comunque grato se potesse darmene notizia. This email is intended only for 
the person or entity to which it is addressed and may contain information 
that is privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you have received this 
email by mistake, please notify us immediately by telephone or e-mail./




--
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




--
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





--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us 

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

2018-06-06 Thread Nuno Oliveira

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 java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() throws T {
    dispose();
    }
    void dispose() throws T;
}
public interface Disposable extends ThrowingDisposable {
    /**
 * @see java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() {
    dispose();
    }
    @Override
    void dispose();
}


Or just keep it simple and have dispose throw Exception like 
java.lang.AutoCloseable#close() and let implementers narrow the return type to 
no exception if they like. Impact will be minimal as client code will likely 
use an implementer not a bare Disposable:



public interface Disposable extends AutoCloseable{
    /**
 * @throws Exception
 * @see java.lang.AutoCloseable#close()
 */
    @Deprecated
    @Override
    default void close() throws Exception{
    dispose();
    }
    void dispose() throws Exception;
}


Preference?

Kind regards,



--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.


--
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


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

2018-06-06 Thread Andrea Aime
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 PropertyName (see commit
> 
> ).
>
> I treated this as a bug, but seeing Andrea's proposal for Selection
> Channels I now wonder if it should have been a proposal too?
>

Hum... I don't see a core API change there, just a schema change? Looks
fine to me, no need for a proposal imho

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information. == Ing. Andrea Aime @geowolf Technical Lead
GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39
0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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


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

2018-06-06 Thread Ian Turton
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

).

I treated this as a bug, but seeing Andrea's proposal for Selection
Channels I now wonder if it should have been a proposal too?

BTW GEOT-5921
 remains
open if any one wants to look at it.


Ian

On Sun, 7 Jan 2018 at 17:35, Ian Turton  wrote:

> While answering this question
> 
> I ran into a couple (or more) bugs in the WFSDatastore - GEOT-5920
>  & GEOT-5921
> 
>
> It looks like the 5921 problem is that the WFSDatastore doesn't check the
> filter capabilities section of the capabilities document and split the
> filter into ones it can and can't handle in the way that the JDBC
> Datastores do. So before I head too far down this rabbit hole can anyone
> suggest an easy way to grab the filter capabilities from a GetCapabilities
> request? I found createGetFeatureRequestPost
> 
>  which
> looks like it should be doing this but seems to think that ILIKE is ok.
>
> 5920 looks like it is not passing the function to GeoServer which is could
> since that is a supported function but is instead is just sending an empty
> parameter - I'm not sure where to look for that
>
> Cheers
>
> Ian
>
> --
> Ian Turton
>


-- 
Ian Turton
--
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


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

2018-06-06 Thread Andrea Aime
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, with some context about
affected areas and the like? :-)

Cheers
Andrea

-- 

Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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


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

2018-06-06 Thread Ian Turton
+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 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 from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
> --
> 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
>


-- 
Ian Turton
--
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


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

2018-06-06 Thread Andrea Aime
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 from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
(LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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