Stream.filter() to produce a list containing only those
+ * Use Stream.filter() to produce a list containing only those
* Persons eligible to vote.
*
* @see Person#getAge()
@@ -242,13 +238,10 @@ public void getAllPersonsEligibleToVote() {
* Ensure that the Set returned cannot be modified by callers by wrapping the result
* in Collections.unmodifiableSet().
*
- * - * The Streams API does not provide a way to wrap the final result, as one of its operations. So just wrap the - * result in an unmodifiableSet yourself. Sometimes it's just as important to know what an API _doesn't_ do. - *
* @throws ClassNotFoundException If the lambdas binary build no longer contains the class * @see Stream#collect(java.util.stream.Collector) - * @see java.util.stream.Collectors#toSet() + * @see Collectors#collectingAndThen(Collector, Function) + * @see Collectors#toSet() * @see Collections#unmodifiableSet(java.util.Set) */ @Test public void setOfVotersInDistrictInUnmodifiableSet() throws ClassNotFoundException { @@ -270,15 +263,27 @@ public void getAllPersonsEligibleToVote() { // Test helpers private static Matcher
+ * Method references are another syntactic addition to JDK 8. They are intended to be used in lambda expressions,
+ * preventing unnecessary boilerplate. Consider the following lambda from an earlier test:
+ * books.stream().map(b -> b.getTitle()). Here the lambda does nothing more than invoke a method on each
+ * element of the stream. This can be written alternatively as: books.stream().map(Book::getTitle). Both
+ * forms are equivalent.
+ *
+ * The parameter list and return type when using a method reference must match the signature of the method. A mismatch + * between the two will result in a compile error, just as invoking a method with parameters or return type with an + * incorrect type will cause a compile error. + * For example, consider the following code: + *
+ * public class Printers {
+ * public static void print(String s) {...}
+ * }
+ *
+ * Note that the printNumber method takes a single String parameter, and has a void return
+ * type. Although declared using different type names, this is the same signature as {@link Consumer}, the functional
+ * interface that's passed to {@link Iterable#forEach(Consumer)}. Since they match, we can use a reference to the
+ * print method when invoking forEach on a list of Strings, like so:
+ *
+ * Arrays.asList("a", "b", "c").forEach(Printers::print)
+ *
+ * If we changed the signature of print to public static void print(String s, String t)
+ * the use of the method reference would no longer compile, with an error message pointing to the mismatch in argument
+ * lists.
+ *
+ * + * There are four different kinds of methods that can be used with the method reference syntax: + *
+ * Static method belonging to a particular class
+ *
+ * In the previous example, the Printers::print method reference is to a static method ('print') belonging
+ * to the Printers class. Here the argument list of the lambda must match the argument list of the method, the first
+ * argument to the lambda is the first argument passed into the method.
+ *
+ * Instance method bound to a particular object instance
+ *
+ * It's possible to use a method invoked an a specific instance of a class. Consider the following code:
+ *
+ * public class Document {
+ * // field, constructor, etc
+ *
+ * public String getPageContent(int pageNumber) {
+ * return this.pages.get(pageNumber).getContent();
+ * }
+ * }
+ *
+ * public static void printPages(Document doc, int[] pageNumbers) {
+ * Arrays.stream(pageNumbers).map(doc::getPageContent).forEach(Printers::print);
+ * }
+ *
+ *
+ * In this case, when the map operation runs, the method getPageContent will
+ * be invoked on the doc instance. Regardless of the current page number at that point
+ * of the stream, it will always be transformed by calling the equivalent of doc.getPageContent(i).
+ *
+ *
+ * Instance method belonging to a particular class
+ *
+ * When iterating over a stream of objects, you can invoke a method on each object by using an instance method
+ * reference. As in this code:
+ *
+ * public static void printDocuments(List<Page> pages) {
+ * pages.stream().map(Page::getContent).forEach(Printers::print);
+ * }
+ *
+ * In this case the method getContent will still be invoked on an instance of Page, however,
+ * it will be invoked on each Page instance that is mapped over.
+ *
+ *
+ * Constructor belonging to a particular class
+ *
+ * By now, we know how to use method references for static methods and instance methods, that leaves an odd case:
+ * constructors.
+ *
+ * While we don't invoke a constructor like a static method, it is useful to think of it that way. Currently we write:
+ * Page p = new Page("content"); but imagine we changed the syntax of the Java language to allow this:
+ * Page p = Page.new("content");. We can consider the Page.new method to have the exact
+ * semantics of a constructor, that is, use a reference to the class object to invoke the constructor method and return
+ * the newly created instance as the result of new.
+ *
+ * public static Stream<Page> createPagesFrom(Stream<String> contents) {
+ * return contents.map(Page::new).
+ * }
+ *
+ * The method will return a Stream of newly constructed Page objects. new is
+ * still a special keyword in Java, but can now be used in the method reference construct. Note that just like other
+ * method references, the method signature of the constructor must match the types fed by the map
+ * operation.
+ *
+ *
+ */
+@SuppressWarnings("unchecked")
+public class Exercise_4_Test {
+
+ /**
+ * The Documents class has a method which transforms a list of Document into a list of
+ * their titles. The implementation has already been filled out, but it uses a lambda, as in:
+ * .map(document -> document.getTitle())
+ * Documents class has a method which calculates a list of the character counts of Pages in a
+ * Document. The method characterCount can be applied to each Page to calculate the number of
+ * characters in that page. Currently it is invoked using a lambda.
+ * characterCount method.
+ *
+ * @see Documents#pageCharacterCounts(Document)
+ * @see Documents#characterCount(Page)
+ */
+ @Test
+ public void getListOfPageCharacterCountsFromDocumentUsingReferenceOfStaticMethodBelongingToAClass() {
+ Document diary = new Document("My Diary", Arrays.asList(
+ new Page("Today I went shopping"),
+ new Page("Today I did maths"),
+ new Page("Today I wrote in my diary")));
+
+ assertThat(Documents.pageCharacterCounts(diary), contains(21, 17, 25));
+ }
+
+ /**
+ * The Documents class has a method which takes a PagePrinter and renders a
+ * Document to text. The method uses two lambda expressions where method references can be used. In
+ * this case the method references are to methods belonging to a particular instance object.
+ * Document class has a method which can create a new Document where all the pages have had a
+ * footer appended to it of the format "Document: {title}". The method uses two lambda expressions where method
+ * references can be used. In this case the method references are to methods belonging to this object
+ * instance. That is, the methods to be invoked should be invoked on this.
+ * this
+ * instance.
+ */
+ @Test
+ public void transformPagesToHaveFooterUsingReferenceOfInstanceMethodBelonginToThisObject() {
+ Document diary = new Document("My Diary", Arrays.asList(
+ new Page("Today I went shopping"),
+ new Page("Today I did maths"),
+ new Page("Today I wrote in my diary")));
+
+ Document diaryWithFooters = diary.copyWithFooter();
+
+ assertThat(diaryWithFooters.getPages(), everyItem(pageEndingWith("Document: My Diary")));
+ }
+
+
+ /**
+ * The Documents class has a method which can translate a document into another language. The method
+ * uses a lambda expression to construct each translated Page, where it could use a method reference
+ * to Page's constructor.
+ * Page.
+ *
+ * @see Documents#translate(Document, Translator)
+ * @see Translator.Languages
+ * @see Page
+ */
+ @Test
+ public void createNewDocumentWithTranslatedPagesUsingReferenceOfConstructorMethod() {
+ Document diary = new Document("My Diary", Arrays.asList(
+ new Page("Today I went shopping"),
+ new Page("Today I did maths"),
+ new Page("Today I wrote in my diary")));
+
+ Document translated = Documents.translate(diary, Languages.REVERSISH);
+
+ assertThat(translated.getPages(),
+ contains(pageContaining("gnippohs tnew I yadoT"),
+ pageContaining("shtam did I yadoT"),
+ pageContaining("yraid ym ni etorw I yadoT")));
+ }
+
+ private static Matcher+ * The introduction of Default Methods is intended to allow for libraries to evolve more easily - with the + * JDK Collections library as their first main user. They permit adding concrete methods, with an implementation, + * to Java interfaces. Prior to JDK 8, every method on an interface had to be abstract, with implementations provided + * by classes. With JDK 8, it's possible to declare the following interface: + *
+ *
+ *
+ * // (stripped down version of the real Iterable.java)
+ * public interface Iterable {
+ *
+ * Iterator iterator(); // As in prior versions
+ *
+ * // example of a new JDK 8 default method
+ * default void forEach(Consumer action) {
+ * Objects.requireNonNull(action);
+ * for (T t : this) {
+ * action.accept(t);
+ * }
+ * }
+ * }
+ *
+ *
+ * In this case the method forEach is a default method with a concrete implementation. With this
+ * declaration forEach() can be invoked on any implementation of Iterable. This is very
+ * similar to adding a concrete method to an abstract class -- if no implementation overrides it, the code in the method
+ * on the interface is executed. Crucially, the new method can be added without causing compiler errors in the client
+ * code. Consider if a normal forEach method was added to Iterable: every class that
+ * implemented the Iterable interface would now fail to compile. Using default methods, the interface can
+ * be evolved without breaking client code.
+ * + * Allowing evolution of a library is the primary use case of default methods. + *
+ *+ *
java.lang.Object. This last case is what occurs if your class does not override
+ * toString. However, if anywhere in the inheritance hierarchy from your class to Object, toString is
+ * implemented, that would be executed instead of Object's toString. This behaviour is still in
+ * place in JDK 8, but has been augmented to cope with default methods.
+ *
+ *
+ * The main difference between superclass methods and default methods in JDK 8 is that there is only single
+ * inheritance of classes, while there is multiple inheritance of interfaces. As such, there needs to be
+ * some extra rules around method lookup.
+ *
+ * Method lookup has all the following characteristics:
+ *
+ *
class A", "class B extends A", and "class C
+ * extends B", if a method is invoked on C, the Java runtime will first look for the implementation in C,
+ * then B, then A, then finally java.lang.Object, invoking the first method it finds. This is also the case with
+ * super-interfaces. Indeed, given "interface X", "interface Y extends X" and "
+ * interface Z extends Y", and declaring "class C extends B, implements Z", the lookup for a
+ * default method would traverse the hierarchy in the following order: C -> B -> A -> Object -> Z -> Y -> X.
+ *
+ * interface A {
+ * default void speak() { System.out.println("A says hi!"; }
+ * }
+ * interface B {
+ * default void speak() { System.out.println("Regards from B!"; }
+ * }
+ * class C implements A, B { } // compiler error: inherits unrelated default methods from A and B
+ * interface Y extends A, B" results in the same compile error.
+ * This error can be resolved by removing ambiguity in the subtype, by overriding the default method. This can be any
+ * compliant implementation, including directly invoking a specific inherited default method. A new syntax in JDK 8 is
+ * available to allow choosing an inherited default method, like so:
+ *
+ * class C implements A, B {
+ * public void speak() { A.super.speak(); } // prints "A says hi!"
+ * }
+ * instanceOfC.speak(); is executed, the default speak from
+ * interface A is invoked. This syntax is also available within default method bodies, allowing an interface
+ * to choose an implementation from one of its super-interfaces. Note that this syntax is not entirely unfamiliar: it
+ * can be considered just like invoking super.someMethod();, except that with the single inheritance of
+ * classes, the name of the super class is can be nothing other than the single superclass, so it can remain implicit.
+ * + * In a way. Java has always supported multiple inheritance of interfaces, previously this did not include any of the + * implementation, just the contract. Inheritance can be subdivided again, into inheritance of state, and + * inheritance of behaviour. Default methods introduce the latter, multiple inheritance of behaviour. + *
There are two aspects to the diamond problem: a) disambiguating implementations and b) handling state. We have seen
+ * how ambiguities are resolved in JDK 8, requiring that users specify the implementation at compile time. Default
+ * methods do not introduce a problem in that aspect of the diamond problem. The second problem, state, is where trickier
+ * issues of the diamond problem live. It can be too easy to accidentally introduce bugs into an implementing class
+ * because it must adhere to the contract defined in the interface and/or superclass, which can include maintaining
+ * state. Any methods which manipulate that state must also be invoked in the implementing class, and accidentally
+ * "losing" that invocation is an easy way to introduce a subtle bug. Also, there is the problem between the ordering of
+ * conflicting methods, that cannot be resolved by disambiguating. Default methods in Java avoid this issue, due to an
+ * existing virtue of interfaces, that they do not contain state. Because an interface cannot be constructed
+ * with fields, there is no state available to encounter this issue. Java still has single inheritance of state,
+ * through superclasses. If the contract of an interface requires state (like, e.g. Iterator) it will be
+ * provided through the single inheritance chain.
+ *
+ * Note that there are still ways to "simulate" state in interfaces with default methods, since there is no restriction + * on accessing static fields defined in other classes. However, that should be avoided for all the reasons that both + * multiple inheritance of state, and global mutable state should be avoided. + *
+ * + * @see Iterable#forEach(Consumer) + */ +@SuppressWarnings("unchecked") +public class Exercise_5_Test { + + /* + Exercise on default methods in interfaces does not apply pre-java8. + */ + +} diff --git a/src/test/java/org/adoptopenjdk/lambda/tutorial/util/FeatureMatchers.java b/src/test/java/org/adoptopenjdk/lambda/tutorial/util/FeatureMatchers.java index 7010d57..005c066 100644 --- a/src/test/java/org/adoptopenjdk/lambda/tutorial/util/FeatureMatchers.java +++ b/src/test/java/org/adoptopenjdk/lambda/tutorial/util/FeatureMatchers.java @@ -25,7 +25,6 @@ import org.hamcrest.FeatureMatcher; import org.hamcrest.Matcher; -import java.util.function.Function; /** * Helper utility for matching on features @@ -46,14 +45,18 @@ private FeatureMatchers() {} * @return A Matcher */ public static