Skip to main content

Javac compiler option to build Windows native exe

51 replies [Last post]
alexanderschunk
Offline
Joined: 2005-03-24
Points: 0

Hi,

this is just a speculative thread, so hit me if i am totally wrong ;)

First off all i want to say that i love to work with java because of its simplicity and wide set of programming tools. However, there is one shortcoming in java that frustrated me over the years: the miss or lack of native code compilation that is, compiling java.exe files like its possible with C/C++.

I know this is a very contradictous matter and there are people claiming that native code compilation is not build-in in java to preserve its platform independence.

I may object that - and practice has prooven that - in most cases people are offering java binaries for different platforms however they may offer only one ignoring the end-users actual platform.

For example the Eclipse and NetBeans IDEs offer binaries for Windows, Linux, Mac etc.

I know there are native code compilers shipped with Java but it would be a nice feature to be able to build native code right away.

For example, if you are using java on a windows platform it should be possible to have a compiler switch that would automatically generate Windows exe files instead of java byte code if the developer so whiches.

That would minimize the job for developers to look for other solutions - i.g. writing a batch script, building a jar manifesto etc. - to just passing a compiler option.

Since Windows is the only platform that supports "exe" files - Linux and Mac have other extensions as far as i know - this would be a windows-platform only feature.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jdavi
Offline
Joined: 2003-06-11
Points: 0

> About Speed I think all has been said, you give a
> linked list example [b]i am talking about GUI
> speed[/b], I don't see the relevance of compiling the
> code. A native compiled GUI will always be faster
> then a JAVA JITed app GET IT!!!
>
> That is the whole point behind SWT.
>

No, the whole point of SWT is to avoid "one level of indirection ;-). It access to native widgets (very optimized for that specific platform) instead of recreate them using low level tools like SWING does. On the other hand, a SWT program is still a java program.

For prove that AOT is better than JIT you have to compile the SAME programs using both other way you are testing SWING ws SWT or whatever GUI toolkit or programing languaje you are using.

Cheers
JD

vhi
Offline
Joined: 2004-10-11
Points: 0

>> About Speed I think all has been said, you give a linked list example i am talking about GUI speed, I don't see the relevance of compiling the code. A native compiled GUI will always be faster then a JAVA JITed app GET IT!!!

Why do you think that native compilation helps GUI more than it helps a Linked List? Do you have any example for this assertion?

The reason I think you see a 'perceivably' slow Java GUI is because of Swing and it has nothing to do with JIT. In case of .NET+C#, the GUI performance is same as it would have been if you had done native exe.

Of course Java, .NET etc will have slower startup times, but then it is the cost of having a VM and that will not go away by using AOT compilation.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Are you trying to be blind or just an idiot

I'm still not falling for your ad hominem flame baiting. It doesn't advance these forums, your cause, or how people perceive you.

> yes people have reversed applications

I know. I have never claimed otherwise.

On Aug 8, 2005 2:31 PM a poster said that a reason to compile to .exe is the fear of someone making minor modifications to an application before reselling it illegally. I am asking if that is a common problem in Java programs and thus a valid reason for wanting to compile to .exe. And whether that compilation method will prevent said decompile-modify-resell scenarios (of which, looking at game "warez" I am not immediately convinced.)

You seem to be trying to answer a different question from what I asked.

> you give a linked list example i am talking about
> GUI speed, I don't see the relevance of compiling
> the code.

The relevance is to the statement: "[i]a native C++ compiler will always be faster than a JIT compiled Java app.[/i]" Which, in my opinion, is false. And the linked list example shows one case where a JIT (or dynamic compiler) can do something that is impossible or difficult for a static compiler: virtual method inlining based on the runtime behaviour of a program.

Do you still think the statement "[i]a native C++ compiler will always be faster than a JIT compiled Java app[/i]" is true? Here is a great opportunity to show the world that you understand the reason why the JITted code is faster and that you are big enough to say "oops, you are right, a JIT can indeed compile to faster code than a static compiler, thanks for proving it, I learned something new today."

> A native compiled GUI will always be faster
> then a JAVA JITed app GET IT!!!

Nope, I do not believe such a law of nature exists. Here is a quickie JIT (well, sort of):
[code]
#!/bin/sh
C++ -o TEMP$$ $0
.\TEMP$$
rm TEMP$$
[/code]
I.e. compile the given program, then immediately execute it. The program is compiled just prior to execution. A real JIT wouldn't usually write the output to a file and (depending on programming language) read bytecode instead of source code. The point is: this "JIT" executes [u]exactly[/u] the speed at a "compiled GUI" because the GUI [u]is[/u] compiled.

After that simple "JIT" we can start making the compiler smarter: auto-detect the CPU architecture, do dynamic recompilation on things like run-time subclassing and jump branch prediction. Which makes the program faster than what static compilation can make it.

GUI code is not somehow magically different from other code. It consists of program statements that get compiled into machine instructions. There are data structures, method calls, callbacks, control flow statements, etc - just like in other programs.

If Hotspot were to write the machine code it generates into a file that could be executed later, it would need some of its optimization removed. Making statically compiled code slower than dynamically compiled.

The program I posted on Aug 9, 2005 1:55 AM displays one such optimization that cannot be done (or is difficult/impractical to do). Hotspot compiles "virtual" function calls into inline code based on heuristics and statistics: it notices a given call site always calls a method with a specific subclass. Therefore it assumes that site [i]always[/i] calls the method that class and compiles accordingly. If the assumption later proves wrong, Hotspot deoptimizes and recompiles the code. That doesn't happen with a static compiler.

> You are now Overcooked !!!

Try to keep to a civilized discussion, sir.

dog
Offline
Joined: 2003-08-22
Points: 0

> > Another example.. someone likes your app, but
> wants
> > to make some minor modifications before he resells
> > it (illegally).
>
> Does this keep happening to you in reality?

This does not happen to me because I do not release code in this way.

I have seen people decompile Java without even thinking about it (some editors will do it automatically). I have seen people cheat in academically.

I have seen people hire someone else to muck around with your app because he doesn't want to pay you what he agreed to. I have seen all kinds of piracy of all sorts..

I live in Latin America, and unfortunately, there's not much the legal system can do to protect me in these cases unless I have a loooot of money and time.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Another example.. someone likes your app, but wants
> to make some minor modifications before he resells
> it (illegally).

Does this keep happening to you in reality?

danielmd
Offline
Joined: 2003-06-13
Points: 0

I think that htayod (Denis) has made a very clear and structured post.

Still I hate the SUN licensing scheme of see but don't touch, they should allow for projects like GCJ to use their libraries or provide something like partial library distribution something like IBM does with SWT, for SWING.

I hate SWT by the way it is an aberration, one of those forks that in time will be hated by all GUI developers. It works well for one kind of application, it is just so problem domain specific in its design that will never be a good general GUI library, unless they redesign it, and then it will look exactly like SWING.

"[i]And there's nothing to stop you from using a 3rd party tool to get that native compiled false sense of security and performance.
Don't assume Sun is responsible for making everything there can ever be that's related to Java.[/i]" - [b]jwenting[/b]

