Are java executables standalone?

[hill0093]

Are executables compiled from java code standalone,
or do they require accompanying files?
In both windows and linux?
I haven't tried gcc yet.

[Andrew Haley-5]

hill0093 writes:
 >
 > Are executables compiled from java code standalone,
 > or do they require accompanying files?
 > In both windows and linux?
 > I haven't tried gcc yet.

gcj compiles to native code, but there is still a substantial library.
For what it's worth, I'm not aware of any programming language that
generates standalone executables and has no runtime library.

It is possible to link statically against libgcj, and indeed this is
the default in Windows, but the disadvantage is rather large
executable files.

Andrew.

[hill0093]

All the languages and compilers I have used before I started using java made standalone executables. It is a nuisance that the industry seems to have quit that neatness option.

Andrew Haley-5 wrote:

hill0093 writes:
 >
 > Are executables compiled from java code standalone,
 > or do they require accompanying files?
 > In both windows and linux?
 > I haven't tried gcc yet.

gcj compiles to native code, but there is still a substantial library.
For what it's worth, I'm not aware of any programming language that
generates standalone executables and has no runtime library.

It is possible to link statically against libgcj, and indeed this is
the default in Windows, but the disadvantage is rather large
executable files.

Andrew.

[John (Eljay) Love-Jensen]

>All the languages and compilers I have used before I started using java made standalone executables. It is a nuisance that the industry seems to have quit that neatness option.

Just for comparison, out of all 554 non-script executable files in my /bin and /usr/bin directories, only one of them is a standalone executable.

Ignoring a few .COM programs that run under OS/2 and Windows, I don't think I've written a standalone program since MS-DOS or Apple ProDOS (I didn't do any programming on GS/OS).  Even my Amiga programs relied on arp.library and a few others.

Sincerely,
--Eljay

[hill0093]

I think there is some kind of misunderstanding. I am talking about executable binaries like fortran, pascal, and c compilers all normally produced say 10 years ago, not the java byte codes. For example, the Jet compiler produces an .exe for windows, but still requires auxilliary stuff so I don't like it. The compiler should be able to collect the library stuff as it compiles.

John Love-Jensen wrote:

>All the languages and compilers I have used before I started using java made standalone executables. It is a nuisance that the industry seems to have quit that neatness option.

Just for comparison, out of all 554 non-script executable files in my /bin and /usr/bin directories, only one of them is a standalone executable.

Ignoring a few .COM programs that run under OS/2 and Windows, I don't think I've written a standalone program since MS-DOS or Apple ProDOS (I didn't do any programming on GS/OS).  Even my Amiga programs relied on arp.library and a few others.

Sincerely,
--Eljay

[John (Eljay) Love-Jensen]

> I think there is some kind of misunderstanding.

I'm still not understanding.

> ... but still requires auxilliary stuff ...

What is the difference between "auxiliary stuff" of Java (such as the native executables produced by gcj), different from the "auxiliary stuff" of other executables (such as native executables produced by Fortran, Pascal and C), such that the former "auxiliary stuff" you don't like, but the later is "auxiliary stuff" that does not raise any consternation?

If the context is just JBC running on JVM, then I'm right there with you.  I'm not a big fan of JVM -- it's one layer removed from the metal too much for my comfort.

But gcj makes native executables (I think; I haven't used gcj; my understanding is that it's just another front-end for GCC), so the JBC on JVM is not relevant.

(And there's nothing wrong with byte code in certain contexts / problem domains.  I have no problems with Lua bytecode, for example.  And as I understand it, Perl scripts get compiled into Perl bytecode and then executed (interpreted?) by the Perl bytecode engine.  And JBC on JVM for J2EE is clearly a big win, and much more palatable / tractable in the enterprise context.)

Sincerely,
--Eljay

[Andrew Haley-5]

hill0093 writes:
 >
 > I think there is some kind of misunderstanding. I am talking about
 > executable binaries like fortran, pascal, and c compilers all
 > normally produced say 10 years ago, not the java byte codes.

Most people stopped doing that for a very good reason.

A little while ago there was a serious security hole found in zlib,
and it turned out that zlib was statically linked to 100 or so
different packages.  A single Linux distribution had very quickly to
produce 100 emergency erratum packages!  Most people said "never
again."  :-)

Andrew.

[hill0093]

Thanks, I don't remember what Jet's auxiliary stuff was. It might have been
the JVM or some library. But Jet produced an .exe for windows from my java
directory with one command line "jc -main=program program" and gathered
automatically the local .class files it needed. I gave program.exe to a
friend to use and it gave the info I have forgotten but wouldn't execute like
I expect an .exe to execute. So I am wondering if gcc requires similar
deployment auxiliaries. I don't really want to go back to Fortran or Turbo Pascal 5.5
or Turbo c which were actually neat compilers though I need them sometimes to
change old programs.

John Love-Jensen wrote:

> I think there is some kind of misunderstanding.

I'm still not understanding.

> ... but still requires auxilliary stuff ...

What is the difference between "auxiliary stuff" of Java (such as the native executables produced by gcj), different from the "auxiliary stuff" of other executables (such as native executables produced by Fortran, Pascal and C), such that the former "auxiliary stuff" you don't like, but the later is "auxiliary stuff" that does not raise any consternation?

If the context is just JBC running on JVM, then I'm right there with you.  I'm not a big fan of JVM -- it's one layer removed from the metal too much for my comfort.

But gcj makes native executables (I think; I haven't used gcj; my understanding is that it's just another front-end for GCC), so the JBC on JVM is not relevant.

(And there's nothing wrong with byte code in certain contexts / problem domains.  I have no problems with Lua bytecode, for example.  And as I understand it, Perl scripts get compiled into Perl bytecode and then executed (interpreted?) by the Perl bytecode engine.  And JBC on JVM for J2EE is clearly a big win, and much more palatable / tractable in the enterprise context.)

Sincerely,
--Eljay