Oracle has announced the release of JavaFX 2.0 Beta SDK release. In this post, I will have a look at JavaFX, its background, current situation, and the problems it is facing.


Brief History of JavaFX

Rich Internet Application (RIA) is an important trend for web/windows applications, and development of such applications needs well-equipped frameworks. Adobe with Flash platfrom (targetted for Flash/AIR client runtimes), and Microsoft with Silverlight and Windows Presentation Framework (WPF) have been much faster and successful in developing RIA technologies and acquising market. Traditionally, Sun Microsystems with Java, has been behind the Adobe and Microsoft in providing RIA frameworks. To deal with this problem, Sun introduced JavaFX as RIA technology. Let's see a brief history of JavaFX from official site of JavaFX:


 At the JavaOne 2007 conference, Sun Microsystems introduced the JavaFX
 platform to help content developers and application developers to create
 content-rich applications for mobile devices, desktops, televisions, and
 other consumer devices. The initial offering consisted of the JavaFX
 Mobile platform and the JavaFX Script language. Multiple public releases
 were delivered after the initial announcement; the 1.3 version was
 released on April 22, 2010.
 After Oracle's acquisition of Sun Microsystems, Oracle announced during
 the JavaOne 2010 conference that support for the JavaFX Script language
 would be discontinued. However, it was also announced that the JavaFX
 Script APIs will be ported to Java and would be released as part of the
 JavaFX 2.0 product. This announcement meant that the JavaFX capabilities
 will become available to all Java developers, without the need for them to
 learn a new scripting language. With this announcement, Oracle has
 committed to making JavaFX the premier environment for rich client


Requirements for Rich Internt Applications (RIAs)

I believe that in order to have a successful and proper RIA technology,one should follow at least four following rules:

  • RULE (1): Separation of UI contents and UI behavior. It is basic idea of MVC (Model-View-Controller). By following this rule, the UI designers can concentrate on contents, and application developers concentrate on coding, and they can smoothly co-work together.
  • RULE (2): Unique/Consistent UI contents modeling.  UIs are needed for a vast variety of applications: mobile device appliations, web applications, desktop applications, and so on. From viewpoint of programmers, it is not effective to learn different UI modeling languages for each application type.
  • RULE (3): Seperation of UI contents modeling from rendering engine. From viewpoint of RIA technology, it will use same UI modeling language for all application types (windows application, mobile device application, and so on), and it only needs to provide different rendering engines according to target device or application type. Therefore, rendering engines should be implementing in a different layer, which is completey separated from UI contents modeling languages layer.
  • RULE (4): Modeling UI contents in declarative markup language. According to RULE (1), both designers and developers need to understand and modify UI contents. They use different tools and approaches; so, modeling the UI contents in an extensible and interchangable format is important. Accordign to RULEs (2) and (3), regradless of target device or application type, UI contents should be modeled in a unique/consistent manner, which makes it necessary to have interchangable format for UI contents modeling. Considering the available technologies, I think the proper answer for format is declarative markup language, or XML.



Comparing RIA Technologies

Considering the above requirements, I have done a comparision on the approaches have been used by three major RIA technology providers. Results are summarized in the following table.


RIA TechnologyFrameworkGUI Contents ModellingGUI Behavior Implementation
Flash platform by AdobeAdobe Flex

MXML files

(extension: .mxml)

(is XML file)

ActionScript files

(extension: .as)

.NET platform by Microsoft

XAML UI Modelling for .NET (used by: Windows Presentation Framework (WPF),Silverlight, Windows Phone and so on)

XAML files

(extension: .xaml)

(is XML file)

Code behind files

(extension: .cs or .vb)

JavaFX by Oracle (Sun Microsystems)

JavaFX 1.3

JavaFX script files

(extension: .fx)

(is script file)

JavaFX script files or

Java files

(extension: .fx or .java)

JavaFX 2.0

(from JavaFX 2.0, JavaFX script language is discontinued)

Java files

(extension: .java)

Java files

(extension: .java)



Let's see a simple sample code for modeling of UI contents for each of above RIA technologies. Assume that UI is a dialog showing one label, one input box, and one button.


Code for Adobe Flex 4.5 is:

 <?xml version="1.0" encoding="utf-8"?>
 <mx:WindowedApplication xmlns:mx="" 
     <mx:Label x="52" y="38" text="Your Name:"/>
     <mx:TextInput x="154" y="36" width="219" id="name"/>
     <mx:Button x="124" y="85" label="Submit" id="submit"/> 


