Re: Compiling "static" applications with SWT/GTK

[Ranjit Mathew <rmathew at hotmail dot com>]

Andrew Haley wrote:
>  > Download size for one - a statically linked in executable
>  > is unlikely to be as big as the whole libgcj.so, especially
>  > as more and more APIs keep getting implemented in
>  > libgcj.
> 
> That's not really true, because of Java's Class.forName.  You have to
> include all of libgcj, because the linker can't tell what might be
> needed.

True, but as you would know already, a simple workaround is
to define a "private static final Class foo = foo.Bar.class"
somewhere in your program. This bites anyone who
tries to use "java.util.Date" for example.


> As I have said here many times, the right thing to do is create a
> configure tool that splits libgcj into a number of components and
> allow the user to choose which ones they want.  But it's quite hard to
> solve the web of dependencies.

Again, true, and this would indeed be closer to the
indistinguishable blur between statically linked
executables and "DLL installed as needed" scenarios
that Per pointed out.

As you might like to point out wearily, we've discussed
this issue over and over and over again and the static and
dynamic "camps" do not seem to give in. :-)

Technically, I agree with what you say and can appreciate
where you're coming from, but we must realise that there
is a certain (large?) number of Java developers for whom
the primary attraction of GCJ lies in the ability to create
standalone native executables that can be distributed
"as is".

Even though Sun would have liked otherwise, the JRE
is not so ubiquitous that a developer can just ship his
class files and expect the program to run on every
user's machine. (I don't even want to start bitching
about how the JRE monster keeps increasing in size with
every release, further reducing the incentive for a
user to download and install it or for a developer to
bundle it with his application.)

*I* was attracted to GCJ because of this reason. Only
now, the urge is more to create a Free (as in speech)
alternative to Sun's JDK that doesn't artificially
prevent native executables.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/