WebSocket

Back in December 2012 when googling about websocket, the results were Atmosphere, jWebSocket, websockets4j, socket.io, and Weberknecht. But in December 2013, the result is JSR 356. Yes, there is finally a standardization about websocket. Apache Tomcat 7.0.47 has also implemented it and we will use it in this blog post.

To start, we can create usual dynamic web project in eclipse. Don't forget to specify Tomcat as the server target runtime. I created a super simple chat application. The chat room can have many users. You can try it by opening as many tabs as you like, each tab represents a new user session. All messages are saved so that users that joined after the conversation has started don't miss anything. In this example, each time a message is sent it will be broadcasted to all users joining the chat. Below is the source code hosted on box:


Below is the result when running the code with three users involved:

Java 3D

My Story on Java Memory Leak

Weeks ago I got an email saying that someone investigated our application (well, the application is neither initially designed nor implemented by me to be precise). Apparently he was hired by our client to find problems and give advice on how to increase application's performances. One of his findings that was sent to me to analyse was a memory leak report. I didn't have an idea on how Java can create memory leak. I understand that we have to destroy an object and release its memory, only if we, our self, allocate memory as in C. Turned out, there are many ways to create memory leak in Java through inappropriate use of design and code. These are the reports that were sent to me.

Having little knowledge of this application's design now I need to find the root cause of this? Great. The report shows that the top three memory consumers are Hibernate SessionFactoryImpl so it must be something to do with Hibernate. My first step was I need to be able to reproduce the report, see if it happens on my local machine (hoping that it only happens on production machine so I can blame the production environment :p). The report was generated using Eclipse Memory Analyser Tool (MAT), so I run it and boom the MAT produced completely same report. Interestingly, the memory leak happens even after the application was deployed on Weblogic App Server.

First, I thought the session was not properly closed. But looking at the code, it uses getCurrentSession() method provided by Hibernate and then by reading at Hibernate document I knew that it is maintained by Hibernate, developers are not allowed to close it manually.

So then how about Hibernate configuration? I changed the configuration a bit here and there.

<prop key="hibernate.connection.release_mode">after_statement</prop>
The connection must be released immediately after a statement is run.

<prop key="hibernate.cache.use_query_cache">false</prop>
I disabled the query cache.

<prop key="hibernate.transaction.flush_before_completion">true</prop>
Each transaction is flushed immediately.

<prop key="hibernate.transaction.auto_close_session">true</prop>
Each session is closed automatically.

But none of them cure the problem. Until then I realized that the SessionFactoryImpl was loaded because Hibernate check named query at startup. So I set this startup_check to false.

<prop key="hibernate.query.startup_check">false</prop>

Then the report shows the actual culprit. The root cause is our ApplicationContextLoader.

The configuration is loaded statically when the class is loaded by using static block. Moreover, it is set to a static variable which means it stays forever until the ApplicationContextLoader class is unloaded from memory.

Java Web Start

Creating simple Java Web Start application is quite simple. There are three things we need to do.

1. Create the main class and wrap it in a JAR file. For simplicity sake, the main class extends JFrame that contains a JButton inside a JPanel as shown below:

2. Create a JNLP (Java Network Launch Protocol) file that links to the JAR file.

This file is an xml file and the structure is quite self explanatory. The main things here are the codebase attribute in <jnlp> element and the <jar> tag inside <resources> element. The codebase describes base path for all href in the file, in this case it is the base path to find jnlp.jnlp and jnlp.jar since I put those two files in the same folder. The jnlp.jar contains a main class which is stated in main="true" and main-class="edu.mat.jnlp.Main".

3. Create a HTML file that contains a link to the JNLP file.

Opening the HTML in a browser displays the following screen

Clicking the launch button launches the application as shown below:

Simple Drools Example

Implementing an expert system using Drools is quiet easy. First of all create ordinary java project in Eclipse. The following image shows the project structure in Eclipse:

There are two source folders, first one is src/main/java to save java classes and second one is src/main/rules to save Drools rule files. Don't forget to include all required libraries in Drools distribution archive to this project. Two important files that need attention are Main.java and validation.drl. Let's see each of them.

The Main.java contains one method main(). In the main method we load the validation.drl file, create a Customer object, and then fire the validation rule. We also add a Map object that is used to save error messages during validation process. Next we will see the validation.drl.

The .drl file has its own format structure. First we state package name, this is used for grouping only. No same Drools file name exists in the same package. Then we import all classes just like we do in java file. Next we create a series of rules.

In the validation.drl above we have two rules, addressMandatory to validate address, and emailMandatory to validate email. In the when clause we get objects that are inserted through session in KnowledgeBase before; the HashMap object which we put inside a variable named errors for later use and also Customer object that we put inside a variable named cust. While addressMandatory rule checks whether the customer's address is null or not, emailMandatory rule checks whether the customer's email is either null or empty.

If the address or email is null we put an error message to the errors variable so that we can write it to console in the main() method. We can safely write any Java code inside the then clause as we do in ordinary java file.

When we run the main() method, the following output is displayed on console:

Java Compiler API

Java Compiler API has been around for a while since Java 6. We can use it to compile java files at runtime. Let's now have fun with it:

Inside main method above we have two java files to compile. Next we obtain the JavaCompiler object from ToolProvider. The JavaCompiler object then does its job to compile those files using verbose parameter supplied. Verbose parameter is useful to display compilation log. When we run the code, two .class files are created at the same location of the original files. Here is the output on console:

Let's now see another approach to compile java files.

First we state the files to compile. Then we obtain the JavaCompiler object from ToolProvider as we did before. After that we create an object of type DiagnosticCollector. This object is used to collect information during compilation process. Next, we get a StandardJavaFileManager by passing the DiagnosticCollector to the JavaCompiler's method getStandardFileManager. From the StandardJavaFileManager we create an Iterable object that contains the files being compiled. Then the actual compilation process is done by CompilationTask object by calling call() method. If an error occurs during compilation, we print the error information that has been collected by our DiagnosticCollector.

Instead of using DiagnosticCollector, we can use DiagnosticListener to collect error information. To do that we have to implement DiagnosticListener interface as shown below:

Then we can use it to compile java files as shown below:

We should be familiar with the code above since in fact we have seen it before. The only difference is that we replace the DiagnosticCollector with our own MyDiagnosticListener. Both DiagnosticCollector and MyDiagnosticListener implements DiagnosticListener interface.

So far we have seen how to compile java files reside on disk. Next we'll see how to compile java file from a string.

 

Again, the code above looks familiar but instead of getting the java content from files we get the java content from a string. The string itself is wrapped inside an object of type JavaObjectFromString which extends SimpleJavaFileObject which implements JavaFileObject as expected by our Iterable object.

To load the compiled class, we can use URLClassLoader by supplying it with a path where the compiled classes are put. Those classes are most likely compiled in the working directory.