Wednesday Sep 24, 2014
Monday Sep 23, 2013
By Janice J. Heiss on Sep 23, 2013
by Timothy Beneke
Mark Reinhold, Oracle’s Chief Architect, the Java Platform Group, took the stage to kick off Sunday’s technical keynote at the Moscone Center. He began by quoting “father of Java” James Gosling. For Java to thrive, it must maintain what Gosling called the “feel of Java”. In other words, it must retain the key values of readability, simplicity, and universality.
“If we keep those,” said Reinhold, “then Java will remain not just productive but fun. It is not enough to simply add popular features each year.”
Lambda Expressions – The Single Largest Upgrade Ever
He turned to lambda expressions, which he described as the single largest upgrade to the programming model ever -- larger even than generics. “This is the first time we have done a carefully coordinated co-evolution of the JVM, the language, and the libraries all together – and the results still feel like Java,” said Reinhold.
He then welcomed Oracle Java Language Architect, Brian Goetz, to share the stage and began by remarking that while most developers understand that lambda offers a simple way to express code as data, some are not sure how it helps Java. Goetz responded that lambda expressions would more than help Java. “It’s going to change the way we all program in Java every day,” he explained. “Programming well is about finding the right abstractions. We want the code we write to look like the problem statements it’s trying to solve, so we can look at it and immediately know it’s correct. Java has always given us good tools for abstracting over data types. I wanted to do better in abstracting over patterns of behavior – that’s where lambda comes in.”
He illustrated this with some simple code that was, strictly speaking, “good” code, but weighed down with boilerplate and did not read like the problem statement it was trying to solve. It could be improved by using an inner class tool, but that too generated a lot of boilerplate. Reinhardt pointed out that improving the code made it less pleasant to work with, as if the developer was being punished for doing the right thing. This often causes developers to give up and do it the “dumb and ugly way”.
Lambdas can replace inner classes with a lambda expression which is simply an anonymous method that captures a behavior without a lot of syntactic boilerplate. “Lambdas are a nicer syntax,” said Goetz. “But they are also something deeper. It’s not just a compiler generating inner classes for you – it uses the invokedynamic feature to get more compact and higher performance code. It will make a qualitative difference in the way we program.”
If the right way to write a program is unpleasant, then people are less likely to do it according to Goetz. They are more tolerant of doing it the wrong way. He gave an example of how lambda expressions address this with the collections API involving a new abstraction to the JDK called stream and showed how to represent a simple query through applying a filter and mapping transformation, followed by an aggregation, in a way that is fused into one path without creating any intermediate weapons.
Reinhold summarized the key points: “So lambda brings 3 weapons to Java – syntax, performance and abstraction.”
“Plus parallelism,” Goetz added. He explained that Java 7 has the fork/join framework for parallel decomposition that is powerful, flexible, and highly efficient – but not the easiest thing to use. Goetz showed how lambdas enable better parallelism without needing to write fork join code: by asking the collection for a parallel stream it uses fork/join under the hood.
Lambda also helps with normal sequential code by making code clearer, less noisy, and easier to read. “When you have code that is hard to read, that’s where bugs come from. You are trying to maintain some code, you look at the code and think you know what it does, but don’t actually know what it does, and boom! – you’ve introduced a bug.”
All in all, the message was clear: Lambda expressions make Java code easier to read and easier to write.
Working with Lambda and the Collections Framework
For lambdas to be successful, they must work with the Java Collections Framework, which is now 15 years old. So an evolution of the interface was in order. Goetz’s team had to grow an interface over time without breaking implementations of the interface. They added a concept that allows developers to compatibly add a method to an interface, as long as a default implementation is provided.
Reinhold remarked that he has now written a couple of thousand lines of code with lambda features and really enjoyed it. “I can be more productive, and the end result still feels like Java,” he said.
To get started learning lambda expressions, Java developers can go to the OpenJDK Project Lambda page and download the developer preview builds there.
Reinhold reminded attendees that there is a great deal more in Java SE 8 besides lambda expressions. Developer preview builds can be downloaded at JDK8.java.net. “Now is a great time to download JDK 8 and take it for a spin. Every planned feature is in there. It’s reasonably stable and it passes almost all of the tests. If you have any feedback, please send it in!” said Reinhold.
In the rest of the technical keynote, Oracle’s John Ceccarelli, head of engineering for Oracle’s NetBeans team and Oracle’s JavaFX architect Jasper Potts, arrived on stage to demonstrate a Duke pad running real Java via a chess program that was connected to a server. The iPad operated through an HTML5 client talking to a Java EE 7 back end with an EE server in charge of messaging, communication, game state, and so on, with clients hook into it – all built with NetBeans. Jasper Potts further showed off the chess demo with an HTML5 client using a front end to a chess server that was managing the chess games. Then a robot, powered by Java ME 8, took over the game.
Oracle Software Engineer, Santiago Pericas Geertsen, who built the chess server, also described how it was built with 5 distinct functional modules.
In sum, attendees witnessed a server running Java EE 7 hooked up with a variety of clients, some written in HTML5, one written in JavaFX on a Duke pad, one using JavaFX 3D on a powerful laptop, plus a Java ME 8-powered robot contributing to the ongoing chess game. In the process, the powers of the Raspberry Pi were demonstrated.
Developers were encouraged to jump in the water, go for a swim, and have fun with NetBeans and Java embedded.
Java SE 9 and Beyond
Wrapping it up, Reinhold peered a bit into the future and suggested some possible directions for Java, some of which are already in development:
One is Java on GPUs, graphic processing units. As GPUs are being used more and more widely to process big data he suggested that it would be good to make Java work directly with the GPU rather than having to call out to some primitive interface. An OpenJDK called Sumatra has people working on this.
Reinhold spoke of the need for reification. Java’s generics, added in 2004, are based on the notion of erasure for good technical reasons as a sound way to create a type system that supports migration compatibility. But this creates programming problems in which the erasure approach severely limits what can be expressed. Reinhold suggested that introducing some reification and eliminating the “annoying dichotomy between primitive and reference types” would be of value.
He mentioned JNI 2.0 and said, “It just shouldn’t be so hard to integrate Java with native code after all these years.”
He called for memory efficient data structures: “As we get into big data – all this boxing and pointer chasing makes it hard to do big data well. We could have less boxing and pointer chasing and load a lot more data into memory.”
Finally, he talked about the notion of a truly modular platform. “The compact profile in Java 8 is a start but it is not flexible enough. We need to continue to unify the Java SE and Java ME platforms.”
OpenJDK Project Lambda
Watch Keynote and Session Highlights on Demand
Tuesday Sep 17, 2013
By Janice J. Heiss on Sep 17, 2013
In the interview, Vos summarizes his sessions:
“In ‘Building Social Software on Top of Java EE 7 with DaliCore,’ I’ll show how you can integrate social software functionality into Java EE 7 applications. Many enterprise applications can benefit from some kinds of integration with e.g., Facebook, LinkedIn, Twitter, etc., without jeopardizing the user’s privacy and without giving up ownership of the data. The DaliCore framework adds the concept of User and OnlineAccount to the Java EE world, and provides the coupling with existing social networks. This saves lots of project-specific boilerplate code. This approach works both in web-applications as well as in desktop applications.
In ‘DataFX: The Best Way to Get Real-World Data into Your JavaFX Application,’ Hendrik Ebbers and I will present DataFX 2, a framework that helps JavaFX developers to populate JavaFX controls with real-world data. Now that JavaFX is beyond the stage of demos and POCs, it becomes important that the fake data used in demos be replaced with real data, often coming from back-end servers and databases. Apart from the regular cases where a JDBC source or a RESTful web service is queried, we will also show how changes in the local data can be propagated to the backend again...”
In discussing his efforts to combine Java EE and JavaFX, Vos remarks: “I am convinced that these two technologies are complementary, and while they are completely decoupled, the combination of them can lead to great end-to-end projects. As a POC, and in order to get more realistic use cases that could benefit both DaliCore and DataFX, I started to write a JavaFX application that offers community functionality. The front-end of that application is written in JavaFX, and the back-end is using DaliCore on top of Java EE 7. In this application, lots of data is sent from and to the back-end.”
In addition, Vos discusses his experiences with Java EE 7 and Java SE 8, the revolution that lambda expressions bring to Java, the client aspect of Java, how JavaFX fits into Java SE 8, and much more.
Check out the interview here.
Wednesday Jun 26, 2013
By Janice J. Heiss on Jun 26, 2013
A new interview with Java Champion Cay Horstmann, now up on otn/java, titled "Diving into Scala: A Conversation with Java Champion Cay Horstmann," explores Horstmann's ideas about Scala as reflected in his much lauded new book, Scala for the Impatient. None other than Martin Odersky, the inventor of Scala, called it "a joy to read" and the "best introduction to Scala". Odersky was so enthused by the book that he asked Horstmann if the first section could be made available as a free download on the Typesafe Website, something Horstmann graciously assented to.
Horstmann acknowledges that some aspects of Scala are very complex, but he encourages developers to simply stay away from those parts of the language. He points to several ways Java developers can benefit from Scala:
"For example," he says, " you can write classes with less boilerplate, file and XML handling is more concise, and you can replace tedious loops over collections with more elegant constructs. Typically, programmers at this level report that they write about half the number of lines of code in Scala that they would in Java, and that's nothing to sneeze at. Another entry point can be if you want to use a Scala-based framework such as Akka or Play; you can use these with Java, but the Scala API is more enjoyable. "
Horstmann observes that developers can do fine with Scala without grasping the theory behind it. He argues that most of us learn best through examples and not through trying to comprehend abstract theories. He also believes that Scala is the most attractive choice for developers who want to move beyond Java and C++. When asked about other choices, he comments:
"Clojure is pretty nice, but I found its Lisp syntax a bit off-putting, and it seems very focused on software transactional memory, which isn't all that useful to me. And it's not statically typed. I wanted to like Groovy, but it really bothers me that the semantics seems under-defined and in flux. And it's not statically typed. Yes, there is Groovy++, but that's in even sketchier shape.
There are a couple of contenders such as Kotlin and Ceylon, but so far they aren't real.
So, if you want to do work with a statically typed language on the JVM that exists today, Scala is simply the pragmatic choice. It's a good thing that it's such a nice choice."
Learn more about Scala by going to the interview here.
Tuesday Apr 24, 2012
By Janice J. Heiss on Apr 24, 2012
He concludes the series with these remarks:
“In this series of articles, we developed a Java EE version of Spring’s Pet Clinic application. We saw how the advanced tooling provided by NetBeans enables us to quickly develop a Java EE application…. Once we were done building the Java EE version of the application, we compared it with the Spring version, noting that the original version has several dependencies whereas the Java EE version has none, because it takes advantage of all the services provided by the Java EE application server.
Finally, we compared how to implement similar functionality such as MVC and DAO implementation, transaction management, and dependency injection with Spring and Java EE. In every case with Spring, some XML configuration needs to be done besides adding annotations to the code. Java EE relies on convention, and in most cases, no XML configuration is needed in order to implement these services.
Although newer versions of Spring rely a lot less on explicit XML configuration than earlier versions, there are always a few little lines here and there that we need to add to an XML configuration file in order to get most of the Spring annotations to work, violating the DRY (don’t repeat yourself) principle...
Additionally, Spring applications tend to have several dependencies, because they are meant to run in a “lightweight” Servlet container such as Tomcat or Jetty and these containers don’t provide all the required functionality. In contrast, Java EE applications are meant to be deployed in a full-blown Java EE 6 application server such as Oracle GlassFish Server...
For these reasons, I always recommend Java EE over Spring for enterprise application development.”
Have a look at the article here.
Friday Mar 30, 2012
By Janice J. Heiss on Mar 30, 2012
In a new article up on otn/java, Java EE expert David Heffelfinger continues his series exploring the relative strengths and weaknesses of Java EE and Spring. Here, he demonstrates how easy it is to develop the data layer of an application using Java EE, JPA, and the NetBeans IDE instead of the Spring Framework.
In the first two parts of the series, he generated a complete Java EE application by using JavaServer Faces (JSF) 2.0, Enterprise JavaBeans (EJB) 3.1, and Java Persistence API (JPA) 2.0 from Spring’s Pet Clinic MySQL schema, thus showing how easy it is to develop an application whose functionality equaled that of the Spring sample application.
In his new article, Heffelfinger tweaks the application to make it more user friendly.
From the article:
“The generated application displays primary keys on some of the pages, and these keys are surrogate primary keys—meaning that they have no business value and are used strictly as a unique identifier—so there is no reason why they should be visible to the user. In addition, we will modify some of the generated labels to make them more user-friendly.”
He concludes the article with a summary:
“The Java EE version of the application is not a straight port of the Spring version. For example, the Java EE version enables us to create, update, and delete veterinarians as well as veterinary specialties, whereas the Spring version of the application enables us only to view veterinarians and specialties. Additionally, the Spring version has a single page for managing/viewing owners, pets, and visits, whereas the Java EE version of the application has separate pages for each of these entities.
The other thing we should keep in mind is that we didn’t actually write a lot of the code and markup for the Java EE version of the application, because the bulk of it was generated by the NetBeans wizard.”
Have a look at the complete article here.
Wednesday Mar 07, 2012
By Janice J. Heiss on Mar 07, 2012
From the article itself:
“Akka offers multiple solutions to the concurrency problem. It provides a toolkit for addressing concurrency, scalability, and high-availability concerns. It provides one thing to learn and one thing to use. Akka has multiple tools that will help you as a developer. Actors, futures, agents, and software transactional memory all raise the abstraction level and make it easer to write, understand, and maintain concurrent, scalable, fault-tolerant code. Instead of messing around with very low-level constructs, you think in terms of higher-level concepts such as message flows and transactions. What is usually solved by use of low-level plumbing in standard enterprise applications becomes workflow in Akka. So you start to think about how the data flows in the systems rather than how to get the concurrency and scalability exactly right.”
Read the complete article here.
Friday Dec 16, 2011
By Janice J. Heiss on Dec 16, 2011
Part 1 began with a Java EE rewrite of Spring's Pet Clinic sample application and developed the persistence layer of the application using Java Persistence API (JPA) 2.0, using NetBeans to generate most of the persistence layer from an existing database schema. Heffelfinger analyzed the generated code, which employed advanced JPA features.
In part 2, he continues this process by developing Enterprise JavaBeans (EJB) 3.1 session beans that act as Data Access Objects (DAOs), as well as JavaServer Faces (JSF) 2.0 managed beans and pages. Readers get to see the generated code in action and are given a look under the hood to see what’s going on.
Heffelfinger concludes Part 2 with a look ahead to Part 3:
“In the next installment of this series, we will modify the generated code to make it a bit more user friendly and we will compare the Java EE and Spring versions of the Pet Clinic application.”
Read the complete article here.
Wednesday Nov 02, 2011
By Janice J. Heiss on Nov 02, 2011
Heffelfinger observes that, “Every time I work on a Spring project, I start mumbling under my breath. I know I will have to go through long and convoluted XML files to determine what is going on with the project. I also know that my project will have approximately 10,000 dependencies and that the generated WAR file is going to be a monster.”
He contrasts this with Java EE, where most of the needed services are required by the application server, reducing the number of required dependencies, and typically Java EE provides configuration by exception, meaning there is little configuration necessary. When configuration is needed, it is usually done through annotations, which allows the developers to get the whole picture from the source code. Also, with Java EE, the advanced tooling from NetBeans is available.
Again, from the article itself:
“In this series of articles, we will rewrite the sample Pet Clinic application provided with Spring using Java EE. In this first article, I illustrate how we can quickly develop an application that has equivalent functionality to the Spring version by taking advantage of the excellent Java EE tooling provided by NetBeans. The Java EE version employs JavaServer Faces (JSF) for the user interface, Data Access Objects (DAOs) are implemented using Enterprise JavaBeans (EJB) 3.1 session beans, and data access is provided by Java Persistence API (JPA) 2.0.”
Read the article in full here.