Re: org.apache.zest.io an org.apache.zest.functional

[Paul Merlin <pa...@apache.org>]

Gang,

I pushed a commit on the replace-io-by-stream branch that replace usage
of core/io with Java 8 Streams:
https://github.com/apache/zest-java/commit/eb4e31a97a92609feb2e7bb18d135de432d511db

After this commit, core/io is completely unused across the whole SDK.

The code is much simpler even if in some cases it's still quite
convoluted to map the underlying stores APIs to Streams.

Please review and comment so I can move forward, address your comments
and merge into develop soon.

Cheers

/Paul


Paul Merlin a �crit :
> Niclas Hedhman a �crit :
>> Most (all?) Iterables in Core was replaced before.
>
> There still are some leftovers here and there.
> I started with TypeLookup where I removed some of the Stream
> multi-iterations and added more caching, optimising frequently invoked
> code paths. There's still room for improvement.
>
>> For exceptions,
>> first of all, I think almost all exceptions in Zest are RuntimeExceptions
>> and should not cause much problem. For IOException and such, I typically
>> wrap in UndeclaredThrowableException if the cause/use is unclear and catch
>> that in the caller.
>
> We use core/io in EntityStore and BackupRestore interfaces.
>
> These APIs are meant to transfer large datasets where each party has
> exceptions to catch and resources to cleanup.
>
> [1] If we forget that for a moment we could write something like:
>
> interface EntityStore {
>   Stream<EntityState> entityStates();
> }
> interface BackupRestore {
>   Stream<String> backup();
>   void restore(Stream<String> states);
> }
>
> Streams are AutoCloseables, so they can be used with try-with-resources
> or simple try/catch. Implementations could register a callback with
> Stream::onClose() to clean up resources.
>
> Both EntityStore and BackupRestore implementations could also wrap
> checked exceptions in unchecked ones.
> BTW, for IOExceptions we should prefer Java 8 UncheckedIOException.
>
> Javadoc for EntityStore and BackupRestore should then advertise that
> consuming the stream may throw UncheckedIOExceptions and that the
> Streams must be closed properly. Like the ones created by java.nio.Files
> for example.
>
> That way the only thing we miss compared to core/io is explicit handling
> of both producer and consumer exceptions around each item in the stream
> on the consumer side.
>
> [2] We could go one step further and write something like:
>
> interface EntityStore {
>   Stream<Supplier<EntityState>> entityStates();
> }
> interface BackupRestore {
>   Stream<Supplier<String>> backup();
>   void restore(Stream<Supplier<String>> states);
> }
>
> so that exceptions and resource cleanup can be handled around fetching
> each item in the stream.
>
> [3] If we want to mimic core/io and use checked exceptions we could go
> even further and write:
>
> interface EntityStore {
>   Stream<ThrowingSupplier<EntityState, IOException>> entityStates();
> }
> interface BackupRestore {
>   Stream<ThrowingSupplier<String, IOException>> backup();
>   void restore(Stream<ThrowingSupplier<String, IOException>> states);
> }
> ThrowingSupplier<T, ThrowableType extends Throwable> extends Supplier<T> {
>     T get() throws ThrowableType;
> }
>
> In both [2] & [3] cases we could use some EntityStateSupplier and
> StringStateSupplier types to reduce API clutter a bit.
>
> My gut feel is that [2] is acceptable for EntityStore and BackupRestore
> use cases. We could also drop the ability to handle producer exceptions
> around each item when consuming and go for [1].
>
> I'll experiment with [1] and see what comes up out of it.
>
> Cheers
>
> /Paul
>
>
>

Re: org.apache.zest.io an org.apache.zest.functional

[Paul Merlin <pa...@apache.org>]

Niclas Hedhman a �crit :
> No feedback should be interpreted as either; "Yeah, that is all good,
> nothing to add" or "Community has fallen asleep"
>
> You know that I typically don't sleep... :-)  It is all good.

Hehe :) I'll proceed and merge then.


> On Thu, Dec 8, 2016 at 9:47 PM, Paul Merlin <pa...@apache.org> wrote:
>
>> Paul Merlin a �crit :
>>> Gang,
>>>
>>> I pushed a commit on the replace-io-by-stream branch that replace usage
>>> of core/io with Java 8 Streams:
>>> https://github.com/apache/zest-java/commit/
>> eb4e31a97a92609feb2e7bb18d135de432d511db
>>> After this commit, core/io is completely unused across the whole SDK.
>>>
>>> The code is much simpler even if in some cases it's still quite
>>> convoluted to map the underlying stores APIs to Streams.
>>>
>>> Please review and comment so I can move forward, address your comments
>>> and merge into develop soon.
>>>
>>> Cheers
>>>
>>> /Paul
>> Any feedback on this?
>>
>>
>>
>
>

Re: org.apache.zest.io an org.apache.zest.functional

[Niclas Hedhman <ni...@hedhman.org>]

No feedback should be interpreted as either; "Yeah, that is all good,
nothing to add" or "Community has fallen asleep"

You know that I typically don't sleep... :-)  It is all good.

On Thu, Dec 8, 2016 at 9:47 PM, Paul Merlin <pa...@apache.org> wrote:

> Paul Merlin a écrit :
> > Gang,
> >
> > I pushed a commit on the replace-io-by-stream branch that replace usage
> > of core/io with Java 8 Streams:
> > https://github.com/apache/zest-java/commit/
> eb4e31a97a92609feb2e7bb18d135de432d511db
> >
> > After this commit, core/io is completely unused across the whole SDK.
> >
> > The code is much simpler even if in some cases it's still quite
> > convoluted to map the underlying stores APIs to Streams.
> >
> > Please review and comment so I can move forward, address your comments
> > and merge into develop soon.
> >
> > Cheers
> >
> > /Paul
>
> Any feedback on this?
>
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: org.apache.zest.io an org.apache.zest.functional

[Paul Merlin <pa...@apache.org>]

Paul Merlin a �crit :
> Gang,
>
> I pushed a commit on the replace-io-by-stream branch that replace usage
> of core/io with Java 8 Streams:
> https://github.com/apache/zest-java/commit/eb4e31a97a92609feb2e7bb18d135de432d511db
>
> After this commit, core/io is completely unused across the whole SDK.
>
> The code is much simpler even if in some cases it's still quite
> convoluted to map the underlying stores APIs to Streams.
>
> Please review and comment so I can move forward, address your comments
> and merge into develop soon.
>
> Cheers
>
> /Paul

Any feedback on this?