I think this is clear, a native compiled application is safer than a java obfuscated application; unless someone uses a cleaver protection scheme like making a statement false breaks the whole protection scheme.
Just try to reverse engineer one of each kind.

Sun is responsible for the libraries it produces and the licenses it uses, they should allow partial distribution of the libraries, or open source the hole thing, as of now they are responsible for the lack of SWING capability of GCJ.

Bu they way GCJ produces binary executables for a multitude of platforms not just windows.

JET produces for Windows and Linux, and I ear somewhere that if there is demand they will produce for MAC OS.

- To [b]sjasja[/b]
> > Another example.. someone likes your app, but
> wants
> > to make some minor modifications before he resells
> > it (illegally).
>
> Does this keep happening to you in reality?

Yes it has happened, i have been on both sides of the barricades has a reverse engineer i have had to create binary file filter, work around legacy code, etc... and i also have had to protect code from being reversed, i also know at least a full hand of people whose job is to reverse code and then create a compatible version without breaking patents.

On performance, hey if you like java performance hurray for you, if you think it is the fastest language, and all that fan boy stuff go ahead, there are others like you, you should at least be a little bit pragmatic, and i am sorry if this is sounding patronizing. But i am done with you.

sjasja
Offline
Joined: 2004-08-15
Points: 0

>>> Another example.. someone likes your app, but wants
>>> to make some minor modifications before he resells
>>> it (illegally).
>>
>> Does this keep happening to you in reality?
>
> [...] i have been on both sides of the barricades
> has a reverse engineer [...]

I would like to repeat the question: has someone decompiled a Java application of yours, made minor modifications, and resold it illegally? Have you done that to someone's code?

> On performance, hey if you like java performance
> hurray for you, if you think it is the fastest
> language, and all that fan boy stuff go ahead,

Straw man. I have never ever in my life said Java is the fastest language. There is no such thing as a "fastest language". In some operations/programs/software systems some languages are fast, in others other languages.

But here is a point I'd like to make and have been trying to explain to you ever since you brought up performance in this discussion: dynamic compilation often(*) beats static compilation. Please try not to twist that statement into something else - that and your repeated ad hominems reflect poorly on you and do not advance your cause.

