noException in stream operation

This article is about some simple coding practice. Nothing really fancy. It is also discussed on StackOverflow.

You just refactored a huge and complex loop to a more readable stream expression forgetting that some of the method calls throw exception. The method containing this code throws this exception, it is declared in the method head. You do not want to deal with this exception on this level. It is cared about on higher levels of the call stack. And you get that annoying error in the code like a splinter under the nail.

Say you want to convert strings to IP addresses.

private static final String[] allowed = {"127.0.0.1", "::1"};

...

Arrays.stream(allowed)
      .map(InetAddress::getByName)
      .collect(Collectors.toSet());

The problem is that getByName(String host) throws UnknownHostException. This is not a RuntimeException so it has to be checked but the method map() needs a Function as an argument and Function does not throw any exception. We need a version of getByName that does not throw exception (or we need to use a different language that is more lame with exceptions).

Arrays.stream(allowed)
       .map(s -> {
                   try {
                     return InetAddress.getByName(s);
                     } catch (UnknownHostException e) {
                     throw new RuntimeException(e);
                     }
                 }).collect(Collectors.toSet());

This is just more ugly and messier than the original loop was. Could this try/catch whatever thing be put into a utility class and call some lame static method that wraps the actual call? Kind of yes. Import the following method statically:

    public interface ExceptionalSupplier<T> {
        T apply() throws Exception;
    }
