Java native code compiler with swing?
- Thread starter jmhduck
- Start date
Assuming you mean free? Nope 
. (At least none that I've found, I think GCJ is the farthest along, their site hadn't been updated in a bit last time I looked but their mailing lists were still active so it's still in dev afaik.)
. (At least none that I've found, I think GCJ is the farthest along, their site hadn't been updated in a bit last time I looked but their mailing lists were still active so it's still in dev afaik.)Maybe you want to keep it a secret, but why are you trying to compile Java to native code?
If it is because you want to run your Java app "without the JVM" or because you want an exe that will just launch rather than a somewhat flaky executable jar in a desktop environment then have you looked at Launch4J? It can certainly wrap up a jar in an exe to make it seem like a native executable, you can also (optionally) bundle a whole JRE with it assuming you know the target platform. Of course your distributable is gonna be very large in size though.
If it is to protect your code from decompilation then have you looked at an obfuscater? There is a large list of them on the site "mindprod" (http://mindprod.com/jgloss/obfuscator.html), they also have a section on native compilers. Obviously not something that will stop the most determined of people who want to see the source though. I think the common solution to this problem is generally "if someone rips you off and you can prove it then just sue them", but obviously that is a big effort.
Perhaps you can compile a small library that does the hard work (if its some kind of number crunching app with a specific algorithm) into native and use JNI to access it, but people could still reverse engineer the assembler and they'll prolly be able to make calls by decompiling the Java.
As far as protecting your code goes, I'm not entire sure that Java was cut out for the commercial desktop application arena, it seems it is meant for more secured environments in business etc. I'd absolutely love to be proved wrong on this and see ways of securing code as I've looked for something like this in the past. I think in the end it boils down to "stop being paranoid because if someone is determined enough it will happen".
Edit: BTW, the whole decompilation of desktop apps sold directly to an end user isn't a dig specifically at Java, its just the price paid for the flexibility of languages that compile to byte code.
Edit 2: If you are using any kind of bytecode manipulation already (such as JPA/Hibernate/Toplink for database integration) an obfuscator will prolly throw a spanner in the works.
If it is because you want to run your Java app "without the JVM" or because you want an exe that will just launch rather than a somewhat flaky executable jar in a desktop environment then have you looked at Launch4J? It can certainly wrap up a jar in an exe to make it seem like a native executable, you can also (optionally) bundle a whole JRE with it assuming you know the target platform. Of course your distributable is gonna be very large in size though.
If it is to protect your code from decompilation then have you looked at an obfuscater? There is a large list of them on the site "mindprod" (http://mindprod.com/jgloss/obfuscator.html), they also have a section on native compilers. Obviously not something that will stop the most determined of people who want to see the source though. I think the common solution to this problem is generally "if someone rips you off and you can prove it then just sue them", but obviously that is a big effort.
Perhaps you can compile a small library that does the hard work (if its some kind of number crunching app with a specific algorithm) into native and use JNI to access it, but people could still reverse engineer the assembler and they'll prolly be able to make calls by decompiling the Java.
As far as protecting your code goes, I'm not entire sure that Java was cut out for the commercial desktop application arena, it seems it is meant for more secured environments in business etc. I'd absolutely love to be proved wrong on this and see ways of securing code as I've looked for something like this in the past. I think in the end it boils down to "stop being paranoid because if someone is determined enough it will happen".
Edit: BTW, the whole decompilation of desktop apps sold directly to an end user isn't a dig specifically at Java, its just the price paid for the flexibility of languages that compile to byte code.
Edit 2: If you are using any kind of bytecode manipulation already (such as JPA/Hibernate/Toplink for database integration) an obfuscator will prolly throw a spanner in the works.
Last edited:
You are correct in assuming I want to compile to native code to protect code from decompilation. Apparently obfuscation isn't secure enough for the application obviously I can't go into details of exactly why.
I am wondering why the app was written in Java if this needed to be done (not my choice). Well it was probably done so as to rip stuff out of another app, the app has definately been written quick and dirty
.
It's not a number crunching thing so the small app idea wouldn't be secure enough. Do you think it would be possible to copy required Java code into the project ie just rip off any java api that is required (and not included with the Java Native Compiler). I'm not sure if all Java package source are available though.
I have found a Java native code compiler that is relatively inexpensive but it doesn't have good enough API/Swing/AWT support. It's here.
^^Hopefully the above makes some sense, and thanks for the reply dude. Do you work in software dev by any chance?
I am wondering why the app was written in Java if this needed to be done (not my choice). Well it was probably done so as to rip stuff out of another app, the app has definately been written quick and dirty
.It's not a number crunching thing so the small app idea wouldn't be secure enough. Do you think it would be possible to copy required Java code into the project ie just rip off any java api that is required (and not included with the Java Native Compiler). I'm not sure if all Java package source are available though.
I have found a Java native code compiler that is relatively inexpensive but it doesn't have good enough API/Swing/AWT support. It's here.
^^Hopefully the above makes some sense, and thanks for the reply dude. Do you work in software dev by any chance?
I believe that most (all?) of the JDK is now open source within the last year or so, there are other initiatives that are doing a complete re-write of the Java API such as GNU classpath (which I think merged with GCJ because they were writing an API clone and their compiler).
The problem isn't so much "find a java compiler and stick the old java code through it" unfortunately. As far as I'm aware (limited knowledge here really
) from when I've needed to dig down deep into swing classes a lot of it eventually does something through JNI or something OS specific which is abstracted away. I think its basically those parts that put the spanner in the works because as far as writing a compiler to compile Java syntax is concerned, that seems to be as "trivial" as writing any other compiler, its just you also need that compiler to implement all features of the JRE too (such as garbage collection).There may well be a way of doing this, I'm not exactly overly knowledgeable here, I've actually just graduated uni, but its something I've looked into in the past and have been asked about in the past for various projects, so there may be light at the end of the tunnel in that someone else has the solution but I'm reasonably sure that there is no quick and easy (or even time consuming and difficult) way of doing it and certainly JET seems to be the most advanced project to manage it
. Like I say, I think it's just Java's target market which seems to be Open Source, Education or Enterprise / Controlled Environments.Edit: Also from reading the "Java Native Compiler" docs, they seem to have basically used GCJ but pulled in the java 1.4 source for AWT/Swing already. GCJ don't have it on their classpath because it's not under a license compatible with the GNU. You may actually get some mileage out of it if your project compiles on Java 1.4?
Last edited:
Hey Dude, sorry for the slow reply. It won't compile to 1.4 and would be a lot of work to get it to do so. This morning I just told my boss that I didn't think using the JNC would really work. I've been given some GUI redesign stuff to do for now so it's all cool for now. Although I think he mentioned that they might just get the JET software :O