Wednesday Sep 24, 2014

Sang Shin is the founder and chief instructor at JPassion.com, a popular online learning site offering hands-on courses on Java, Java EE, the Spring framework, Java development tools, Java performance, JavaScript, jQuery, HTML5, Groovy and Grails, MySQL, Android, web services, Ruby on Rails, and Hadoop. Before founding JPassion.com, Shin was a lead technology architect and evangelist at Sun Microsystems. He frequently gives talks on various technologies to worldwide developer audiences.

Q: Tell us about the topic you will present at Java University during JavaOne.

Monday Sep 23, 2013

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 EverHe
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.

“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 FrameworkFor
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.

Playing ChessIn 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 BeyondWrapping
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.”

Tuesday Sep 17, 2013

A new interview is now up on otn/java. In it, Johan Vos, a highly regarded Java Champion whose focus is on combining the strengths of back-end systems and embedded devices, provides his insightful take on what’s happening in the world of Java technology. His favorite technologies are currently Java EE/Glassfish at the backend and JavaFX at the front-end. He is a co-author of Pro JavaFX 2, and will be offering two sessions at JavaOne 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.

Wednesday 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."

Tuesday Apr 24, 2012

In a new article, now up on otn/java, titled “Spring to Java EE Migration, Part 4,” David Heffelfinger presents the final part of his series in which he demonstrates the ease of migration from the Spring Framework to Java EE. Here he compares equivalent functionality in Java EE and Spring in areas such as MVC design pattern implementation, data access, transaction management, and dependency injection.

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.”

Friday 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.”

Wednesday Mar 07, 2012

In a new interview on otn/java, titled “Java Champion Jonas Bonér Explains the Akka Framework,” Jonas Bonér explores the intricacies of Akka, an open source platform for next-generation event-driven, scalable, fault-tolerant architectures on the JVM. He argues that the way concurrency is typically performed in Java with shared-state consistency is needlessly difficult, resulting in concurrent access to shared mutable state guarded by locks, which are notoriously hard to understand and get right. Locks, from Bonér’s perspective, do not compose, scale poorly, have complicated error recovery and are, generally, too low level.

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.”

Friday Dec 16, 2011

In part two of a four-part article series on otn/java, “Spring to Java EE Migration, Part 2,” CTO and Java EE expert David Heffelfinger elaborates further on 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.

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.”

Wednesday Nov 02, 2011

In a new article up on otn/java, the first of a series, titled “Spring to Java EE Migration, Part 1,” CTO and Java EE expert David Heffelfinger 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.

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.”