I never forget Steve Jobs' 2005 Stanford Commencement Address. It was a fantastic speech by a great man. Everyone may fail sometimes in some parts of life. However, Steve explains that a failure can be a start for a new success. And it is very amazing!

Last year, Oracle didn't make the presentations of JavaOne 2010 available to public for free immediately. Fortunately, this year, you can download the pdf files of JavaOne 2011 presentations (Oct. 2-6) from their site one day after the conference. Refer to the following link:

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

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.

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.

RULE

JavaFX 1.3 evaluation

JavaFX 2.0 evaluation

1

Separation of UI contents and UI behavior

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

2

Unique/consistent UI contents modeling

for each category of applications, Java has different APIs: Swing, JavaFX API, applets, JavaFX scripts, and so on. No consistent solution exists.

3

Separation of UI contents modeling from rendering engine

4

Modeling UI contents in declarative markup language

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

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:

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:

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):

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):

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.

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.

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:

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.

This is my first post on this blog. I am planning to write things about different aspects of software design/architecture, that I face during my work expriences. Should be fun! Hope you also enjoy the posts.

OK. first post goes for Web application's unit test/integration test. I separate it to two parts. In first part, I want to explain some basic concepts, and in second part, I will explain about "Arquillian", which is the newest framework by JBoss for web application's test.

Suppose we have a web application, and we want to create some unit test/integration test items for it. If your application is windows application, you just need to create some JUnit or TestNG test cases/suites (for Java language), and then you are done. But, if you are dealing with web applications, I think you will agree that it is not as easy as it seems to create/test such test cases. Your test cases need to run inside the web application container, in order to be able to access to your application's database, message queue, application context, and other business logic classes that their life-cycle is managed by container.

I think the problem is clear, but, what is the solution? Basically, there are two approaches for dealing with this problem.

Mock Object Test Approach: "Mock" means a program that simulates the web application container. Mock programs hide the difficulty of dealing with actual web application containers, and make the test easier. But, on the other side, they have the problem that your test is not running in the acual container, and you are not sure the result of test will be exactly same when you run it in actual environment. Also, if you have complicated setting files or use some speical libraries, you may face some compile/setup/run errors. If you want to use this approach, for Java programming language, you can use JMock, EasyMock, Mockito, Mockrunner, and many others. You can use some other mock test tools in this link and link2.

In-Container Test Approach: As it is obvious from the name, test cases are deployed and run inside the container. The idea is straightforward, but, the difficulty is how to deploy/run the test cases inside web application. For this approach, you can use frameworks, like: Apache Cactus, JUnitEE, and JBoss Arquillian.

According to the requirements of your project, you need to select a framework. For me, since I wanted to run my tests in actual container, I decided to use In-Container test approach. I think it should be a logical selection for many of you too.

As you can see in official Apache Cactus's homepage, this project has been retired from Apache projects on 2011/8/5, and there will not be any extension/development in this project. Honestly, I didn't select the JUnitEE, since this project's homepage is not updated for long time. Even their EJB's sample test is not updated for EJB 3.0 and it is EJB 2.0. And, finally, I selected JBoss Arquillian for In-Container test of web application. I selected it not because there is no other option, but actually because it is well-designed and easy-to-use, and it simplifies all the difficult tasks of archeiving/deploy/test/undeploy of test cases into container (Arquillain interally uses JBoss ShrinkWarp for archeiving/deploy/undeploy into container).

In part 2, I will explain about JBoss Arquillian and how to use it to unit test the web applications.