Code for .NET 3.5 is:

 <Window x:Class="WpfApplication1.Window1"
    Title="Window1" Height="298" Width="522">
           <Label Margin="52,38,0,0" Name="label1" Height="28"
                VerticalAlignment="Top" HorizontalAlignment="Left" 
                Width="120">Your Name:</Label>
           <TextBox Height="23" Margin="154,36,0,0" Name="name"
                VerticalAlignment="Top" HorizontalAlignment="Left"
                Width="219" />
           <Button Height="23" HorizontalAlignment="Left" Margin="124,85,0,0"
                Name="submit" VerticalAlignment="Top" 


Code for JavaFX 1.3 is:

 import javafx.stage.Stage;
 import javafx.scene.Scene;
 import javafx.scene.control.*;
 Stage {
     title: "Sample Dialog"
     scene: Scene {
          width: 522
          height: 298 
               Label {text: "Your Name:" layoutX: 52 layoutY:38 }
               TextBox {layoutX: 154 layoutY: 36 columns: 10}
               Button { text:"Submit" width: 75  height: 23 layoutX: 124
                     layoutY:85 }


Code for JavaFX 2.0 is: 

 import javafx.stage.Stage;
 import javafx.scene.Scene;
 import javafx.scene.control.*;
 public class Main extends Application {

   public void start(Stage stage) {
       Group root = new Group();
       Scene scene = new Scene(root, 522, 298, Color.BLACK);
       Label label1 = new Label ("Your Name");
       Button button1 = new Button("Submit");
       TextBox textBox1 = new TextBox ();

       stage.setTitle("JavaFX Scene Graph Demo");

   public static void main(String[] args) {


For the Flex or .NET, you can see that all the above RULEs are valid.


With reagrds to RULEs 1 and 4, both  Flex and .NET have modeled UI contents as an extension of XML language, and XML model file for UI contents is completely separated from UI behavior file (which is ActionScript or C#.NET or VB.NET languages). In .NET, UI designers can use Microsoft Expression Blend to create XAML files, and programmers can use Microsoft Visual Studio .NET to add behavior for those XAML files. Different tools, but, all deal with same data types/files for UI contents.


With regards to RULEs 2 and 3, Microsoft has done an amazing job by using XAML technology as a consistent format for different application types, like: windows application, silverlight application, windows phone, xbox, and so on. XAML is not a sub-project of WPF or Sliverlight or other technologies. But, it is a much wider project that is used by those technologies. As they have mentioned in this site: "XAML is the language behind the visual presentation of an application that you develop in Microsoft Expression Blend, just as HTML is the language behind the visual presentation of a Web page."



But, how about JavaFX?

I think both JavaFX 1.3 and 2.0 fail to satisfy almost all above four rules. I have summarized evaluation results in the following table:


No.RULEJavaFX 1.3 evaluationJavaFX 2.0 evaluation
1Separation of UI contents and UI behaviorthe .fx files contain both UI contents and UI behavior. Basically, .fx files are scripting files, which should not include UI contents. It is a really big mistake to mix those scripts with UI contents.exactly same problems as JavaFX 1.3 exist. The only difference is that JavaFX 2.0 uses Java API code, instead of script files.
2Unique/consistent UI contents modelingfor each category of applications, Java has different APIs: Swing, JavaFX API, applets, JavaFX scripts, and so on. No consistent solution exists.
3Separation of UI contents modeling from rendering engine
4Modeling UI contents in declarative markup languagenot using declarative markup languages, but, script files.not using markup languages, but, java code files.


I beleive stopping support for scripts of JavaFX 1.3 was a good decision, but, unfortunately, JavaFX 2.0, instead of solving problem, is just making it worse. Using JavaFX APIs for JavaFX 2.0 is not the solution. Some people even say that JavaFX 2.0 has become like a Swing++ library, nothing more...


I know that in JavaFX 2.0, Oracle is adding support for FXML file format for modeling UI contents. The idea of FXML files come from BXML files of Apache Pivot. As very first steps, it may be good action, but, it is not really enough.


What should be done?

I believe JavaFX (actually, Java language) needs to re-design its policies for having a consistens and declarative markup language for modeling of visual presentation for different application types of Java (swing, applets, mobile phones, RIAs, and even web applications). This modeling language should not be a sub-project of current Java presentation frameworks, but, it should be on top of them, and guide those presentation frameworks.


I guess that starting a new JCP for JavaFX specification should be a good start point. The power of Java comes from JCP process, so, why not use this process for JavaFX?


OK. JavaOne 2011 will be hold on October 2-6. Let's wait and see the official presentations of Oracle to understand their plans for extending JavaFX. Hope it is going to correct the current wrong direction of JavaFX, and make a move to right path. Otherwise, Orcale (and we, as Java developers) will be behind Adobe and Microsoft in RIA technologies, same as before.


P.S.: There is a framework, called "Metawidget", that you can find details about it in this link. The idea behind this framework seems interesting, and near to rules I have explained above. There is a presentation about this framework in JavaOne 2011 in this link, as following:


Presentation: "DRY UIs: Let the metadata do the work"

Speakers: Dan Allen, Richard Kennard

In part 1 of this post, I described the possible approaches/frameworks for unit testing of web applications. In this post, I concentrate on one framework, which is JBoss Arquillian. The contents of this post will be:

  • What about JBoss Arquillian?
  • Use Arquillian to Unit Test inside EClipse and JBoss 6
  • Secrets behind Scene: How Arquillian handles the Test?


Since the contents of this post is a little bit long, I will explain the following remained contents in part 3:

  • Using Arquillian for Unit Test from Apache Ants
  • Is Arquillian Really Good? Let's Evaluate it


Before jumping to details, I should mention that I am not a member of Arquillian project or JBoss. This post is only persoanl exprience of me on this framework, as a community member. So, it is not official ...


What about JBoss Arquillian?

As it is mentioned in official site of Arquillian:


 Arquillian enables you to test your business logic in a remote or 
 embedded container. Alternatively, it can deploy an archive to the
 container so the test can interact as a remote client. ...
 Arquillian can either execute a test case inside the container, in 
 which case the test class is deployed by Arquillian along with the
 code under test, or hold back the test class so it can act as a 
 remote client to the deployed code. All the developer has to do is
  write the test logic.


In four words, Arquillan is in-container test framework. For concept of in-container test, please refer to part 1 of this post.


Arquillian is a well-designed and easy-to-use framework, that makes the difficult task of web application unit test/integration test very easy.

You just write test cases using well-known tools of JUnit 4 or TestNG 5, and then add a few metadata to your test code specific to Arquillian, and you are done. Just need to run the test. The following difficult jobs are handled by Arquillian:

  • Build deployable archive files (jar, war, ...) containing your test case classes.
  • Deploy built test archive files to web application container, and after test, undeploy it automatically.
  • After deploy, run the test inside container, and capture test results/failure.
  • If necessary, Arquillian can handle start/stop web application container.


At the time of this post, it is still in 1.0.0.Alpha 5 release, and as a JBoss project, an active community and many team members are extending it to make it ready for final release. Its official site is as following:


Use Arquillian to Unit Test inside EClipse and JBoss 6

OK, introduction is enough. Let's see how to use Arquillian in a typical unit test case. Arquillian has many rich funcationalites and support different scenarios. But, for understanding it, let's concentrate on a simple situation (although it is simple, I guess it will be enough for many test situations). Let's assume our test situation is as following:

  • As a sample, Target code to be tested is a business logic class to manage users of our web application with a simple CRUD interface like following sample code (typically, these kind of information are stored/retrieved to/from database):


 public class UserLogic {  
     public User add( User user ){ ... }
     public User get( Long id ){ ... }
     public Boolean update( User user ){ ... }
     public Boolean delete( Long id ){ ... }



  • Our application's classes/resources (including above business logic class) have been already deployed into web application server, which is JBoss 6, and the server is running (don't worry, if you are using different application server, we will talk about it too in few lines lower).
  • We are using EClipse IDE as development/coding environment, and we can deploy/debug/run the web appliction into above web application server. The meaning of this assumption is that EClipse already knows how to access into application server. (I think other IDE tools should be the same, and EClipse is only a sample. However, I have not tested other IDEs).
  • Your have necessary JUnit 4 or TestNG 5 plugin already installed into your EClipse, and you can use it. In recent versions of EClipse, these plugins have already been installed, and you shouldn't need any additional plugin.


That's all for the assumptions. Let's start preparing unit test items and do the test. The steps are very easy, and as following:


STEP (1): Write Unit Test Classes: For this step, you don't care about Arquillian, and just need knowledge of how to use JUnit 4 or TestNG 5. I assume that you already know how to do it. If not, you can find many good tutorials on web, for example, this link. Let's consider that our unit test case class will be something like following code (for JUnit 4):



 public class UserLogicTest {
        public void testUserAdd(){
             UserLogic logic = ...;
             User user = ...;
             user = logic.add(user);
             User userFromDB = logic.get( user.getId() );
             asertNotNull("User should not be null" , userFromDB);
             assertEquals("User ID confirm" , user.getId() , userFromDB.getId());
             assertEquals("User Name confirm" , user.getName() , userFromDB.getName());
             // ... (other confirmations)


For this step, be careful about one important point. For JUnit, you should use JUnit 4.8.2 or higher. If using TestNG, you should use TestNG 5.14.9 or higher. Please confirm that your classpath library in EClipse for JUnit or TestNG is pointing out proper version, otherwise, when you run the test, you may face exception.


STEP (2): Add Arquillian Libraries to Your EClipse Project: Same as other Java frameworks, to use them, you need to add the necessary libraries to the library classpath of your project in EClipse. Same is for Arquillian, and you need to add Arquillian JAR files. Technically, this step should be the easiest, but, actually, this one is the most difficult step.

If you are using Apache Maven in your project, you can refer to this page of Arquillian's documentation. But, if, same as me, you are not fan of Apache Maven, logically you should be able to find the necessary JAR files in the download page of Arquillian, in this link. However, in this link, you can find it is mentioned:


 Right now, Arquillian releases only consist of individual binary and source JARs 
 published to the JBoss Community Nexus repository (see above). We'll make 
 distributions available for download once Arquillian enters beta.


If you ca't wait for Beta release of Arquillian, then you can refer to following table to download the necessary JAR files. Sorry if I can't summarize all of them in one ZIP file to make this step easy for you.


No.Category of LibraryJAR fileDownload Links
1JBoss Arquillian libraries (1.0.0.Alpha 5)arquillian-api-1.0.0.Alpha5.jarLink
2JBoss ShrinkWrap libraries (1.0.0.Alpha 12)shrinkwrap-api-1.0.0-alpha-12.jarLink

Unit test framework (JUnit or TestNG) libraries

(include libraries for the framework you use)

junit-x.y.jar (should be higher than 4.8.2)Link
testng-x.y.jar (should be higher than 5.14.9)Link

Web application container's client libraries

(For JBoss, refer to right link.

For other web application containers, refe to this link)


Find in /client sub

folder of JBoss



As you can see in category 4 of above table, for different web application servers, the only difference is that you just need to include the related client libraries of target application server. Other steps are exactly same for all types of server.


STEP (3): Add Arquillian Meta-Data to Unit Test Classes: We have already included the Arquillian libraries in classpath, and we are ready to modify the unit test class we prepared in above STEP (1). The modification is very easy, and you can see the final test code in following.


 public class UserLogicTest {
      public static JavaArchive createTestArchive() {
              return ShrinkWrap.create(JavaArchive.class, "test.jar");
     public void testUserAdd(){
          UserLogic logic = ...;
          User user = ...;
          user = logic.add(user);
          User userFromDB = logic.get( user.getId() );
          asertNotNull("User should not be null" , userFromDB);
          assertEquals("User ID confirm" , user.getId() , userFromDB.getId());
          assertEquals("User Name confirm" , user.getName() , userFromDB.getName());
          // ... (other confirmations)



The @RunWith(Arquillian.class) means to use the Arquillian's test runner, instead of default JUnit's test runner.

And, the static @Deployment method, means to deploy the test code to web application server, as a "test.jar" archive file.

That's all for this step. Huh, it is easy, isn't it?


STEP (4): Run Test Classes: Last step is to run your test cases. It is easy, and exactly same as the way you run other test case classes inside EClipse. Nothing special for Arquillian. For JUnit, you can refer to this link.


Enjoy it. Your test should be running and show you the results, hopefully no error.


Secrets behind Scene: How Arquillian handles the Test?

We have seen how to create and run the unit test classes. But, how Arquillian run the test inside container? Run your test case inside the EClipe again, and when the test is running, have a look at: /server/serverName/deploy folder of your JBoss. While unit test is running, you can see a file called "test.war" is created in the deploy folder. And when the unit test is finished, this war file is deleted automatically.


Huh? In the static @Deployment method (mentioned in STEP (3)), the code says that test file should be "test.jar", but, the deploy file is "test.war". Why?


The answer is very easy. If you unzip the "test.war" file, you can see that a "test.jar" file exists inside it, which contains your test case class. But, in addition to "test.jar", some other Arquillian JAR files also exist within "test.war" file. That is logical. Arquillian needs to run the test cases inside the application server, so, the Arquillian libraries also should be deployed into server.


In order to run in-container test, Arquillian do following tasks sequentially for each test case:

  • Bundle the test class and related Arquillian library JAR files into an archive file (according to static @Deployment method)
  • Deploy the test archive into web application server
  • Enhance/enrich the test class (e.g., resolving @Inject, @EJB and @Resource injections) and run the test class within server, and return the test results
  • Undeploy the test archive from web application server


To be exact,  other than "enhance/run/return results of test classes", other tasks are all done by JBoss ShrinkWrap. You have already seen in above STEP (2), that ShrinkWrap JAR libraries are necessary. To be more exact, ShrinkWrap internally uses the SPI (Service Provider Interface) to support deploy/undeploy archive files into/from web application server. You can read about SPI more in details in this link. Anyway, let's thank develppers of the Arquillian framework who have done good job to handle such difficult implementations internally, that we don't need to learn SPI.


OK. This long post is reaching to the end. By reading this post, I think you have found enough knowledge of how to use Arquillian. Arquillian has many advanced functionalities, that you can read in the documentation page. In part 3, I will explain about how to run Arquillian test cases from Apache Ant's xml files.