Return-Path:
The Zest⢠Core I/O API tries to address the problem around shuffling data around from various I/O inputs and outputs, possibly with transformations and filtering along the way. It was identified that there is a general mix-up of concerns in the stereotypical I/O handling codebases that people deal with all the time. The reasoning around this, can be found -in the Use I/O API, and is recommended reading.
Why does I/O operations in Java have to be so complicated, with nested try/catch/final ly and loops? Donât you wish +in the Use I/O API, and is recommended reading.
Why does I/O operations in Java have to be so complicated, with nested try/catch/final ly and loops? Donât you wish that the operations could be expressed in a more natural way, such as;
File source = ... File destination = ... source.copyTo( destination );
It seems natural to do, yet it is not present for us. We need to involve FileInputStream/FileOutputStream, wrap them @@ -83,7 +83,7 @@ Inputs.text( source ).transferTo( Output
Pretty much self-explanatory, wouldnât you say? But what happened to the handling of exceptions and closing of resources? It is all handled inside the Zest⢠Core I/O API. There is nothing you can forget to do.
Another simple example, where we want to count the number of lines in the text;
import org.qi4j.io.Transforms.Counter; import static org.qi4j.io.Transforms.map; -[...snip...] + [...snip...] File source = new File( "source.txt" ); File destination = new File( "destination.txt" ); @@ -107,7 +107,7 @@ likewise is the ultimate "receiver". (ReceiverThrowable) which the transferTo() method may also throw as the data may not be accepted and such exception will bubble up to the transferTo() method (the clientâs view of the transfer).
The output interface is likewise fairly simple;
public interface Output<T, ReceiverThrowableType extends Throwable> { -[...snip...] + [...snip...] <SenderThrowableType extends Throwable> void receiveFrom( Sender<? extends T, SenderThrowableType> sender ) throws ReceiverThrowableType, SenderThrowableType; @@ -210,7 +210,7 @@ as every 1000 items. This may not be wha how you can combine the general principles found in the Zest⢠Core API package.
The filter transform takes a specification implementation which has a very simple method, isSatisfiedBy() (read more about that in Function.
public interface Specification<T> { -[...snip...] + [...snip...] boolean satisfiedBy( T item ); } @@ -246,7 +246,7 @@ sources and destinations.
code
docs
tests
First of all, your code should never, ever, have a dependency on Core Runtime. If you think you need this, you should probably contact qi4j-dev forum at Google Groups and see if your usecase can either be solved in a existing way or perhaps -that a new Core SPI Extension is needed.
Letâs repeat that; Never, never, ever depend on Core Runtime. Make sure that the compile dependency does NOT include +that a new Core SPI Extension is needed.
Letâs repeat that; Never, never, ever depend on Core Runtime. Make sure that the compile dependency does NOT include
the org.qi4j.core.runtime
jar.