2010-03-11

Compiling Java applications to native Windows executables

Being a Java developer really sucks when it comes to making end-user desktop applications. You want these applications to be light, fast and easily redistributable. Packaging a bunch of jars along with startup script is the worst thing you can do. It may work quite well in various Linux distributions, where you can make a .deb or .rpm which automatically installs JRE, puts startup script to /usr/local/bin and creates a nice launcher with icon in the applications menu. In Mac OS you can use that outdated JRE that comes by default and then easily bundle all scripts and jars into an .app. But in Windows it does not work that way. You can use JSmooth to make .exe out of .jar and use NSIS to create a nice installer, but there still is a problem. User may not have a compatible JRE, or he/she may choose not to have one just because Java sucks for running on it's bloated memory hogging virtual machine. I have to agree here. As a user, I have no faith in desktop applications that are written in Java.

So what is the solution? Compile to native executable and forget JRE. It is possible, but it will not be a walk in the park. First, you will have to get familiar with GNU Compiler Collection and particularly with GCJ.

Let's compile a Hello World application like this one:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello native world!");
    }
}
  1. Get the patched GCJ here: http://www.thisiscool.com/gcc_mingw.htm (120 MB)
  2. Extract it somewhere and add thisiscool-gcc/gcc-ejc/bin to your PATH
  3. Compile Hello.java as Hello.exe: gcj --main=Hello -o Hello Hello.java
  4. Enjoy your statically linked Hello.exe which prints Hello native world! and runs without JRE.
Wait. Hello.exe is 37MB? Holy crap! Well, it's a little overhead you have to pay for loosing the JRE, this .exe contains the whole garbage collection mechanism, etc. Also, you will be able to compile SWT GUI applications! It is possible to get smaller executables with MinGW tooling. Hello.java compiled with MinGW is about 3MB, but it has other issues, I couldn't manage to get the system output working. You may be more lucky though.

Anyway, when you compile native binaries, your Java code cannot be decompiled, so you have better protection than by using obfuscators. And the best thing is that end users won't complain that "it's crap because it's Java". They just wouldn't know.

I wish Sun (I just can't say Oracle when referring to Java, it makes me sick, sorry) could create an official AOT Java compiler so developers would not have to go through hellfire to make native executables.

2009-11-15

Making Windows a better place to be

Many developers including me are forced to use Windows at work due to various corporate reasons even when our work has nothing to do with Microsoft technologies. And we are all stuck with that terrible Command Prompt or a Power Shell which are crap compared to a proper terminal. However, there is a way to have a fully functional Unix terminal in Windows thanks to Cygwin and a patched version of Putty

I am doing this for several years and this is one of the first things I do in any Windows machine that I want to do some software development on, so it's time to come up with a little tutorial.

Setting up Cygwin and PuttyCyg

Getting Cygwin

Go to http://www.cygwin.com to download and run the setup.exe. Installation process is illustrated in screenshots below.
 


I suggest you installing cygwin directly to C:\cygwin as it's recommended. It's a significant part of your system and it is really worth the place in C:\ directly.



Cygwin offers "C:\Windows\System32" as a place for local packages, however I don't like that idea and keep it all under "C:\cygwin".


Some mirrors were failing for me with missing packages so I choose a respectable source and deal with slower download speed in exchange for reliability.



Choosing packages may take a while. You can go with default selection, however going through the long list is worth a while if you want to have goodies like vim, curl, ping, openssh, mc and so on.


Now go make yourself some coffee.


Don't add any icons or shortcuts because they open cygwin in that ugly command prompt we are about to get rid of.


Introducing Cygwin to your Windows

Now that you have the Cygwin, try it out by launching C:\cygwin\cygwin.bat. You will see something like this.


As you can see, a few files can be modified to configure your environment. Keep them in mind for future:
  • ~/.bashrc
  • ~/.bash_profile
  • ~/.inputrc

Now append these to the beginning of your Windows PATH environmental variable:

C:\cygwin\usr\local\bin;C:\cygwin\usr\bin;C:\cygwin\bin;



Run a fresh Command Prompt (if you are using Launchy or a similar program to run the cmd.exe, you have to restart it before the new PATH applies to programs you run.) and you will be able to do the following:


That's just a small benefit you get from cygwin, but it's handy to have unix commands anywhere in the system. If you think that cmd.exe is enough to enjoy unix commands, you are wrong. It fails to resize properly, it's hard to copy and paste. Compare using Putty with a remote machine to using Command Prompt on your local Windows box, It's like day and night.

Getting PuttyCyg

Get the latest puttycyg from http://code.google.com/p/puttycyg/. For the past year it's this one: http://puttycyg.googlecode.com/files/puttycyg-20090811.zip. You can put it in c:\cygwin\puttycyg to avoid a mixup with the original Putty if you use it.

Configuring PuttyCyg to access local cygwin

Create a shortcut to putty.exe from the puttycyg pack that you just extracted.


Run it to configure the local connection. Check "Cygterm" in Connection type and enter a minus (-) in Command.


Be sure to go to Window configuration and set Lines of scrollback to something more reasonable than the default 200.


Save the settings. Name the session "localhost".


Now click "Open" to test the configuration. You should see a working terminal.


You can now enhance the shortcut you created earlier to load the "localhost" session automatically. Just append "-load localhost" to the end of Target.


You're all set. A few resources to get you familiar with Cygwin:

2009-09-29

XML processing in Java

One of the things that most Java developers tackle on daily basis is dealing with XML. Despite the fact that XML is taking lots of criticism and new formats like YAML are emerging and becoming more popular, you cannot avoid XML it's too widespread and used everywhere. It's the main format for interchanging data across systems and even people. There is a great deal of fat books that show how to use various XML APIs and libraries to handle the beast with all it's standards and extensions. There are many solid tools that had been continuously developed for years by large communities (Xalan, Xerces, JDOM, DOM4J).

And still XML processing in Java is still a major pain in the ass.
I see two reasons for that: 
  1. XML is too bloated as a format. See the picture below (click to enlarge):
  2. Java libraries that deal with XML are bloated. It's natural because they simply try to implement the specifications

Let's say you have a Java application which receives some data in form of simple XML:

<?xml version="1.0" encoding="UTF-8"?>
<data>
  <entry id="1">entry number one</entry>
<entry id="2">entry number two</entry>
</data>
Your application has this class:

public class Entry {
private int id;
private String content;
//the usual setters and getters here
}
If you would want to parse this XML with Java, into Entry objects you would usually do something like this:

try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File("data.xml"));
NodeList nl = doc.getElementsByTagName("entry");
for (int i = 0; i < nl.getLength(); i++) {
Entry entry = new Entry();
entry.setId(Integer.parseInt(nl.item(i).getAttributes()
.getNamedItem("id").getNodeValue()));
entry.setContent(nl.item(i).getTextContent());
System.out.println(entry);
//do real stuff
}
}
catch (final Exception e) {
System.out.println("Failed parsing: " + e);
//do real handling
}
Expected output:

Entry:{id: 1; content: entry number one}
Entry:{id: 2; content: entry number two}
In Java 6 DocumentBuilderFactory.newInstance() will usually return an instance of this implementation: com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl 
This is Xerces embedded into the JRE. What's wrong with that? First, it's a huge library with big memory footprint. It will be outdated in comparison with what you can get at the official homepage, so if you want to go for the latest version with all the bug fixes, you will have to add another megabyte of jars to your project, set a system property (javax.xml.parsers.DocumentBuilderFactory) to change the default implementation and hope your code works. Then you have to know DOM. You have to use an ugly for loop to iterate the results instead of doing it right (for (Node n : doc.getElementsByTagName("entry") { ... }).
Even though Java aims to be loosely coupled, you can use the API and switch implementations, you should keep in mind that API changes over time, and implementations work differently. I have seen legacy code where you can find sick things like DocumentBuilderFactoryImpl = (DocumentBuilderFactoryImpl) DocumentBuilderFactory.newInstance();, I have seen Axis failing to parse complex SOAP messages after switching to different, newer JDK, I have seen third party software vendors who start cursing when you change your web service implementation and your WSDL is generated with minor cosmetic differences (i.e.: xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" instead of previous version: xmlns:s="http://schemas.xmlsoap.org/wsdl/soap/"). In all these cases APIs and implementations failed to do what they were meant for. Of course, everything can be fixed, but it takes time and nerves, and these things are precious.
XML processing in Java is terrible, and the worst part is when you have to go through all this just to parse a simple piece of data. Why couldn't it be as simple as that:

for (XmlSlicer piece : XmlSlicer.cut(data).getTags("entry")) {
//each piece is: <entry id="...">...</entry>
Entry entry = new Entry();
entry.setId(Integer.parseInt(piece.getTagAttribute("entry", "id")));
entry.setContent(piece.get("entry").toString());
System.out.println(entry);   
//do real stuff
}
After being fed up with Java's great XML APIs and libraries I made a small tool for simple daily work with XML files.
The code above would work in XML Zen - a small and lightweight XML processing library that supports ~1% of what other XML processing libraries can do, however this 1% of functionality is what you use 90% of the time. There are no big APIs, just simple logic driven object oriented processing of XML strings. And it's just a little over 10Kb.
You can add XML Zen dependency with Maven, just set the dev.java.net repo first:

<repositories>
<repository>
  <id>maven2-repository.dev.java.net</id>
  <name>Java.net Repository for Maven</name>
  <url>http://download.java.net/maven/2</url>
  </repository>
  <!-- other repositories -->
</repositories>
Then the dependency:

<dependency>
    <groupId>com.googlecode.xmlzen<groupId>
    <artifactId>xmlzen</artifactId>
    <version>0.1.1</version>
</dependency>
That's it, you are ready to go. And when it comes to building XML and XML Zen is not enough for your needs, check out this great project: http://java.ociweb.com/mark/programming/WAX.html.

2009-06-17

A tool for unpacking multiple archives and other ramblings

I've always wondered why torrents are packed into multiple archives, sometimes even archives inside other archives. Anyway, I've got fed up with all the unpacking routines, especially after downloading several seasons of something that has each episode in an individual folder containing 20 rar or zip files. So, after one evening of coding this nightmare is now over.

Here is the screenshot of the stupidly named tool (click to visit project page):


It was also a good reason to try out new version of NetBeans. I still hate GUI builders, however for small "write and forget" kind of projects like Multi Unpacker it's a fairly good choice. However NetBeans is still slow and unresponsive in comparison with Eclipse.

So far Multi Unpacker is for Windows only, however it's a spare evening away from becoming cross-platform (and you are welcome to join the project). Too bad my MacBook broke down completely, so Macs will most probably not get any special treatment... This is also bad news for Hawkscope, unless someone is willing to donate me an old Mac? :)

2009-06-07

Cheatsheet: Unicode characters for buttons and GUI elements

Before drawing your own graphics for various GUI buttons, you could try finding a Unicode character that represents the thing you want to do. For instance, up/down arrows can be made with 25B2 (▲) and 25BC (▼).

Here are some pictures with Unicode characters that you can use to build GUIs. First a quick guide to using these:



Now, the cheatsheets:











These were captured from a tool named Korais.

You can download these images in a single PDF file: unicode.gui.cheatsheet.pdf