I am still investigating this change. I think I have found a use-case
where deprecation of dispose() and third-party migration to close()
might introduce a resource leak. I will report back when I have finished
my investigation.
Kind regards,
Ben.
On 07/06/18 14:29, Ben Caradoc-Davies wrote:
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.
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
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
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-Da
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
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
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
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 th
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 h
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 05/06/18 20:05, Ian Turton wrote:
On Tue, 5 Jun 2018 at 00:25, Ben Caradoc-Davies wrote:
- Should we add AutoCloseable to interfaces, and if so which ones? We
could make a list.
This is an obvious first step, is there an easy way to do it? grep for
dispose?
I found many interfaces and cla
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_
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
On Tue, 5 Jun 2018 at 00:25, Ben Caradoc-Davies wrote:
> Many interfaces in GeoTools and GeoServer use the Dispose pattern, often
> with a dispose() method, but do not implement AutoCloseable, preventing
> their use in a try-with-resources statement. Examples range from
> ImageReader to DataStore
Many interfaces in GeoTools and GeoServer use the Dispose pattern, often
with a dispose() method, but do not implement AutoCloseable, preventing
their use in a try-with-resources statement. Examples range from
ImageReader to DataStore/DataAccess. Some interfaces like FeatureReader
already imple
Hello, Yes, the tool checks daily for new GeoTools packages available in the https://sourceforge.net/projects/geotools/files/ directory. Thank you. BTWThe report for the 15-RC1 version has been added today: http://abi-laboratory.pro/java/tracker/timeline/geotools/ 18.05.2016, 21:34, "Jody Garnett":
That is interesting, and a good sanity check when writing our update
instructions.
Does it automatically watch the repo for new tags?
--
Jody Garnett
On 18 May 2016 at 06:08, Ponomarenko Andrey
wrote:
> Hello,
>
> The reports for the GeoTools library have been added to the API Tracker
> project
Hello,
The reports for the GeoTools library have been added to the API Tracker
project: http://abi-laboratory.pro/java/tracker/timeline/geotools/
One can look at the recent changes in the API and analysis of backward
compatibility and navigate over the history of API changes in the library. The
Some other ones from last week
FileDataStore is now an interface; replacing AbstractFileDataStore as
the explicit public api. FileDataStoreFinder now returns one of these
things
Andrea points out that new PostgisDataStoreFactory works so I will
remove the etDataStoreFactory( Pos
I have been adding methods in order to tidy up tutorial examples .
A DataStoreFinder method to look up a factory instance by type name.
This method allows me to remove all the new ShapeFileDataStoreFactory
() . Used type narrowing to make it a bit easier...
ShapefileDataStoreFactory fact
21 matches
Mail list logo
