Love and hate for Java 8

Java 8 brings exciting developments, but as with any new technology, you can count on the good, the bad, and the headaches

1 2 3 4 5 Page 3
Page 3 of 5

Let's look at one more quick example.

Old way without Lambda:

Runnable runnable1 = new Runnable() {


public void run() {

System.out.println("Running without Lambda");



New way with Lambda

Runnable runnable2 = () -> { System.out.println("Running from Lambda"); };

As you can see, using Lambda expressions will often make the code easier to read and require fewer lines. This addition has excited a lot of people around the Java community. With Scala, however, we have a somewhat widely used JVM language with all of these features already in it.

Not surprising, the Scala community is incredulous because many of Java 8's additions merely look like Scala replacing the => operator with ->. In some cases, Java 8's syntax has been pointed out to be more verbose or less clear than Scala's. It's yet to be determined what, if anything, it will do to languages like Scala that are built around Lambda expressions.

On the one hand, if Java continues to evolve and implement everything around Lambda as Scala has done, then there may be no need for Scala. On the other hand, if it is left alone to provide only core functionality, such as helping with anonymous inner classes, then Scala and other languages will continue to thrive and ride on top of Java as they do now. This is the best outcome; it will allow other languages to continue to grow and be inventive without worrying about whether or not they will become obsolete.

Java time
Java has had a long history with time, pun intended. First there was the java.util.Date class, which quickly showed us that Sun could deprecate methods in record time, but that deprecated methods might be eternal. Oh, don't forget java.sql.Date, which helped us realize the time and place for using fully qualified names (FQNs) in code.

Next, there was the Calendar, which realized that code might have to deal with more than one part of the world in the same JVM. But dealing with times and dates required a lot of monkey code and fiddling with a fractured Java API. From this was born third-party libraries such as JodaTime among others. Now Java has decided belatedly to clean it up with a java.time package. This looks to me like everything we always wanted the various temporal APIs to be.

While it is certainly to be applauded, the Java API could use some cleanup and depth on other items in the spacetime continuum: distances, mass, weights and more. I also think Currency could be handled better. While I generally believe the Java API needs a good pruning rather than more items, I have to say this basic element of nature probably should have the kind of standard compatibility the Java API is intended to provide.

1 2 3 4 5 Page 3
Page 3 of 5
How to choose a low-code development platform