Skip to main content

Small Changes to Java 7 via Project Coin and Why They are Useful


Did you know how new features were added into Java 7? The following are functionalities that can be considered.
Source: [1]
Project Coin is all about the changes in the range from syntactic sugar to new language feature. This is what we're talking about today.

Since Java 7 is the first version developed in an open source manner, there is an amount of actions that must be performed for any changes as follows:
  • Update the Java Language Specification (JSL)
  • Implement a prototype in the source compiler
  • Add library support essential for the change
  • Write tests and examples
  • Update document
  • Etc, ...
Project Coin has submitted a lot of proposals (almost 70) but only some of them are chosen to Java 7. Why? Briefly, Java is a rich static type system and it has a lot of possible interaction points between different bits of it. Making changes to this type system is prone to creating unexpected surprises.

Wow! It is tough, right? Let's take a look what features Project Coin brought to Java 7.

Strings in switch statement

Question: Why do we need "switch"? (already supported by prior Java 7)
Answer: To avoid lots of ugly nested "ifs".
Question: Why do we need "string" in "switch"?
Answer: Just to make life in Java 7 a little bit easier. Agree?

Enhanced syntax for numeric literals

Underscores in numbers to improve readability.
E.g: 100_000_000 and 10_000_000 are much more readable than 100000000 and 10000000.

Improved exception handling

- Multicatch: it groups a family of exceptions into one catch statement; this feature can reduce code duplication.
- Final rethrow: it won't force to declare the exception signature. For example, my IDE complains of the block below with Java 6 compiler, but Java 7.

However, the issue here is the real dynamic type of the exception has been swallowed if we declare the exception signature.
And, the change in Java 7 is just simple as follows: 

try {
  doSomethingWhichMightThrowIOException();
  doSomethingElseWhichMightThrowSQLException();
} catch (final Exception e) {
  //...
  throw e;
}

Why is final keyword useful? Because it provides a new semantics of catch and rethrow. The appearance of the final keyword indicates that the type that’s actually thrown is the runtime type of the exception that was encountered.

Note: If a catch block handles more than one exception type, then the catch parameter is implicitly final.

Try-with-resources

#Funfact: Virtually no one gets manual resource closing 100 percent right.
Therefore, using try-with-resources to eliminate unnecessary bugs from your codebase.

try(OutputStream out = new FileOutputStream(file);
InputStream is = url.openStream()){
 byte[] buf = new byte[4096];
 int len;
 while ((len = is.read(buf)) > 0) {
  out.write(buf, 0, len);
 }
}

Diamond syntax

To avoid the definition and setup of instances can be really verbose.
#Funfact: Why "diamond syntax" name? Because original name, ITIGIC (Improved Type Inference for Generic Instance Creation), is a very long(stupid) name and the shortened type information looks like a diamond.

Simplified varagrs method invocation

What is it? It just moves a warning about type information for a very specific case where varargs combines with generics in a method signature.

An admitted weaknesses of Java’s generics—you aren’t normally allowed to create an array of a known generic type. For example, this won't compile:

HashMap<String, String>[] arrayHm = new HashMap<>[2];

So when it runs into this circumstance, the compiler cheats and breaks its own rule about the forbidden array of generic type. It throws the warning "unchecked" which is darkly meaning. Oops! Then, dummy developers want to know why their methods are "unchecked"? They need an explanation.

To make things easier for developers and by annotating the method with "@SafeVarargs", the developer essentially asserts that method doesn't perform any unsafe operations. Known issue! ;)

Reference:



[1]. Benjamin J. Evans and Martijn Verburg, “The Well-Grounded Java Developer: Vital techniques of Java 7 and polyglot programming"

Labels:

Comments

Post a Comment

Popular posts from this blog

How to convert time between timezone in Java, Primefaces?

