Return-Path: X-Original-To: apmail-zest-commits-archive@minotaur.apache.org Delivered-To: apmail-zest-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5FF03186BF for ; Mon, 21 Sep 2015 15:17:02 +0000 (UTC) Received: (qmail 6583 invoked by uid 500); 21 Sep 2015 15:17:02 -0000 Delivered-To: apmail-zest-commits-archive@zest.apache.org Received: (qmail 6564 invoked by uid 500); 21 Sep 2015 15:17:02 -0000 Mailing-List: contact commits-help@zest.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@zest.apache.org Delivered-To: mailing list commits@zest.apache.org Received: (qmail 6555 invoked by uid 99); 21 Sep 2015 15:17:02 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Sep 2015 15:17:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id AFA121A51B1 for ; Mon, 21 Sep 2015 15:17:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.301 X-Spam-Level: **** X-Spam-Status: No, score=4.301 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RDNS_NONE=2.5, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 0aBQYuUBVPwE for ; Mon, 21 Sep 2015 15:16:45 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (unknown [209.188.14.139]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTP id 0818423066 for ; Mon, 21 Sep 2015 15:16:32 +0000 (UTC) Received: from svn01-us-west.apache.org (svn.apache.org [10.41.0.6]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CAF30E1222 for ; Mon, 21 Sep 2015 15:16:31 +0000 (UTC) Received: from svn01-us-west.apache.org (localhost [127.0.0.1]) by svn01-us-west.apache.org (ASF Mail Server at svn01-us-west.apache.org) with ESMTP id B1E583A07E9 for ; Mon, 21 Sep 2015 15:16:31 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1704315 [10/17] - in /zest/site: content/ content/java/2.1/ content/java/2.1/js/ content/java/latest/ content/java/latest/js/ src/ Date: Mon, 21 Sep 2015 15:16:12 -0000 To: commits@zest.apache.org From: paulmerlin@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20150921151631.B1E583A07E9@svn01-us-west.apache.org> Modified: zest/site/content/java/latest/core-io.html URL: http://svn.apache.org/viewvc/zest/site/content/java/latest/core-io.html?rev=1704315&r1=1704314&r2=1704315&view=diff ============================================================================== --- zest/site/content/java/latest/core-io.html (original) +++ zest/site/content/java/latest/core-io.html Mon Sep 21 15:15:15 2015 @@ -70,7 +70,7 @@ independently of Zest, together with the Zest™ Core Functional API, which the Core I/O API depends on.

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.

Table 19. Artifact

Group IDArtifact IDVersion

org.qi4j.core

org.qi4j.core.io

2.1


The Problem

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.

Table 19. Artifact

Group IDArtifact IDVersion

org.qi4j.core

org.qi4j.core.io

2.1


The Problem

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

org.qi4j.io.Output

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.

How to write a filter specification?

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.

Table 21. Artifact

Group IDArtifact IDVersion

org.qi4j.core

org.qi4j.core.runtime

2.1


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.

Table 21. Artifact

Group IDArtifact IDVersion

org.qi4j.core

org.qi4j.core.runtime

2.1


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.