Thursday Sep 26, 2013

Session Report: DataFX: The Best Way to Get Real-World Data into Your JavaFX Application

Java Champion Johan Vos of Lodgon and GUI expert Hendrik Ebbers of Materna GmbH gave a session on Vos’ labor of love, Project DataFX, a 2-year-old free and open source project intended to make retrieving, massaging, populating, viewing, and editing data in JavaFX UI controls easier. In so doing, they extend the functionality of JavaFX.

The goal of the session was to teach attendees how to develop enterprise applications in JavaFX with real-world services and data. They were focused on showing how the DataFX framework facilitates the process of data retrieval and rendering, and how it allows developers to focus on their application-specific logic.

According to Vos and Ebbers, the real value in most client-oriented business applications is the data sitting on remote servers and cloud systems. Retrieving and displaying this data must be done correctly before end users can interact with it. The open source DataFX framework aims to simplify this by enabling JavaFX developers to easily retrieve data from a variety of sources in several formats and rapidly integrate it with JavaFX components (such as TableView), using typical JavaFX patterns. The session introduced the DataFX project, gave practical advice for using it, and provided insight into future applications.

The session explored a variety of tools used in DataFX: the Concurrency API, DataFX Executor, lambda expressions, DataReader, RestReader, DataProvider, Controller API, Flow API, and many more.

The DataFX Project
Java Champion Johan Vos
Hendrik Ebbers
Be sure and go to to view the session in early October.

Friday Jul 19, 2013

Java API for JSON Processing: An Introduction to JSON

A new article, now up on otn/java, by Oracle’s Jitandra Kotamraju, titled “Java API for JSON Processing: An Introduction to JSON,” takes a look at how Java API for JSON Processing provides portable APIs to parse, generate, transform and query JSON, also known as JavaScript Object Notation. Kotamraju, a principal member of the technical staff at Oracle, is the JSON Processing specification lead.

JSO, a lightweight, text-based, language-independent data exchange format that is easy to read and write by both humans and machines, can represent two structured types: objects and arrays. Kotamraju, the JSON Processing specification lead, explains that “an object is an unordered collection of zero or more name/value pairs. An array is an ordered sequence of zero or more values. The values can be strings, numbers, booleans, null and these two structured types.”

JSON is frequently used in Ajax applications, configurations, databases, and RESTful web services. JSON is offered as the data exchange format with their RESTful web services by all popular websites.

Kotamraju gets under the hood with both the object model and streaming APIs. He concludes that the API for JSON Processing offers the following capabilities:
* “Parsing input streams into immutable objects or event streams
* Writing event streams or immutable objects to output streams
* Programmatically navigating immutable objects
* Programmatically building immutable objects with builders”

The API forms a base for building data binding, transformation, querying, or other manipulation APIs. JAX-RS 2.0 provides native integration for the Java API for JSON Processing.

Check out the article here.

Wednesday Jun 26, 2013

Diving into Scala with Cay Horstmann

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.

Friday May 31, 2013

Security and Java!

In a detailed blog, Nandini Ramani, Vice President of Software Development, summarizes Oracle steps to address security issues on the Java platform. Amongst the most recent changes,  she explains that "it is now possible to run signed applets without allowing them to run outside the sandbox, and users can prevent the execution of any applets if they are not signed". She lists the impacts of those changes and mentioned for example that "Oracle urges organizations whose sites currently contain unsigned Java Applets to sign those Applets according to the documented recommendations."  

She also explains that "Oracle has found that the public coverage of the recently published vulnerabilities impacting Java in the browser has caused concern to organizations committed to Java applications running on servers.  As a result, Oracle is taking steps to address the security implications of the wide Java distribution model, by further dissociating client/browser use of Java (e.g., affecting home users) and server use (e.g., affecting enterprise deployments). With Java 7 update 21, Oracle has introduced a new type of Java distribution: “Server JRE.”"

She added that "starting in October 2013, Java security fixes will be released under the Oracle Critical Patch Update schedule along with all other Oracle products.  In other words, Java will now issue four annual security releases."

Check out her original blog 

Wednesday May 22, 2013

What's New in JMS 2.0: Ease of Use

A new article by Oracle’s Nigel Deakin, up on otn/java, titled “What's New in JMS 2.0, Part One: Ease of Use,” demonstrates ways in which JMS 2.0 enables developers to send and receive messages while writing less code. Some features of JMS 2.0, part of Java EE 7, and can be deployed in Java EE Web or EJB applications, while others can only be used standalone in a Java SE environment.

Deakin writes:

“The single biggest change in JMS 2.0 is the introduction of a new API for sending and receiving messages that reduces the amount of code a developer must write. For applications that run in a Java EE application server, the new API also supports resource injection. This allows the application server to take care of the creation and management of JMS objects, simplifying the application even further…”

The new API, known as the “simplified” API, is simpler and easier to use than the existing JMS 1.1 API, now known as the “classic” API.

Deakin describes the new API as follows:

“The simplified API consists of three new interfaces: JMSContext, JMSProducer, and JMSConsumer:

* JMSContext replaces the separate Connection and  Session objects in the classic API with a single object.