I use the calendar Primefaces component with timeOnly and timeZone attributes for using only hour format (HH:mm). Like this: <p:calendar id="xabsOvertimeTimeFrom" pattern="HH:mm" timeOnly="true" value="#{data.dateFrom}" timeZone="#{data.timeZone}"/> We can convert the value of #{data.dateFrom} from GMT/UTC time zone to local, conversely, from local time zone to GMT/UTC time zone. Here is my functions: package vn.nvanhuong.timezoneconverter; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Calendar; import java.util.Date; import java.util.TimeZone; public class TimeZoneConverter { /** * convert a date with hour format (HH:mm) from local time zone to UTC time zone */ public static Date convertHourToUTCTimeZone(Date inputDate) throws ParseException { if(inputDate == null){ return null; } Calendar calendar = Calendar.getInstance(); calendar.setTime(inputDate); int ...
Post a Comment
Read more

JSF, Primefaces - Invoking Application Code Even When Validation Failed

A use case I have a form which has requirements as follow: - There are some mandatory fields. - Validation is triggered when changing value on each field. - A button "Next" is enable only when all fields are entered. It turns to disabled if any field is empty. My first approach I defined a variable "isDisableNext" at a backend bean "Controller" for dynamically disabling/enabling the "Next" button by performing event "onValueChange", but, it had a problem: <h:form id="personForm"> <p:outputLabel value="First Name" for="firstName"/> <p:inputText id="firstName" value="#{person.firstName}" required="true"> <p:ajax event="change" listener="#{controller.onValueChange}" update="nextButton"/> </p:inputText> <p:outputLabel value="Last Name" for="lastName"/> <p:i...
Post a Comment
Read more

Styling Sort Icons Using Font Awesome for Primefaces' Data Table

So far, Primefaces has used image sprites for displaying the sort icons. This leads to a problem if we want to make a different style for these icons; for example, I would make the icon "arrow up" more blurry at the first time the table loading because I want to highlight the icon "arrow down". I found a way that I can replace these icons with Font Awesome icons. We will use "CSS Pseudo-classes" to achieve it. The hardest thing here is that we should handle displaying icons in different cases. There is a case both "arrow up" and "arrow down" showing and other case is only one of these icons is shown. .ui-sortable-column-icon.ui-icon.ui-icon-carat-2-n-s { background-image: none; margin-left: 5px; font-size: 1.1666em; position: relative; } .ui-sortable-column-icon.ui-icon.ui-icon-carat-2-n-s:not(.ui-icon-triangle-1-s)::before { content: "\f106"; font-family: "FontAwesome"; position: ...
Post a Comment
Read more

Attribute 'for' of label component with id xxxx is not defined

I got the warning in the log file when I have used the tag <h:outputLabel> without attribute " for " in xhtml file. It was really polluting my server log files. The logged information actually makes sense anyway! We could find an answer as the following: "Having h:outputLabel without a "for" attribute is meaningless. If you are not attaching the label, you should be using h:outputText instead of h:outputLabel." However, these solutions are not possible just for my situation. Instead of using h:outputText for only displaying text, my team has used h:outputLabel too many places. We were nearly in our release time (next day) so it is quite risky and takes much efforts if we try to correct it. Because the style (with CSS) is already done with h:ouputLabel . The alternative by adding attribute " for " the existing h:outputLabel is not reasonable either. I really need to find another solution. Fortunately, I came across a way if I cha...
Post a Comment
Read more

Junit - Test fails on French or German string assertion

In my previous post about building a regex to check a text without special characters but allow German and French . I met a problem that the unit test works fine on my machine using Eclipse, but it was fail when running on Jenkins' build job. Here is my test: @Test public void shouldAllowFrenchAndGermanCharacters(){ String source = "ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ"; assertFalse(SpecialCharactersUtils.isExistSpecialCharater(source)); } Production code: public static boolean isExistNotAllowedCharacters(String source){ Pattern regex = Pattern.compile("^[a-zA-Z_0-9_ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ]*$"); Matcher matcher = regex.matcher(source); return !matcher.matches(); } The result likes the following: Failed tests: SpecialCharactersUtilsTest.shouldAllowFrenchAndGermanCharacters:32 null A guy from stackoverflow.com says: "This is probably due to the default encoding used for your Java source files. The ö in the string literal in the J...
5 comments
Read more