(*)"often": as the Excelsior employee above mentions, there is a case where static compilation can beat dynamic compilation: a static compiler can use very expensive algorithms in optimizing. If you don't mind I'll express an opinion based on my compiler work (opinion only, I can't prove this): the number and efectiveness of such expensive optimizations vs. the number and efectiveness of extra optimizations available to a dynamic compiler makes dynamic compilers win with most non-trivial programs.

(Well, there are application benchmarks of GJC vs Hotspot if you qualify those as evidence.)

There was also the claim "a native C++ compiler will always be faster than a JIT compiled Java app". If you wish, you could try the little experiment in my post @ Aug 9, 2005 1:55 AM to see if that statement holds water with your favorite C++ compiler. Oh, but you are "done with me" so I guess only the rest of us will find out the truth there.

Message was edited by: sjasja: typo fix

danielmd
Offline
Joined: 2003-06-13
Points: 0

Dude...

Are you trying to be blind or just an idiot, yes people have reversed applications, and used features, people reverse hardware and do that, there are departments in big companies whose jobs is to reverse hardware and software.

About Speed I think all has been said, you give a linked list example [b]i am talking about GUI speed[/b], I don't see the relevance of compiling the code. A native compiled GUI will always be faster then a JAVA JITed app GET IT!!!

That is the whole point behind SWT.

If JIT works for all your needs great, some people need AOT, paying the price of all the advantages and disadvantages. Plus the whole point of JIT is to transform interpreted code into Native Optimized code.

If it was possible to retain that Native compiled code in beetween run time sessions maybe java GUIs could have the same speed level that native application have. And still have all the advantages that a dynamic compiled application has over a static compiled application.

You are now Overcooked !!!

Message was edited by: danielmd

jwenting
Offline
Joined: 2003-12-02
Points: 0

GUI speed rarely matters though.
It doesn't mean squat if an application screen in Java renders in 25 milliseconds when a C++ screen renders in 19.
The user himself is the limiting factor in the speed of operation of most GUI applications, and his response time to that screen will be an order or magnitude slower than the rendering of that screen at least.
Of course you can create poorly performant GUIs using Java, but you can do that in any language. It might be easier to write a poorly performant GUI using Java even, but you won't solve that using native compilation as it will still perform more slowly than a well written GUI in another language (as well as slower than a dynamic compiled GUI written in Java that was written well).

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I simply mean that it is just in time, it compiles
> to native (optimizes) the most common/used parts of
> code (at run time) vs AOT compiler that does it all
> at (build time).

The terms "JIT" and "dynamic compiler" seem to be interchangably and/or to mean whatever the speaker feels like. But if we follow the terminology here: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html

A JIT compiles everything it runs. A JIT does not have an interpreter, just compiler & execute the compiled code. You can turn a static compiler into a JIT by having it compile classes as they are read in, thus making JIT generated code exactly the same speed (exactly same machine code) as the static compiler.

A Dynamic Compiler picks and chooses what it compiles and when it compiles. A DC might compile everythin on sight, then recompile after it has better understanding of the program. Or it might interpret at first. Eventually the program gets compiled, method by method, until all that remains is optimized machine code.

A DC can produce faster code than a static compiler. Such dynamic compilers exist today and are widely used.

> JIT code can be faster than AOT code but AOT code will
> have a better GUI response, at least this has always
> been the case in all the applications that i tested

Is enough evidence to want static compilation?

Does it matter that benchmarks show existing static Java compilers to produce worse code than Hotspot?

> But this isn't event the topic of the thread, we are
> talking about natively wrapping an application for the
> windows OS, this has it's advantages especially on the
> Task management side, and solves some user friendliness
> problems.

This thread has branched here and there. The original post in this thread does not mention the words wrapper, task, or friendliness. "User" is in there in "end-users actual platform".

Speed and optimization were brought up as alleged advantages of "binary compilation" by danielmd (hey, that's you!) in his Aug 7, 2005 8:34 PM post.

Just pointing out that static compilation does not have an optimization advantage over dynamic compilation. In fact it is exactly the opposite: dynamic compilation beats static compilation right now, today. (I'm guessing "binary compilation" means static compilation but that's just a guess.)

danielmd
Offline
Joined: 2003-06-13
Points: 0

> > I simply mean that it is just in time, it compiles
> > to native (optimizes) the most common/used parts
> of
> > code (at run time) vs AOT compiler that does it
> all
> > at (build time).
>
> The terms "JIT" and "dynamic compiler" seem to be
> interchangably and/or to mean whatever the speaker
> feels like. But if we follow the terminology here:
> http://www.javaworld.com/javaworld/jw-03-1998/jw-03-ho
> tspot.html
>
> A JIT compiles everything it runs. A JIT does not
> have an interpreter, just compiler & execute the
> compiled code. You can turn a static compiler into a
> JIT by having it compile classes as they are read in,
> thus making JIT generated code exactly the same speed
> (exactly same machine code) as the static compiler.
>
> A Dynamic Compiler picks and chooses what it compiles
> and when it compiles. A DC might compile everythin on
> sight, then recompile after it has better
> understanding of the program. Or it might interpret
> at first. Eventually the program gets compiled,
> method by method, until all that remains is optimized
> machine code.
>
> A DC can produce faster code than a static compiler.
> Such dynamic compilers exist today and are widely
> used.

Than a static java compiler yes most of the times it can not 100% of the time and faster than a native optimizing C++ compiler hardly.

> > JIT code can be faster than AOT code but AOT code
> will
> > have a better GUI response, at least this has
> always
> > been the case in all the applications that i
> tested
>
> Is enough evidence to want static compilation?
>
> Does it matter that benchmarks show existing static
> Java compilers to produce worse code than Hotspot?

If it makes the GUI respond faster, i don't have a problem on having overall worse performance. If it turns out to be a better user experience.

> > But this isn't event the topic of the thread, we
> are
> > talking about natively wrapping an application for
> the
> > windows OS, this has it's advantages especially on
> the
> > Task management side, and solves some user
> friendliness
> > problems.
>
> This thread has branched here and there. The original
> post in this thread does not mention the words
> wrapper, task, or friendliness. "User" is in there
> in "end-users actual platform".

The mention of Netbeans.exe and Eclipse.exe are Wrapper .exe, also there is a problem with the taskmanager, it only shows the javaw process instead of the app name, this can be solved by using Process Explorer, still it is not nice...

[i]"That would minimize the job for developers to look for other solutions - i.g. writing a batch script, building a jar manifesto etc. - to just passing a compiler option."
[/i]
and look why would one build an exe instead of a jar with a manifest, or a bat file...could it be?... To make the whole process of running a java file on windows more user friendly,to use the native behavior to that platform, clicking on a .exe is the norm in windows. You should not take things so literally :)

> Speed and optimization were brought up as alleged
> advantages of "binary compilation" by danielmd (hey,
> that's you!) in his Aug 7, 2005 8:34 PM post.

Why are you trying to take things out of context, just try it, load the Windows version of notepad, and then load the java version of notepad/WordPad, and see witch one responds best, use the open file dialog box, use the menus... and this is a small app, and still the GUI performance problems are present in the java version.

Believe me, I hate that the performance difference/nag is there, but the fact is that it is there is no denying it, and users complain about it and they are right, they are not used to this kind of performance.

> Just pointing out that static compilation does not
> have an optimization advantage over dynamic
> compilation. In fact it is exactly the opposite:
> dynamic compilation beats static compilation right
> now, today. (I'm guessing "binary compilation" means
> static compilation but that's just a guess.)

Well that depends on what compiler are we talking about, a native C++ compiler will always be faster than a JIT compiled Java app. AOT compilation can have an overall slower performance, but from my experience the GUI responds in a faster more responsive way... it also, can inflate the size of an application by more than double, But it does have a place in the market, hey Excelsior JET has been around for more than 5years.

Now Please do not take statements out of context, or try to distort the truth, you must a republican ;)

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Now Please do not take statements out of context,
> or try to distort the truth,

Your style of rhetoric does not advance your cause.

> Well that depends on what compiler are we talking
> about, a native C++ compiler will always be faster
> than a JIT compiled Java app.

Could you please compile and run the following and report your timings? Make sure you use optimization compiler flags for C++ and "java -server" in running the Java version. Make very very sure you use "java -server" and "c++ -O". Did you use "java -server" and "c++ -O"?
[code]
#include
#include
#include

using namespace std;

class LinkedList
{
private:
LinkedList *link;
void *data;

public:
LinkedList(LinkedList *tail)
{
link = tail;
}

virtual LinkedList *next() { return link; }
};

int milliseconds(struct timeval *start, struct timeval *end)
{
int usec = (end->tv_sec - start->tv_sec) * 1000000 + end->tv_usec - start->tv_usec;
return (usec + 500) / 1000;
}

void doit()
{
struct timeval start, end;
int rounds = 100000;

LinkedList *list = new LinkedList(NULL);
for (int n = 0; n < 1000; n++)
list = new LinkedList(list);

gettimeofday(&start, NULL);
int length = 0;
for (int m = 0; m < rounds; m++) {
for (LinkedList *scan = list; scan != NULL; scan = scan->next())
length++;
}
gettimeofday(&end, NULL);

long time = milliseconds(&start, &end);
cout << "time " << time << " ms, length " << length << endl;
}

int main()
{
for (int n = 0; n < 5; n++)
doit();
return 0;
}

/************* Then the Java version *******************/

class LinkedList
{
private LinkedList link;
private Object data;

public LinkedList(LinkedList tail)
{
link = tail;
}

public LinkedList next() { return link; }
}

class List
{
public static void main(String args[])
{
System.out.println("Ignore the first few timings.");
System.out.println("They include Hotspot compilation time.");
System.out.println("I hope you are running me with \"java -server\"!");
for (int n = 0; n < 5; n++)
doit();
}

static void doit()
{
int rounds = 100000;

LinkedList list = new LinkedList(null);
for (int n = 0; n < 1000; n++)
list = new LinkedList(list);

long start = System.currentTimeMillis();
int length = 0;
for (int m = 0; m < rounds; m++) {
for (LinkedList scan = list; scan != null; scan = scan.next())
length++;
}
long end = System.currentTimeMillis();

System.out.println("time " + (end - start) + " ms, length " + length);
}
}
[/code]

javakiddy
Offline
Joined: 2004-01-23
Points: 0

Isn't this just another example of the one-size-fits-all philosophy which seems to dominate software development these days?

Back when I started programming, almost 25 years ago, languages were considered tools with different purposes. BASIC, C, Assembler, COBOL, etc, were all used for different purposes, to solve different types of problem. Today it seems more like languages are considered 'lifestyle choices' - you pick a language you like, then expect it to be good at tackling any type of problem you want to solve.

Languages have attracted a 'fanboy' culture, which I'm pretty sure they didn't have a couple of decades ago (at least, not to anywhere near the same degree!) Some of the tit-for-tat between the different language camps is now every bit as bad as the PC/Mac holy war at its height.

Languages are tools. You pick the tool which fits the job. If you don't like the notion of having to install a runtime before someone can run your software, DON'T USE JAVA!!!

Let's celebrate the differences between languages, rather than pushing to create one great homogeneous language - a jack of all trades and a master of none!

danielmd
Offline
Joined: 2003-06-13
Points: 0

> Languages are tools. You pick the tool which fits
> the job. If you don't like the notion of having to
> install a runtime before someone can run your
> software, DON'T USE JAVA!!!

I agree with you in 95% of the cases, but java does bring more to the table that might make it more attractive to 5% of the population that really should be using C++ like better OOP features, smarter tools, etc... and for those people Native AOT (Full application not Wrapper) compilation might cover up some GUI responsiveness and be the solution for them.

Don't get me wrong i think JIT is great, but there is a need for AOT even if it's a marginal need.

Now Native integration that's another story, and i do think that the Java Webstart and JNLP is a very bad protocol, it's being fixed but there will be no real progress until Mustang comes out mid-2006. The other option is to have smart deployment tools that will make the installation process transparent to the Native OS, simple stuff like Add/Remove programs integration (uninstaller) Desktop shortcuts, and other Stuff that Native application have and that make java client apps so weird to the end user. They just don't care if it's java or not, and wend they see that java starting splash screen and the permissions dialog they get scared, and wont use it.

Wend they see a .jar file they don't know they are suppose to have a JRE installed, or that they should click that file, they don't know what a .jar file is, but they recognize a .exe for sure, and know they are suppose to click it to execute/run the application, and that's all there is.

Oh lets not forget that more than 90% of the OS desktop market is Microsoft Windows so should Sun make an effort to make client desktop applications easier to deploy, YES they SHOULD. Especially now that they have become such close friends ;)

sjasja
Offline
Joined: 2004-08-15
Points: 0

> you missed the point. If you try to decompile a java or
> C# application you can do so very easily and get the
> source code, meta data, a pretty UML diagram, the works,
> really reverse engineer all the parts in no time.

So? Why would you try to prevent someone from decompiling your code?

Here is a little secret: very few people care about your code. say you spent years writing a great application. You release it and billions upon billions of people have no interest in decompiling it. Sad but true.

Why are you worried that people will decompile your programs? Did you put a secret in there? Secrets aren't safe even in an .exe.

> Also with binary compilation you get allot of other
> advantages, like speed, optimization, file size, etc...

This is why Hotspot does binary compilation!!!!! Hotspot compiles Java into the exact same binary machine instructions as a static compiler does. Except that because Hotspot has access to run-time information, Hotspot can compile into even faster code and optimize more! Dynamic compilers can do things like "virtual" function inlining, which static compilers can't do.

Think of it this way: take an existing static compiler and make it into a JIT compiler by doing the compilation just before the program is executed. The JIT compiler you get this way produces [u]exactly[/u] the same speed code as a static compiler -- after all, it is the exact same compiler as the static compiler you started with.

After you have done that, you can add [i]more[/i] optimizations. For example, if you notice LinkedList is never subclassed, you can inline LinkedList.size(). Hey presto, you have a dynamic compiler that trivially produces faster code than the static compiler you started with.

Or you can make the compiler detect that the CPU it is running on has the SSE2 instruction set extension, or the CMOV instruction, or it is an Athlon which has different instruction timings from an Intel, or that there are four CPUs which requires special synchronization. A dynamic compiler uses the CPU more efficiently than a static compiler because a dynamic compiler can look at the details of the CPU and the computer it is running on.

Right now, today, dynamic compilers produce faster code than static compilers. .exe is [i]so[/i] last century, slow and obsolete.

danielmd
Offline
Joined: 2003-06-13
Points: 0

> > you missed the point. If you try to decompile a
> java or
> > C# application you can do so very easily and get
> the
> > source code, meta data, a pretty UML diagram, the
> works,
> > really reverse engineer all the parts in no time.
>
> So? Why would you try to prevent someone from
> decompiling your code?
>
> Here is a little secret: very few people care about
> your code. say you spent years writing a great
> application. You release it and billions upon
> billions of people have no interest in decompiling
> it. Sad but true.
>
> Why are you worried that people will decompile your
> programs? Did you put a secret in there? Secrets
> aren't safe even in an .exe.

I don't, it is just a fact that C/C++ apps are harder to Reverse Engineer, and compiling them to native format is a much effective technique than simple obfuscation. Safe NO, just Safer.

> > Also with binary compilation you get allot of
> other
> > advantages, like speed, optimization, file size,
> etc...
>
> This is why Hotspot does binary compilation!!!!!
> Hotspot compiles Java into the exact same binary
> machine instructions as a static compiler does.
> Except that because Hotspot has access to run-time
> information, Hotspot can compile into even faster
> code and optimize more! Dynamic compilers can do
> things like "virtual" function inlining, which static
> compilers can't do.

The thing with JIT compiler is that they are algorithmic, and can't fully optimize an application, there is always a delay to native compiled applications.

There are advantages to AOT and disavantages, it is an option, might work for some people that needs a more responsive GUI.

> Think of it this way: take an existing static
> compiler and make it into a JIT compiler by doing the
> compilation just before the program is executed. The
> JIT compiler you get this way produces [u]exactly[/u]
> the same speed code as a static compiler -- after
> all, it is the exact same compiler as the static
> compiler you started with.
>
> After you have done that, you can add [i]more[/i]
> optimizations. For example, if you notice LinkedList
> is never subclassed, you can inline
> LinkedList.size(). Hey presto, you have a dynamic
> compiler that trivially produces faster code than the
> static compiler you started with.
>
> Or you can make the compiler detect that the CPU it
> is running on has the SSE2 instruction set extension,
> or the CMOV instruction, or it is an Athlon which has
> different instruction timings from an Intel, or that
> there are four CPUs which requires special
> synchronization. A dynamic compiler uses the CPU
> more efficiently than a static compiler because a
> dynamic compiler can look at the details of the CPU
> and the computer it is running on.
>
> Right now, today, dynamic compilers produce faster
> code than static compilers. .exe is [i]so[/i] last
> century, slow and obsolete.

Again tell that to any SWING Gui user vs a Native Gui user, and see if he buys that. Simple test open notepad or wordpad (if you are using win) and then try the java notepad, see if you can spot the differences, i know i can.

Message was edited by: danielmd

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I don't, it is just a fact that C/C++ apps are harder to
> Reverse Engineer, and compiling them to native format is
> a much effective technique than simple obfuscation.

Are you being hurt by people decompiling your programs? Would compiling to machine language prevent that? Is there a real problem here somewhere?

> The thing with JIT compiler is that they are
> algorithmic,

Huh? Can you explain a bit more what you mean by "algorithmic"? I've written one compiler myself and been in a team to write another; so you can be specific and technical in your explanation.

> and can't fully optimize an application

No compiler can "fully optimize" - perfect optimization is equivalent to the halting problem which is unsolvable.

JIT compilers can and do compile to better code than static compilers. Right now, today.

danielmd
Offline
Joined: 2003-06-13
Points: 0

> > I don't, it is just a fact that C/C++ apps are
> harder to
> > Reverse Engineer, and compiling them to native
> format is
> > a much effective technique than simple
> obfuscation.
>
> Are you being hurt by people decompiling your
> programs? Would compiling to machine language prevent
> that? Is there a real problem here somewhere?

No i have no problem with it :) It is just a fact.

