Tuesday Aug 14, 2012

Enterprise JavaFX Deployment with LightView: Part 3 now on otn/java

A new article by Java Champion Adam Bien, now up on otn/java, titled “Enterprise JavaFX Deployment with LightView: Part 3,” explores ways to use Maven 3 to build and deploy the LightView application in all available deployment modes. In addition, Bien shows how to sign and deploy LightView with a Java EE 6 application.

Bien explains the basics:

“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”

He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.

Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”

Check out the article here.

Wednesday Sep 07, 2011

Unit Testing for Java EE tech article on OTN

A new article, titled “Unit Testing for Java EE,” by Java Champion Adam Bien, is up on otn/java’s front page. Bien points out that too many developers believe that testing Java EE applications is too hard, inconvenient, or complex, something that has not been true since the advent of Java EE 5 more than five years ago.

Bien explains: “There is nothing special about unit testing Java EE 6 applications. You only have to add the JUnit library into your pom.xml file (see Listing 5) and put your classes into the src/test/java directory. All JUnit tests will be executed automatically during the standard Maven lifecycle: mvn clean install.”

He goes on to make use of “Mockito” an easy-to-use, open source mocking library. Bien writes:

“Mockito is able to create ‘smart proxies’ (a.k.a. mocks) from classes or interfaces. These proxies do not come with any behavior, but they are still perfectly usable. You can invoke methods, but will get the default values, or null, back. The behavior of the mocks can be recorded after their creation with when(mock.getAnswer()).then(42) syntax.

Mockito is perfectly suitable for ‘simulating’ any inconvenient classes, resources, or services. You can start with Mockito just by knowing a single class org.mockito.Mockito. The when-then ‘domain specific language’ is composed of static methods from the Mockito class. The org.mockito.Mockito class is well documented. In fact, the whole documentation set was generated from the JavaDoc markup in the org.mockito.Mockito class.”

Read the complete article here.

About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today