* JMSProducer is a lightweight replacement for the MessageProducer object in the classic API. It allows message delivery options, headers, and properties to be configured using method chaining (sometimes known as a builder pattern).

* JMSConsumer replaces the MessageConsumer object in the classic API and is used in a similar way.”

Developers can now choose between the two APIs and have access to both the classic and new features. Stay tuned for Part Two, in which Deakin will explore new messaging features in JMS 2.0.

Check out Part One here.

Monday Apr 29, 2013

JSR 356, Java API for WebSocket

A new article, now up on otn/java, by Java Champion Johan Vos, titled “JSR 356, Java API for WebSocket,” shows developers how to integrate WebSockets into their applications. JSR 356, part of the Java EE 7 platform, specifies the API that Java developers can use when they want to integrate WebSockets into their applications on both on the Java server and client side. The API is highly flexible, and frees developers to write WebSocket-based applications independent of the underlying WebSocket implementation, thus preventing vendor lock in. It also allows for more choice in libraries and application servers. Web clients or native clients leveraging any WebSocket implementation can more easily communicate with a Java back end.

As part of the Java EE 7 standard, all Java EE 7-compliant application servers will have an implementation of the WebSocket protocol that adheres to JSR 356. Vos explains:

“Once they are established, WebSocket client and server peers are symmetrical. The difference between a client API and a server API is, therefore, minimal. JSR 356 defines a Java client API as well, which is a subset of the full API required in Java EE 7….

The Java API for WebSocket is very powerful, because it allows any Java object to be sent or received as a WebSocket message.

Basically, there are three different types of messages:

* Text-based messages
* Binary messages
* Pong messages, which are about the WebSocket connection itself

When using the interface-driven model, each session can register at most one MessageHandler for each of these three different types of messages.

When using the annotation-driven model, for each different type of message, one @onMessage annotated method is allowed. The allowed parameters for specifying the message content in the annotated methods are dependent on the type of the message.”

Check out the article here and learn how to integrate WebSockets into your applications.

Wednesday Mar 27, 2013

Real-Time Topic Modeling of Microblogs

A new article published on the front page of otn/java, by Yogesh Tewari and Rajesh Kawad, of Infosys Limited Labs in Bangalore, India, titled “Real-Time Topic Modeling of Microblogs,” explores “the challenge of real-time extraction of topics from a continuous stream of incoming microblogs or tweets that are particular to an application” that they created. From a simple tweet text, the application is designed to accurately suggest relevant topics discussed in the tweet, and provide real-time timelines of topics generated from the tweet streams.

They explain that this is no simple tasks since a tweet, “considered as a text corpus, contains only 140 characters and second, given their brevity, tweets may not provide useful information and may contain different forms of text such as ‘smileys’ and short-form URLs. Finally, tweets are generated in real time.”

Yogesh and Rajesh apply LDA (latent Dirichlet allocation) to topic model tweets and make use of the Machine Learning for Language Toolkit (MALLET) API as the implementation for LDA – all performed in a Java environment. The LDA implementation is in turn encapsulated within the MALLET API, which here functions as a command line–based Java tool.

As they state: “Our targets are the actual Java classes that perform the LDA logic whose methods we invoke with required input in real-time. Storm is our choice of a free and open source distributed real time computation engine implemented in Java and running in a distributed mode. Storm is highly scalable and easily capable of handling incoming tweet streams. We use Twitter4J to stream tweets, which require valid Twitter authentication. So our task is to design a topology that will consume tweet streams and output a timeline of topics.”
Check out the article here.

Wednesday Feb 13, 2013

JavaFX Open Source Update!

Oracle has started to open source JavaFX, the rich client platform for Java applications. The list of open sourced projects will be growing in the next couple of weeks with an additional 7 projects. "We are also going to open source our iOS and Android implementations over the next couple of months" announced Richard Bair, architect of the JavaFX platform, in his blog.

Wednesday Jun 13, 2012

The Enterprise Side of JavaFX - Part One

A new article, now up on otn/java, by Java Champion Adam Bien, titled “The Enterprise Side of JavaFX,” shows developers how to use LightView to convert REST services into a bindable set of properties. The article, Part One of a three-part series, presents the enterprise and business side of JavaFX with minimal animations, effects, and transitions, and a focus on structuring the presentation logic and integration with back-end services.

Bien makes use of LightFish, LightView and much more:

“LightFish is an open source monitoring application that periodically fetches and persists snapshots from a “GlassFish Under Test” machine and makes them available in real time via a simplified REST API.

LightFish comes with a basic Web interface to manage the data-capturing interval that is implemented with JavaServer Faces 2. LightView is a JavaFX 2 real-time visualizer that integrates the Web UI directly and accesses the monitoring data via REST and long polling. It could be considered to be a ‘stress test dashboard.’”

Look for Part Two of the series, which will directly integrate the JavaServer Faces 2 UI with WebView.

Check out the article here.

Friday Mar 30, 2012

Spring to Java EE, Part Three - new tech article on otn/java

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.


Insider News from the Java Team at Oracle!

javeone logo


« April 2014