> > The thing with JIT compiler is that they are
> > algorithmic,
>
> Huh? Can you explain a bit more what you mean by
> "algorithmic"? I've written one compiler myself and
> been in a team to write another; so you can be
> specific and technical in your explanation.

I simply mean that it is [b]just in time[/b], it compiles to native (optimizes) the most common/used parts of code (at run time) vs AOT compiler that does it all at (build time).

> > and can't fully optimize an application
>
> No compiler can "fully optimize" - perfect
> optimization is equivalent to the halting problem
> which is unsolvable.
>
> JIT compilers can and do compile to better code than
> static compilers. Right now, today.

I think JIT is the best thing that happened to the JVM, but it simply does not give the same levels of GUI responsiveness that a native app does. JIT code can be faster than AOT code but AOT code will have a better GUI response, at least this has always been the case in all the applications that i tested, so there is a small margin of users that should be using C++ but are using Java and might need to use AOT.

But this isn't event the topic of the thread, we are talking about natively wrapping an application for the windows OS, this has it's advantages especially on the Task management side, and solves some user friendliness problems.

Message was edited by: danielmd

markelsoft
Offline
Joined: 2005-04-13
Points: 0

You are right most people will not decompile or reverse engineer your Java code. However, developers are not most people and developers WILL decompile JARs that contain code they find interesting and in some case want to steal. But in the commercial arena you have to protect your investment and using obfuscating technigues and/or compiling to native code (.exe on Windows or .bin on Unix) is such a measure. It is very easy decompile Java code using tools such as DeCafe and then use the code in your own application.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> You are right most people will not decompile or reverse
> engineer your Java code. However, developers are not most
> people and developers WILL decompile JARs that contain
> code they find interesting and in some case want to steal.

