Java 9: A Look at Milling Project Coin
Follow along this explanation of JEP 213: Milling Project Coin. Check out the tweaks coming to the Java language for identifier names, SafeVarargs, and more.
Join the DZone community and get the full member experience.
Join For FreeIn this section, we are going to discuss the new Java 9 enhancements as part of JEP 213: Milling Project Coin. The purpose of JEP 213 is to address some rough edges. Milling Project Coin has five small amendments to the Java programming language.
1. Underscore as an Identifier Name
In Java 8, an underscore ( _ ) is allowed as an identifier name, but the compiler will show a warning that "It will not be supported after Java SE 8." So Java 9 completed the removal of underscore from the set of legal identifier names.
Java 8: Warning for _ as the identifier name
Java 9: Error for _ as the identifier name
The underscore will be used as a keyword for an unnamed lambda parameter in future Java releases (JEP 302).That's the reason the compiler stated "_" is a keyword while compiling the Java file.
2. Enhancement of try-with-resources Statements
Java 7 introduced the try-with-resources statement, where resources will be closed automatically after the execution. It requires an additional variable for the resources to be assigned. But Java 9 manages the same with the final or effectively final variables. The effectively final variable is the variable or the parameter whose values will never be changed once it is initialized.
Example: int num=10;
The above num is treated as effectively final by the compiler until you change the value, so the effectively final variable is treated like the final variable unless it is changed.
Java 7: Requires the additional variable:
InputStream inputStream = new FileInputStream("test.txt");
try (InputStream stream = inputStream) {} catch (IOException e) {}
Java 9: Doesn't require additional variables:
InputStream inputStream = new FileInputStream("test.txt");
try (inputStream) {} catch (IOException e) {}
3. Private Methods in the Interface
Please refer my previous post on Java 9 Interface for this section.
4. SafeVarargs to Support Private Methods
Java 7 introduced the @SafeVarargs annotation to final, static methods, and constructors. Java 9 extends this functionality to use for private methods, too.
Example:
import java.util.Arrays;
import java.util.List;
public class Test {
public static void main(String[] args) {
Test test = new Test();
test.printList(Arrays.asList("Apple", "Bat"));
}
private void printList(List < String > ...stringList) {
for (List <String> list: stringList)
System.out.println(list);
}
}
Upon compiling the above code with Java 8 using the javac tool with -Xlink:unchecked to get a detailed warning, it throws two warnings, as seen below:
We can avoid this warning message by annotating the private method with the @SafeVarargs annotation in Java 9. Compile the same code by annotating the printList with @SafeVarargs.
5. Diamond Operators With Anonymous Classes
Java 7 introduced the diamond operator ( <> ) in generic class instantiation contexts. The following code shows its use:
List<String> list1 = new ArrayList<String>();
List<String> list2 = new ArrayList<>();
list1 is the pre-Java 7 approach to instantiate a generic class. The actual type argument is specified while instantiating it. But list2 is instantiated without mentioning the actual type argument, which was introduced in Java 7.
But in Java 7, we cannot use the diamond operator in anonymous classes. Java 9 enhanced the type inference algorithm to tell whether the inferred type is denotable when analyzing an anonymous class that supports the diamond operator.
Example:
Iterator <String> iter = new Iterator <> () {
@Override
public boolean hasNext() {
// TODO Auto-generated method stub
return false;
}
@Override
public String next() {
// TODO Auto-generated method stub
return null;
}
};
The above snippet will throw the compile time error "<> cannot be used with anonymous classes." But the same code will be successfully compiled in Java 9.
Opinions expressed by DZone contributors are their own.
Comments