...
    public static <T> T lame(ExceptionalSupplier<T> z) {
        try {
            return z.apply();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

After the import you can write

Arrays.stream(allowed)
      .map(s -> lame(() -> InetAddress.getByName(s)))
      .collect(Collectors.toSet());

the catch is that you can not just lame( ... ) the call. You have to convert it to an exceptional supplier. A functional interface that has the same look-alike as Supplier but it allows exceptions.

Still not ideal. (Well, it is Java, so what did you expect?) Okay. It is Java, but it still can be made better. What if instead of converting the expression through a supplier to an expression that is not throwing the exception we could convert the “Function” that throws the exception into one that is not throwing the exception. We need a method that accepts an exceptional function and returns a normal function. That way we can save the () -> noise in our code. Readability rulez.

    public interface ExceptionalFunction<T, R> {
        R apply(T r) throws Exception;
    }
...
    public static <T, R> Function<T, R> lame(ExceptionalFunction<T, R> f) {
        return (T r) -> {
            try {
                return f.apply(r);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        };
    }

With that utility the “final” expression will be

Collection<InetAddress> allowedAddresses =
        Arrays.stream(allowed)
              .map(lame(InetAddress::getByName))
              .collect(Collectors.toSet());

The actual utility class in the GIST defines a WrapperException extending RuntimeException so that you can catch the exception somewhere in the method, like

public myMethod() throws IOException {
try{
    ... do whatever here we do ...
   } catch (RuntTimeExceptionWrapper.WrapperException we) {
       throw (IOException) we.getCause();
   }

That way the method will throw the exception but if anywhere there is another RuntimeException that will be throwing up uncaught.

This is just a simple, nice and little trick that helps you keep up with Java, which is backward compatible instead of starting development with some other language that is modern, clutter-free and let’s you focus more on the functionality you need to code instead of coding techniques.

Advertisement

New Regex Features in Java 9

I recently received my complimentary copy of the book “Java 9 Regular Expressions” from Anubhava Srivastava published by Packt. The book is a good tutorial and introduction to anyone who wants to learn what regular expressions are and start from scratch. Those who know how to use regex the book may still be interesting to reiterate the knowledge and to deepen into a more complex feature like zero-length assertions, backreferences, and alike.

In this article, I will focus on the regular expression features that are specific to Java 9 and were not available in earlier version of the JDK. There is not many, though.

Java 9 Regular Expression Module

The JDK in Java 9 is split up into modules. One could rightfully expect that there is a new module for the regular expression handling packages and classes. Actually, there is none. The module java.base is the default module on which all other modules depend on by default and thus the classes of the exported packages are always available in Java applications. The regular expression package java.util.regex is exported by this module. This makes the development a bit simpler: there is no need to explicitly ‘require’ a module if we want to use regular expressions in our code. It seems that regular expressions are so essential to Java that it got included in the base module.

Regular Expression Classes

The package java.util.regex contains the classes

• MatchResult
• Matcher
• Pattern and
• PatternSyntaxException

The only class that has changed API is Matcher.

Changes in class Matcher

The class Matcher adds five new methods. Four of those are overloaded versions of already existing methods. These are:

• appendReplacement
• appendTail
• replaceAll
• replaceFirst
• results

The first four exists in earlier versions and there is only change in the types of the arguments (after all that is what overloading means).

appendReplacement/Tail

In case of appendReplacement and appendTail the only difference is that the argument can also be a StringBuilder and not only StringBuffer. Considering that StringBuilder introduced in Java 1.5 something like 13 years ago nobody should say that this is an inconsiderate act.

It is interesting though how the currently online version of the API JDK documents the behaviour of appendReplacement for StringBuilder argument. The older, StringBuffer argumented method explicitly documents that the replacement string may contain named references that will be replaced by the corresponding group. The StringBuilder argumented version misses this. The documentation seems like copy/paste and then edited. The text replaces “buffer” to “builder” and alike and the text documenting the named reference feature is deleted.

I tried the functionality using Java 9 build160 and the outcome is the same for these two method versions. This should not be a surprise since the source code of the two methods is the same, a simple copy/paste in the JDK with the exception of the argument type.

Seems that you can use

    @Test
    public void testAppendReplacement() {

        Pattern p = Pattern.compile("cat(?<plural>z?s?)");
        //Pattern p = Pattern.compile("cat(z?s?)");
        Matcher m = p.matcher("one catz two cats in the yard");
        StringBuilder sb = new StringBuilder();
        while (m.find()) {
            m.appendReplacement(sb, "dog${plural}");
            //m.appendReplacement(sb, "dog$001");
        }
        m.appendTail(sb);
        String result = sb.toString();
        assertEquals("one dogz two dogs in the yard", result);
    }

both the commented lines or the line above each. The documentation, however speaks only about the numbered references.

replaceAll/First

This is also an “old” method that replaces matched groups with some new strings. The only difference between the old version and the new is how the replacement string is provided. In the old version the string was given as a String calculated before the method was invoked. In the new version the string is provided as a Function<MatchResult,String>. This function is invoked for each match result and the replacement string can be calculated on the fly.

Knowing that the class Function was introduced only 3 years ago in Java 8 the new use of it in regular expressions may be a little slap-dash. Or, perhaps … may be we should see this as a hint that ten years from now, when the class Fuction will be 13 years old, we will still have Java 9?

Lets dig a bit deeper into these two methods. (Actually only to replaceAll because replaceFirst is the same except that it replaces only the first matched group.) I tried to create some not absolutely intricate examples when such a use could be valuable.

The first sample is from the JDK documentation:

    @Test
    public void demoReplaceAllFunction() {
        Pattern pattern = Pattern.compile("dog");
        Matcher matcher = pattern.matcher("zzzdogzzzdogzzz");
        String result = matcher.replaceAll(mr -> mr.group().toUpperCase());
        assertEquals("zzzDOGzzzDOGzzz", result);
    }

It is not too complex and shows the functionality. The use of a lambda expression is absolutely adequate. I can not imagine a simpler way to uppercase the constant string literal “dog”. Perhaps only writing “DOG”. Okay I am just kidding. But really this example is too simple. It is okay for the documentation where anything more complex would distract the reader from the functionality of the documented method. Really: do not expect less intricate examples in a JavaDoc. It describes how to use the API and not why the API was created an designed that way.

But here and now we will look at some more complex examples. We want to replace in a string the # characters with the numbers 1, 2, 3 and so on. The string contains numbered items and in case we insert a new one into the string we do not want to renumber manually. Sometimes we group two items, in which case we write ## and then we just want to skip a serial number for the next #. Since we have a unit test the code describes the functionality better than I can put it into words:

    @Test
    public void countSampleReplaceAllFunction() {
        AtomicInteger counter = new AtomicInteger(0);
        Pattern pattern = Pattern.compile("#+");
        Matcher matcher = pattern.matcher("# first item\n" +
                "# second item\n" +
                "## third and fourth\n" +
                "## item 5 and 6\n" +
                "# item 7");
        String result = matcher.replaceAll(mr -> "" + counter.addAndGet(mr.group().length()));
        assertEquals("1 first item\n" +
                "2 second item\n" +
                "4 third and fourth\n" +
                "6 item 5 and 6\n" +
                "7 item 7", result);
    }

The lambda expression passed to replaceAll gets the counter and calculates the next value. If we used one # then it increases it by 1 if we used two, then it adds two to the counter and so on. Because a lambda expression can not change the value of a variable in the surrounding environment (the variable has to be effectively final) the counter can not be an int or Integer variable. We need an object that holds an int value and can be changed. AtomicInteger is exactly that even if we do not use the atomic feature of it.

The next example goes even further and does some mathematical calculation. It replaces any floating point formatted number in the string to the sine value of it. That way it corrects our sentence since sin(pi) is not even close to pi, which can not be precisely expressed here. It is rather close to zero:

    @Test
    public void calculateSampleReplaceAllFunction() {
        Pattern pattern = Pattern.compile("\\d+(?:\\.\\d+)?(?:[Ee][+-]?\\d{1,2})?");
        Matcher matcher = pattern.matcher("The sin(pi) is 3.1415926");
        String result = matcher.replaceAll(mr -> "" + (Math.sin(Double.parseDouble(mr.group()))));
        assertEquals("The sin(pi) is 5.3589793170057245E-8", result);
    }

We will also play around a bit with this calculation for the demonstration of the last method in our list, which is a brand new one in the Matcher class.

Stream results()

The new method results() returns a stream of the matching results. To be more precise it returns a Stream of MatchResult objects. In the example below we use it to collect any floating point formatted number from the string and print their sine value comma separated:

    @Test
    public void resultsTest() {
        Pattern pattern = Pattern.compile("\\d+(?:\\.\\d+)?(?:[Ee][+-]?\\d{1,2})?");
        Matcher matcher = pattern.matcher("Pi is around 3.1415926 and not 3.2 even in Indiana");
        String result = String.join(",",
                matcher
                        .results()
                        .map(mr -> "" + (Math.sin(Double.parseDouble(mr.group()))))
                        .collect(Collectors.toList()));
        assertEquals("5.3589793170057245E-8,-0.058374143427580086", result);
    }

Summary

The new regular expression methods introduced in the Java 9 JDK are not essentially different from what was already available. They are neat and handy and in some situation , hey may ease programming. There is nothing that could have not been introduced in the earlier version. This is just the way of Java to make such changes to the JDK slow and well thought. After all that is why we love Java, don’t we?

The whole code copy paste from the IDE can be found and downloaded from the following gist

What is private in Java 9?

When doing interviews I experience that most of the candidates do not know what private modifier in Java really means. They know something about it that is enough for every day coding, but far from complete. It is not a problem. Knowing enough is, well… enough. But it is still interesting to know some of the inner working of Java. In some rare cases it may shed light on some details. If nothing else then it is entertaining .orElse(whyDoYouReadIt) ?

By the way: mentioning interviews is a good opportunity to write rants even if the statements and implications related to my person are, in my view, false. After all, my person is not important and distancing myself from the fact that it criticizes me I find that article interesting and the conclusions about the interviews are important and actually totally in line with my opinion.

This article is to describe some of the Java facts hopefully in a bit more readable way than reading the language standard.

So what is private?

private is an access modifier in Java. If you have a private member (method, field, inner or nested class or a nested interface) of a class it can only be used by code, which is in the same class. The interesting question is: what happens when there are more than one classes that the private method is in? How can it be in more than one class? In case there is a class that contains another class and there is a private method inside the inner/nested class then it is inside the inner/nested class and also in the top level class.

Can a private method inside an enclosed class called from the outer class? Can a code inside an enclosed class call a private method in the outer class? The answer is yes in both cases. The sample code

package javax0.package1;

class TopLevelClass {

  void topMethod(){
    NestedClass nc = new NestedClass();
    nc.method();
  }
  
  private int z;

  interface NestedInterface {
    default void method(){
      TopLevelClass tlc = new TopLevelClass();
      tlc.z++;
    }
  }

  static class NestedClass {
    private int k;

    private void method() {
      TopLevelClass tlc = new TopLevelClass();
      k = tlc.z;
    }
  }
}

clearly shows this situation: the nested class NestedClass and the nested interface NestedInterface both contain code that can access the outer class contained private field z. Similarly the top level class code can call the private method inside the nested class. The fact that this sample code does not actually perform anything reasonable is not important in this case.

If we compile this single source file we get three class files:

1. TopLevelClass$NestedClass.class
2. TopLevelClass$NestedInterface.class
3. TopLevelClass.class

That is because the JVM does not know what is top level and what is nested. The JVM does not know anything about nested and top level classes. For JVM a class is just a class. A top level class if you insist. That is mainly because the Java language 1.0 did not have nested and inner classes and the JVM was designed according to that. When inner and nested classes were introduced in Java 1.1 the compilation was modified only instead of the JVM so that the inner and nested classes remained a language feature but not handled by the JVM directly.

How can the top level class access a private method in another class that was nested in the source code, but when it is compiled it is just another “top level” class. They are on the same level. If the accessibility were changed to public then we could also access it from other classes, but we can not. The compiler will not allow any other code in other classes to access the private method and even if we did some trick to overcome the compiler the generated class fill will make the JVM to throw an exception. Private in Java is private.

What really happens is that the compiler generates special getter and setter methods to get access to the field z.

Such a bridge method is created for every private field or method that is accessed from a different class inside the same top level class. If the private whatever is not accessed from the enclosing class then the method is not generated. If the field is only read then only the getter is generated, if it is only set from outside then only the setter is generated.

This is also an interesting failure believing that a private field (or whatever) is accessible only from within the same object. That is the usual way we use these members when we program, but if the code has a reference of another instance of the same type then through that reference we can access the private fields of the other object just as good as we can access “our own” fields. Is this a rare case? You may think because you rarely program it. But in reality it is extremely frequent: the IDE usually generated the code for us and that is why some developer does not think about that. Without this it would hardly be possible to code the equals(Object other) method of classes.

What about Java 9?

So far there is nothing specific to Java 9 in this article and these days every Java article should be about Java 9 (or 10 already?).

If we look at access control generally then we have to talk about JPMS, and there are many great articles about that. codeFx has a good list of articles about it. Stephen Colebourne has nice articles.

Soon you will be able even to buy books about Java module systems from different publishers. I am in a lucky position that I can already read one in draft from Packt as a reviewer and I love it. But JPMS does not change “private” on this level. Still there will be nested classes and inner classes and bridge methods exactly the same way as before.

The little difference is that Java 9 now has private methods inside interfaces. This means that now we should be prepared to have syntethic bridge methods not only in inner and nested classes, but also in interfaces.

Takeaway …

Sometimes the simplest things are not as simple as they seem. After all the whole IT technology, science, engineering is nothing else but a bunch of zeroes and ones. It is just that we have a lot of them. Really a lot. If there was something new to you in this article then it should tell you that there are areas in the Java language and in the JVM that you may be interested to examine a bit more. For example:

• What is the difference between a nested and an inner class?
• Can you have a nested interface inside a class and similarly can you have an inner interface inside a class?
• What about classes or interfaces inside an interface? Can you have an inner class in an interface? How about a nested class?
• Can you write a code using reflection that list all the methods a class has? Will it list the synthetic methods? What modifiers will it have?
• When you compile an inner class it will have the compiled name Outer$Inner.class, which is a legitimate name. But what happens if there is a Outer$Inner.java source file? Figure it out!
• The generated synthetic methods also have legitim names. What happens if you define a method with that name? Is it Java specification or implementation specific what you see?
• How deep can you nest inner and nested classes and/or interfaces? Can a nested class contain an inner class? Can an inner class contain a nested class?
• What is your guess, why there is no symbolic name in the JDK for the synthetic modifier? Why can the actual modifier value be the same as the value for volatile fields?
• Can you have a static field, class or method inside a nested class?

The answer to those questions and the knowledge is not practical, I know. I have never ever seen any code or project where knowing that an inner class can not have a static field was giving any advantage. On the other hand thinking about these, getting the answers may give you some joy, like solving crosswords if that is your taste and a knowledge that still may be useful aiding to the understanding the technology in a way that we do not recognize. In some situation one person just finds a bug faster than other because she “feels” the technology. That is when you can not tell what was whispering the solution to your ears but something, knowledge like the above did. But it will only if you love to dig into those fine bits of the technology.

Last a trick question, even less practical than those above just for entertainment, if you like:

Puzzle

We know that it is not possible to have a static field inside an inner (not nested) class. Is it still possible to have a compiled class file generated by the Java compiler from an inner class that has a static method?