How to create a native Java App

Recently, I stumbled upon JCGO, an interesting project, which translates Java 1.4 code into C.
In this article, I show how to create a native Windows app out of a small Java app.

The Java app I will use is NetCat (https://github.com/rafalrusin/netcat). You can download precompiled executable, netcat.exe, from https://github.com/rafalrusin/netcat/downloads.

So the first step is to download all dependencies. I will use MinGW, MinGW GCC, jcgo-lib-1_14.tar.gz, jcgo-src-1_14.tar.bz2, classpath-0.93 (http://ftp.gnu.org/gnu/classpath/classpath-0.93.tar.gz) and Java sources for the app with dependent libraries: https://github.com/rafalrusin/netcat, commons cli 1.2 (http://commons.apache.org/cli/download_cli.cgi). You need to put all this in the same directory, so it’ll have structure like this:

auxbin
classpath-0.93
commons-cli-1.2-src
dlls
goclsp
src
jcgo
jcgo.exe
jcgo.jar
libs
miscsrc
netcat
out
rflg_out
stdpaths.in

Then, you need to run Java to C translator by using command:

jcgo.exe -sourcepath netcat/src -sourcepath commons-cli-1.2-src/src/java netcat.NetCat @stdpaths.in -d out

Initializing...

Analysis pass...

Output pass...

Writing class tables...
Creating main file...
Parsed: 293 java files (2699 KiB). Analyzed: 3067 methods.
Produced: 640 c/h files (3769 KiB).
Contains: 1490 java methods, 4119 normal and 288 indirect calls.
Done conversion in 1 seconds. Total heap size: 36572 KiB.
 
Next step is to compile it into final executable. Following command does this:
 
gcc -DJCGO_INET -DJCGO_NOFP -DJCGO_WIN32 -DJCGO_THREADS -I src/include/ -I src/include/boehmgc/ -I src/native/ out/Main.c -o netcat.exe libs/x86/mingw/libgcmt.a -lws2_32
 
I used some switches, which are suitable for this particular app. For example, by default JCGO doesn’t use multithreading or networking. This has to be enabled explicitly. 
 
And that’s it. Now you can try out the app by calling google.com, like this:
 
$ netcat.exe google.com -p 80
Connecting to google.com port 80
GET
HTTP/1.0 302 Found
Location: http://www.google.pl/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=2f3085ac38771e98:FF=0:TM=1345885031:LM=1345885031:S=8A-IkreMgCogMsey; expires=Mon, 25-Aug-2014 08:57:11 GMT; path=/; domain=.google.com
Set-Cookie: NID=63=O_QZ4bDrzYNiiE0DY8RT-34c_pGt_OZagP3gzrzqCAx_Xo2kO7s9zVrUOx7FVz4TyAEY7Wx9UhglYZSX9UHSdzT7c9mUKzfkJFp5lk5FyfiMIcKITLhgSX4__3QwEYBS; expires=Sun
, 24-Feb-2013 08:57:11 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Sat, 25 Aug 2012 08:57:11 GMT
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN


<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.pl/">here</A>.
</BODY></HTML>

I like the approach of translating Java code into C, because compared to other tools, which generate C++ code, this is more suitable for embedded devices. For example it is possible to generate code for iOS, because Objective C is a superset of C.

One feature I would like to see though is to be able to use reference counting instead of full gc. This is because one of the advantages of C over Java is that it doesn’t have GC hangs. So then the programmer would have to make sure there’s no cycles in orphaned object structure.

Update: Ivan Maidansky, an author of JCGO, has put some interesting comments regarding this article. In particular, he is aware of some apps in Apple Store, which do this kind of translation. Also, reference counting is discouraged due to multithreading issues. These comments can be found here: https://github.com/ivmai/JCGO/issues/2

You May Also Like

Agile Skills Project at my company

Unfulfilled programmers Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working i... Unfulfilled programmers Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working i...

Private fields and methods are not private in groovy

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

  1. Person has private constructor that cannot be accessed
  2. Field "name" is private and cannot be accessed
  3. Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person() // constructor is private - compilation error in Java
println(person.toString())

person.@name = 'Mike' // access name field directly - compilation error in Java
println(person.toString())

person.name = 'John' // there is a setter generated by groovy
println(person.toString())

person.@surname = 'Foo' // access surname field directly
println(person.toString())

person.surname = 'Bar' // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!