Having a look at some short thread in the programming forum related with IDEs, I dropped a look at my Netbeans 6.8.. As I know, that IDE was coded in Java, which is sort of an argument for it's slowness(hell, it is slow!).

However, it's an *.exe file, not a *.jar, which I get when building my Java stuff..
I know *.exe is a set of "instructions" for the OS(CPU directly?), while *.jar is a byte code, that's translated to these "instructions", before it's execution..

So, two things:

1. How do I turn my *.jar to *.exe?
2. Why the heck is Netbeans still SO SLOW, relatively to let's say MSVS?

P.S:
But hell, it's still a lot better than Dev-C++, & is also free.. I'll go suggest it as a "decent IDE" for this guy..

Append:
Missed a comma in the thread name:(

Here's a thread on Yahoo Answers!

Barely anything new there.. It's all obvious. I'm seeking deeper thoughts related with the topic, it also doesn't any touch the fact Netbeans itself is an *.exe file, although AFAIK is written in Java.

I assume it is like how you can use "exedat" to attach data to an executable. Basically there is a boot loader, that loads the data, (java code in this case,) then runs it with the java executable.

There is also a java frontend for GCC that compiles the program as a native executable, not requiring java to be installed on the computer the application is deployed on.

Well .bat were once used during the heyday of the command.exe era of windows when windows existed on ms-dos. Basically running a shell script is somehow equivalent to running a jar file.

Here's an interesting reference on java.exe. Its a lot of information though.

Theres also something call Jsmooth

Here's an actual article on the topic you asked for.

jar is Java Archive. It is a plain zip file with some META-INFormation. Unzipping it would give you the separate packages and class files. You don't need to jar your .class files in order for the Java project to work.

Google.

It's still Java and not a natively compiled C application. The .exe file merely starts the application for you. I have Netbeans installed and I don't have to say invoke "java" with the jar and classpath parameters if I want to run it because it has the native launcher (netbeans-6.8 binary file).

That and its memory intensive. Each byte in Java is represented as a word because thats how the VM sees things when it works on an arbitrary CPU. I'm sure the details are covered somewhere, I found this out on wikipedia although they should have a reference to that statement with more depth.

(Untested)

So many letters..
Bamcca I don't understand you literally. Vertex, I've had a looked on it, I'll look deeper.

So the open question remains- is what that Netbeans is.. How much is it a byte code, are a set of instructions or whatsoever..

As mentioned above, there are tools for that, basically they just run the Java VM with a predefined jar (some tools embed the jar inside the exe).

Java bytecodes are interpreted while .NET IL gets compiled to the native processor before running. Modern Java VMs compile the most used code at runtime, and you can even tune them to get more performance (such as using the server VM instead of a client one, increasing maximum memory, disabling bytecode validation, etc.). EDIT: IDE internal design differences also play a part as well.

http://en.wikipedia.org/wiki/Java_bytecode

I haven't looked into it, but I know NetBeans (or at least the bulk of it) was written in Java. More than likely, the executable is just a simple program to launch the Java code. That's what my sample program above claims to do, although it's untested and I have no idea if it actually works.

What about the JIT stuff? Why can't that just be inserted into the middle of an .exe "template", as it were?

The point about JIT is to optimize for processor-specific code, not just target architecture.

When the program is installed it can be JIT'd and output into an executable.

It could be, that is very similar to how it works in .NET after all. I don't know if there are any Java VM implementations that do that, though.