Do you have an URL to a case where someone decompiled and stole Java code? How many times and how have you been hurt by this? I'm interested whether this is a real or an imagined problem.

I have occasionally decompiled class files to find out how the code really works when documentation has been poor. I don't think it hurt the library programmer though. I have also disassembled C and C++ code for the same reason.

If I wanted to see source code I'd just go to, say, sourceforge.net. More than a hundred thousand software projects with more source code there than I can possibly read.

alexanderschunk
Offline
Joined: 2005-03-24
Points: 0

oh my god,

may be i should have been more precise in my first post ;)

My intention was to run a debate on having a native win32 compiler switch in order to compile directly to windows plattforms and build exe files instead of having to run any 3rd party tools to do the job.

The problem is what someone else already mentioned here in this thread: If i compile an AWT or Swing app to windows i have a Jar file to distribute and people are forced to dl or install the java runtime.

What i wanted is to compile Windows exe files like i can do with C or C++ without the need to worry about end-user having installed the JRE.

To those guys working with Linux i understand that they dont worry about win32 native compilation however you cannot compare those 2 plattforms simply because under Linux there are so many different versions of binaries like rpm, debian packages etc. whereas under Windows you only have .exe.

And, by the way, i dont see that .exe is outdated simply because all present - and future - versions of Windows will run on .exe files.

danielmd
Offline
Joined: 2003-06-13
Points: 0

Sun will not do that, and they won’t even tell you why they won’t do it. To me it is due to historical reasons and a thinking ahead of your time mentality that reins in Sun they have allot of smart people in their ranks (I would say most belong to the Top 1% of worldwide smart people), the thing is… wend you put allot of smart people in one place they think that they are smarter than everybody (they think they are Psychohistorians – any Asimov fan will get this one if you don’t go to wikipedia), and that’s wend you do mistakes that cost allot of money, (just see the stock values from the last 5years).

OT: I really wish Scott McNealy stopped clowning around he is simply to attached to the company, dressing up in a penguin suit and acting like a clown only works for one CEO/President (Richard Branson), anyway corporate politics aside it is time to talk about the evolution of java and the denial by Sun to make it a Desktop technology, because to a large extent that was accepting Microsoft, and the Windows Operating System, and as we all know Bill and Scott did not like each other, some years and a couple of billion dollars latter, now they are best buddies. Anyway…

Ok I think it is time for a little walk down history lane…

Back in 1996 the first time I tried java (JDK1.0) I Hated It, it was slow had almost no features (no printer support, I just rolled on the floor laughing so this is the Next Big Thing that all the magazines and Usenet groups are talking about Right ;) ), it simply was not ready for prime time, but it did have an interesting thing Applets ( programs that actually don’t need to be installed and run on any operating system on any computer, now that is cool) but there was not much that a real programmer could do with it, and it was beyond salvation for the Desktop Market, and especially AWT was not up to the job.

With JDK 1.1 some mistakes whore corrected (JFC added more than 700 classes and introduced SWING) and swing was/is a well thought GUI library it was powerful enough to stand against MFC, still performance was not good, so the desktop market was once more unthinkable/neglected.

JDK1.2 brought Hotspot, and this is the time that java should have been made a first grade desktop platform, but at this time Macromedia Flash was substituting Applets as the Rich Internet Application platform aspirations so instead of directing attention to rich internet client desktop apps they come up with EJB (the Enterprise market is the way to go)…JavaCard… thin clients… etc…

…this is getting way too long I will fast forward, the point is they always neglected the Desktop Market, and wend Microsoft tried to take over the JVM we all know what happened (.NET that is actually a framework with the Desktop in mind).

Meanwhile a couple of companies realizing there was an opportunity for Native Desktop Client (the need for AOT) software using the java language, lunched in that field, by 2001 there was more than 10 products to natively compile Java code and get rid of the JRE need, but also to make it perform faster better startup times (all that is good about AOT)… fast forward to 2005 there are now only two products (well one actually Excelsior JET, the GCJ is GNU so it is part of the GCC and it is OSS but does not support many of the most important features for a GUI Desktop client application.), with so many Third party applications to create native java applications they saw no need (and since this is not their vision) to support the desktop market extensively.

And to this day on the back of their heads, IMHO they still believe that supporting Desktop Client Software is supporting Windows, and since they don’t like windows they neglect it, there is allot of Bad Blood behind all of this, and that is the main reason why you will not see this feature introduced, it has nothing to do with technology, architecture, design, it is simply a case of Bad Blood between Sun (Scott, Gosling, The java team) and the Windows platform (Bill, Balmer), because accept it or not, the Desktop Market is Windows.

And you don’t have to belong to the Top1% to see this ;)

In conclusion they never thought of the Desktop market as a prime time target (their visions and smart people always think ahead of their own time, and they constantly keep getting hurt by not accepting that this is the time of the Desktop, this is the XXI century not the XXII) and on the other hand we all know that Gosling and Scott have problems accepting the dominance of Windows, to put it simply there is still allot of Bad Blood going around between Microsoft and Sun (kids with multi-billion Toys).

Message was edited by: danielmd

jwenting
Offline
Joined: 2003-12-02
Points: 0

> To clarify my state-of-view:
>
> I actually just meant to hava a compiler switch like
> so:
>
> javac -win32 main.java

Again, what good what that do?

My main deployment platform is Linux, with secondary deployments on AIX and Windows, and the occasional deployment on SCO Unix, Solaris, and HP.

90% of my customers won't be able to run that exe, every one of them can run a classfile deployed in an executable jar (or for GUI applications optionally JNLP).

Making platform specific extensions should be the responsibility of 3rd party tools providers and operating system manufacturers, not Sun.

danielmd
Offline
Joined: 2003-06-13
Points: 0

> > To clarify my state-of-view:
> >
> > I actually just meant to hava a compiler switch
> like
> > so:
> >
> > javac -win32 main.java
>
>
> Again, what good what that do?
>
> My main deployment platform is Linux, with secondary
> deployments on AIX and Windows, and the occasional
> deployment on SCO Unix, Solaris, and HP.
>
> 90% of my customers won't be able to run that exe,
> every one of them can run a classfile deployed in an
> executable jar (or for GUI applications optionally
> JNLP).
>
> Making platform specific extensions should be the
> responsibility of 3rd party tools providers and
> operating system manufacturers, not Sun.

It might be useful for Task Manager problems, there could also be native linux, aix, etc... wrapers.

But i agree with you, it should be a 3rd party tool, and there are third party tools that do just that, i don't know if there are any OSS that does that.

vhi
Offline
Joined: 2004-10-11
Points: 0

>> But i agree with you, it should be a 3rd party tool, and there are third party tools that do just that, i don't know if there are any OSS that does that.

Try JSmooth.

http://jsmooth.sourceforge.net/

I can vouch for its simplicity and effectiveness.

fuerte
Offline
Joined: 2004-11-22
Points: 0

I agree 100%, this should be implemented in Mustang. It should be quite easy to do as well. Primary reason is that the process should be easily identifiable. Now if I start Azureus, for example, I see two new processes in Windows Task Manager: Azureus.exe and javaw.exe.

a) I should only need one process for one program.

b) javaw.exe is anonymous, it is impossible to say what it is doing.

When Personal Firewall asks if I want javaw.exe to access network, I must say Yes, meaning that all other Java programs have access as well. It should be easy to write viruses and backdoors using Java, because Java applications are anonymous.

By using Process Explorer from Sysinternals, I see that Azureus.exe is the owner of javaw.exe. I also see that javaw.exe was started with command line:

"D:\Program Files\Java\jre1.6.0\bin\javaw.exe" "-Djava.library.path=F:\Programs\Azureus\\" "-Duser.dir=F:\Programs\Azureus\\" -Xmx128m -Xms16m -classpath ";F:\Programs\Azureus\Azureus2.jar;F:\Programs\Azureus\swt.jar;" org.gudy.azureus2.ui.swt.Main

Javaw.exe is pretty small, under 64 kB, so it should be pretty easy to build native Azureus.exe that would require java.dll and other runtime libraries, and which would have these command line options and jars built in.

We would have only one identifiable process, only one executable which would have all required components built in (except the JRE).

danielmd
Offline
Joined: 2003-06-13
Points: 0

> I agree 100%, this should be implemented in Mustang.
> It should be quite easy to do as well. Primary reason
> is that the process should be easily identifiable.
> Now if I start Azureus, for example, I see two new
> processes in Windows Task Manager: Azureus.exe and
> javaw.exe.
>
> a) I should only need one process for one program.
>
> b) javaw.exe is anonymous, it is impossible to say
> what it is doing.
>
> When Personal Firewall asks if I want javaw.exe to
> access network, I must say Yes, meaning that all
> other Java programs have access as well. It should be
> easy to write viruses and backdoors using Java,
> because Java applications are anonymous.
>
> By using Process Explorer from Sysinternals, I see
> that Azureus.exe is the owner of javaw.exe. I also
> see that javaw.exe was started with command line:
>
> "D:\Program Files\Java\jre1.6.0\bin\javaw.exe"
> "-Djava.library.path=F:\Programs\Azureus\\"
> " "-Duser.dir=F:\Programs\Azureus\\" -Xmx128m
> -Xms16m -classpath
> h
> ";F:\Programs\Azureus\Azureus2.jar;F:\Programs\Azureus
> \swt.jar;" org.gudy.azureus2.ui.swt.Main
>
> Javaw.exe is pretty small, under 64 kB, so it should
> be pretty easy to build native Azureus.exe that would
> require java.dll and other runtime libraries, and
> which would have these command line options and jars
> built in.
>
> We would have only one identifiable process, only one
> executable which would have all required components
> built in (except the JRE).

To me it just looks like the appropriate thing to do, i think it would simplify many things (that have to do with processes) and could improve performance.

rizzix
Offline
Joined: 2004-08-21
Points: 0

Wow, you can actually implement GC for natively compiled code? I mean like the way Java does it? Cool!

Either way.. if SUN is to add an option to compile to native code, then they would have to add such an option for each platform out there..

Don't tell me that windows has the largest market share and hence windows alone would suffice. Of all the java apps created, how many of those are created to run on windows alone?

A problem now isn't it?

I think it's best to leave things the way they are... Native compilation is not necessary. If you are soo insterested in such a thing look into gcj or something.

Message was edited by: rizzix

htayod
Offline
Joined: 2005-08-09
Points: 0

Wow, brilliant discussion!

I want to make some clarifications on what is AOT/native compilation and how it can help. Hope these statements can be useful for those who read the discussion:

/* I work for Excelsior LLC, which develops and sells AOT compiler. So my optinion _is_ biased */

1. AOT-compilation is not a silver bullet. It makes SOME applications faster, more responsive or more secure, but it does not improve EVERY program. There is no way to predict. All you can do is try it on your app.

2. There are Java developers who really use AOT compilation. Mostly they aim to achieve the following goals:

2.1 Protect code from reverse engineering.

2.2 Decrease application start-up time.

2.3 Decrease GUI responce time.

2.4 Improve overall application performance.

I have seen many applications that really benefit from native compilation, by improving one or several of the listed parameters.

As well, I have seen many applications that do not benefit (they work slower, they have worse start-up time, by they nature native compilation does not protect them etc).

3. Both statements "JIT is better than AOT" and "AOT is better than JIT" are false. It depends on the nature of your application, on the underlying hardware, on the usage scenario.

JIT compiler can do dynamic optimization - it is aware of the actual hardware configuration and it has profiling data, so _sometimes_ it produces better code.

AOT compiler has more time to optimize your program. It can use more time-consuming optimization algorithms. So, _sometimes_ it produces better code.

Finally, there is no "abstract" JIT or AOT compilers. You can compare specific products (for instance Sun's HotSpot Server VM 1.5.0 against Excelsior JET 3.7). They differ not only in being JIT- or AOT-based, but by other parameters as well. For instance, they use different GC algorithms, and it can affect performance of your application.

4. (Just for curious people) Sun uses AOT technology. In HotSpot VM in Java 1.5, some core classes are pre-compiled to native code and are loaded at the applicaiton start-up instead of dynamic compilation.

5. There are two AOT compilers for J2SE Java:

5.1 Excelsior JET (http://www.excelsior-usa.com/jet.html)

5.2 GCJ (http://gcc.gnu.org/java/)

JET is commercial product. It supports the whole Java 1.4/1.5. Any Java program can be compiled to .exe by JET, and it will run excactly the same way it was with "java.exe -jar" or whatever.

GCJ is free. It supports a subset of Java API, for instance, you cannot compile a Swing-based application to .exe by using GCJ.

Denis.

alexanderschunk
Offline
Joined: 2005-03-24
Points: 0

To clarify my state-of-view:

I actually just meant to hava a compiler switch like so:

javac -win32 main.java

where main.java is the only one main.java file that starts up the app. I know there are plenty of apps who my have more than one "main.java" file, so that may not fit to them.

A solution for this would be to write an Ant script passing the -win32 switch to all of the "main.java" files that might be there.

I just wanted to have native win32 exe file as you can build with C or C++.

I know the hacks of batch scripts or other mechanisms to get java files running on windows and i don't find neither of them really convincing nor comfortable.

Again, this thread was speculative trying to push some debate about this.

podlesh
Offline
Joined: 2004-07-26
Points: 0

> javac -win32 main.java
>
> I know the hacks of batch scripts or other mechanisms
> to get java files running on windows and i don't find
> neither of them really convincing nor comfortable.

So, what you need is some .exe wrapper, which starts java (javaw) ? That's reasonable request, but it's not SO simple.

You need to specify full runtime classpath (which can be different to compile-time classpath!) and main class, at least. Maybe you'll need some additional platform-dependent data (icon, for example).

For this reason, it's not good idea to put it into javac. It should be special tool (and it already exists...)

danielmd
Offline
Joined: 2003-06-13
Points: 0

Yes it does, exe4j is one of them, and there are many other there are even some OSS out there, but they require long and at times painful configuration... there can be progress in that field.

Oh and about what [b]sjasja wrote[/b]:
"[i]There is a multi-million dollar business writing assembly language copy protection schemes. Whole armies of PHDs try to prevent people from cracking games.

And still 12-year-olds all around the planet routinely release cracks for every interesting game within days of the game's release.

An .exe is safe...???? Really????[/i]"

you missed the point. If you try to decompile a java or C# application you can do so very easily and get the source code, meta data, a pretty UML diagram, the works, really reverse engineer all the parts in no time.

Try to do that to a exe application and all you get is assembly code, even with powerful disassembler like IDA pro all you get is an overview of the code, some assembly code, the function names, and maybe some schematics, but it is much harder to decode and you never truly get a decompiled version of the application.

So crackers focus on a very small and many times repeated (as in a bought protection solution vs home built) sub-set of the code.

It is much harder to crack a C/C++ application than a java or C# application, but it is much much much more harder to decompile RE a C/C++ application than a Java one.

Also with binary compilation you get allot of other advantages, like speed, optimization, file size, etc... it is not for all applications, i would say 90% of the java client application due to their static nature would benefit from being natively compiled, 10% would not because they are too dynamic.

Message was edited by: danielmd

jwenting
Offline
Joined: 2003-12-02
Points: 0

> you missed the point. If you try to decompile a java
> or C# application you can do so very easily and get
> the source code, meta data, a pretty UML diagram, the
> works, really reverse engineer all the parts in no
> time.
>
If you need to care that much about such things you should choose a different business model.

> Try to do that to a exe application and all you get
> is assembly code, even with powerful disassembler
> like IDA pro all you get is an overview of the code,
> some assembly code, the function names, and maybe
> some schematics, but it is much harder to decode and
> you never truly get a decompiled version of the
> application.
>
If they're determined and knowledgable enough they won't care.
In fact with the right tools many C/C++ applications can be decompiled to C/C++ code with little effort.

> So crackers focus on a very small and many times
> repeated (as in a bought protection solution vs home
> built) sub-set of the code.
>
That's just a time saver :)

> Also with binary compilation you get allot of other
> advantages, like speed, optimization, file size,
> etc... it is not for all applications, i would say
> 90% of the java client application due to their
> static nature would benefit from being natively
> compiled, 10% would not because they are too dynamic.
>
Ah, the old myth of "static compiled code is inherently faster than on demand compiled code".
Patently not true, especially since the introduction of JIT compilers which can create highly optimised code beating any static compiler.

danielmd
Offline
Joined: 2003-06-13
Points: 0

> > you missed the point. If you try to decompile a
> java
> > or C# application you can do so very easily and
> get
> > the source code, meta data, a pretty UML diagram,
> the
> > works, really reverse engineer all the parts in no
> > time.
> >
> If you need to care that much about such things you
> should choose a different business model.

Hum ? Did not get it.

> > Try to do that to a exe application and all you
> get
> > is assembly code, even with powerful disassembler
> > like IDA pro all you get is an overview of the
> code,
> > some assembly code, the function names, and maybe
> > some schematics, but it is much harder to decode
> and
> > you never truly get a decompiled version of the
> > application.
> >
> If they're determined and knowledgable enough they
> won't care.
> In fact with the right tools many C/C++ applications
> can be decompiled to C/C++ code with little effort.

Well disassembled yes, decompliled i don't think so. I have been disassembling application for more than 10 years now, so please do send me links to the right tools.

> > So crackers focus on a very small and many times
> > repeated (as in a bought protection solution vs
> home
> > built) sub-set of the code.
> >
> That's just a time saver :)
>
> Ah, the old myth of "static compiled code is
> inherently faster than on demand compiled code".
> Patently not true, especially since the introduction
> of JIT compilers which can create highly optimised
> code beating any static compiler.

Well tell it to SWING GUI app users, versus native GUI apps, oh and SWT is not a real option so don't even go there.

jdavi
Offline
Joined: 2003-06-11
Points: 0

> > > you missed the point. If you try to decompile a
> > java
> > > or C# application you can do so very easily and
> > get
> > > the source code, meta data, a pretty UML
> diagram,
> > the
> > > works, really reverse engineer all the parts in
> no
> > > time.
> > >
> > If you need to care that much about such things
> you
> > should choose a different business model.
>
> Hum ? Did not get it.
>
> > > Try to do that to a exe application and all you
> > get
> > > is assembly code, even with powerful
> disassembler
> > > like IDA pro all you get is an overview of the
> > code,
> > > some assembly code, the function names, and
> maybe
> > > some schematics, but it is much harder to decode
> > and
> > > you never truly get a decompiled version of the
> > > application.
> > >
> > If they're determined and knowledgable enough they
> > won't care.
> > In fact with the right tools many C/C++
> applications
> > can be decompiled to C/C++ code with little
> effort.
>
> Well disassembled yes, decompliled i don't think so.
> I have been disassembling application for more than
> 10 years now, so please do send me links to the right
> tools.

I just typed decompile C code in google and it came up wit h a few usefull links,
http://www.backerstreet.com/rec/rec.htm

>
> > > So crackers focus on a very small and many times
> > > repeated (as in a bought protection solution vs
> > home
> > > built) sub-set of the code.
> > >
> > That's just a time saver :)
> >
> > Ah, the old myth of "static compiled code is
> > inherently faster than on demand compiled code".
> > Patently not true, especially since the
> introduction
> > of JIT compilers which can create highly optimised
> > code beating any static compiler.
>
> Well tell it to SWING GUI app users, versus native
> GUI apps, oh and SWT is not a real option so don't
> even go there.

I don't think that it has anything to do with the static vs dinamic, they are generating the GUI using a completelly different method...

danielmd
Offline
Joined: 2003-06-13
Points: 0

> I just typed decompile C code in google and it came
> up wit h a few usefull links,
> http://www.backerstreet.com/rec/rec.htm

I hope you are joking :)

Look just to make it clear obfuscating java programs is like breaking a vase into 100 parts, Native Compilation is like breaking a vase into 10000 parts. I hope you get the analogy (some of that 10000 parts are jsut dust grains).

> > Well tell it to SWING GUI app users, versus native
> > GUI apps, oh and SWT is not a real option so don't
> > even go there.
>
> I don't think that it has anything to do with the
> static vs dinamic, they are generating the GUI using
> a completelly different method...

My only point is Native applications = Faster GUI than JITed applications, from my experience even AOT compiled application have Faster GUI than JITed apps.

imnes
Offline
Joined: 2004-06-29
Points: 0

The GNU Compiler Collection has a java compiler which will compile java source code to native executables, and also pre-compiled java bytecode to native executables. (Also can compile java source to java bytecode).

Works really well. They are still working on getting all of the AWT and Swing libs in place, but if you're writing against native GUI toolkits like Qt or Gtk or Cocoa it's fine. Also will compile against SWT gui kits. (RedHat deploys Eclipse on a GNU gcj system, with no traditional Sun java runtime environment or jdk).

Nick

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Javac compiler option to build Windows native exe

Why?

exe is [i]so[/i] last century... Slow, big, non-portable, ...

aviadbd
Offline
Joined: 2004-07-04
Points: 0

This is a handy tool. It costs money, however.
http://www.ej-technologies.com/products/exe4j/overview.html

Something that's probably worth the money if you develop multi-platform desktop applications is install4j, which creates native yet multi-platform installers.
http://www.ej-technologies.com/products/install4j/overview.html

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Guys... slow down... you don't need to convert bytecode to EXE to have decent deployment.

I recommend you take a look at Jace -- http://sourceforge.net/projects/jace

You can write up a native wrapper which launches the JVM in under 20 lines of code. It's extremely easy. Jace really makes this kind of stuff easy to do and it's completely free.

Though the library itself is quite mature, I'd love for someone to come along and help me maintain it :)

Gili

dog
Offline
Joined: 2003-08-22
Points: 0

Actually there are good reasons to run Java natively. One good reason to do this is code safety (no obfuscators aren't good enough, wrappers won't get the job done). GCC and Excelsior Jet are both able to do this to different degrees.

If javac could do it I'd be all for it. Sometimes a native version is necessary. The java community is large and diverse and native code is important to some people. Especially on the client side.

I guess the more important feature would be for Sun to allow an exception for third party providers (like Excelsior Jet) who technically already can create small native binaries for Java, but cannot do so because of licensing restrictions.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> One good reason to do this is code safety
> (no obfuscators aren't good enough, wrappers
> won't get the job done).

There is a multi-million dollar business writing assembly language copy protection schemes. Whole armies of PHDs try to prevent people from cracking games.

And still 12-year-olds all around the planet routinely release cracks for every interesting game within days of the game's release.

An .exe is safe...???? Really????

dog
Offline
Joined: 2003-08-22
Points: 0

> > One good reason to do this is code safety
> > (no obfuscators aren't good enough, wrappers
> > won't get the job done).
>
> There is a multi-million dollar business writing
> assembly language copy protection schemes. Whole
> armies of PHDs try to prevent people from cracking
> games.
>
> And still 12-year-olds all around the planet
> routinely release cracks for every interesting game
> within days of the game's release.
>
> An .exe is safe...???? Really????

You miss the point. While you can easily crack my exe, you don't have my source code.

Some of us work in markets were you sell an app to a client, then the client doesn't want to pay up for maintenance and searches for some other guy to mod your app (even if you signed a contract that stated otherwise).

Another example.. someone likes your app, but wants to make some minor modifications before he resells it (illegally).

If there program is natively compiled it is much harder to do this (even though it isn't impossible). Maybe even hard enough to disuade the person from doing such things.

But really.. who cares if you understand why some people want/need native compilation. The fact is that they want it. If you don't want it.. good for you.. the debate is tiresome. However, as this forum attests there are people who have good reason to want it.

Some people say "if you want native compilation don't use Java". Well.. I say there's nothing inherent in the Java language that stops me from natively compiling... so why limit it. I should have the option of deciding for myself if I want to use it on my current project.

(I didn't want generics.. this is certainly less painful and more useful that stupid generics)

jwenting
Offline
Joined: 2003-12-02
Points: 0

> Some people say "if you want native compilation don't
> use Java". Well.. I say there's nothing inherent in
> the Java language that stops me from natively
> compiling... so why limit it. I should have the
> option of deciding for myself if I want to use it on
> my current project.
>
And there's nothing to stop you from using a 3rd party tool to get that native compiled false sense of security and performance.
Don't assume Sun is responsible for making everything there can ever be that's related to Java.

> (I didn't want generics.. this is certainly less
> painful and more useful that stupid generics)

No, it's not.
It goes against the very spirit of the language which was designed from the outset to have a single binary format which runs on all platforms that have a JVM (of the correct version).
If you show me a single native executable format that runs on all OSs and hardware platforms out there on which there's a JVM maybe then you have a point (and you've at the same time removed the need for a JVM or any other virtual machine technology).

tlund_
Offline
Joined: 2005-04-21
Points: 0

alexanderschunk:

Ok, the Eclipse and Netbeans exe-files are just launcher files afaik. They just run javaw.exe and the accompanying jar/class-files. Maybe they do a couple of extra tasks in those exe-files, like pop up a splash screen, but their main task is to launch the "main" java code.

I hope you don't mean compiling ALL of the class files into native code.. There are some 3rd party projects out there who tries to do that, but it's only supported for commandline applications afaik. So it won't work for GUI code.

rogerhernandez:
I agree with you on this. If it can solve the problem of every java application showing up as "java.exe" in taskmanager, then it would be a good idea. But just an exe-file that acts as a launcher.

batemana
Offline
Joined: 2003-06-17
Points: 0

>If it can solve the problem of every java application showing up as "java.exe" in taskmanager, then it would be a good idea.

Check out the jps utility that was added in the JDK5.0. It lists java applications that you are running. The output is the pid and class name of the main class and there are various options to customize this ("jps -l" is the long listing showing the full package name or path to the JAR file).

The documentation for jps is here:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jps.html

khooke
Offline
Joined: 2003-06-11
Points: 0

Symantec VisualCafe used to have a native compiler option to compile bytecode to native Windows executables.

That IDE is long since dead, but I bet if you Google around you'll find something around that does the same thing.

Kevin Hooke

dglasser
Offline
Joined: 2003-06-13
Points: 0

khooke, I remember the VisualCafe native Windows compiler. I actually got a non-trivial Swing app compiled to a native Windows .exe file, which, IIRC, was totally self-contained -- it could run on a machine without a JVM installed. But the app ran really slow and had a much larger memory footprint than a normal JVM. It wasn't ready for primetime.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

I'm not sure if this is a request for a classfile -> object file and therefore a native java compiler, or something simplier.

If after building a java application that must be run with:
java -classpath foobar some.long.package.name.classname
or
java -jar foobar.jar
You would rather get a foobar.exe run as:
foobar
that under the covers ran 'java' (similar to our own javac.exe file), then that's a different story, and actually something we could possibly investigate. Kind of an automatic launcher exe file creation. Is that what you had in mind?

[The native java compiler project is a massive undertaking, with lots of issues, which you could discuss if you wanted, but the bottom line in my opinion is that it usually benefits one native platform and often harms the general Java population.]

rogerhernandez
Offline
Joined: 2005-02-23
Points: 0

Actually, generating an executable launcher that executes the VM behind the scenes would be great for process management in Windows, since in the task manager process tab
everything shows up as java.exe. Makes it difficult to tell things appart.