making static linkage useful (oh the horror!)

[Andrew Haley <aph at redhat dot com>]

Adam Megacz writes:
 > 
 > Andrew Haley <aph@redhat.com> writes:
 > > Trouble is, you're threatening to make static linkage useful!
 > 
 > Ah, the truth comes out!

I don't think this is news.

 > I understand that the gcj folks would like to see libgcj.so/libgcj.dll
 > spread as far and wide as possible as part of your nefarious plot for
 > world domination.

Not precisely.  I want gcj to meet its goal, which is to be a free
Java implementation.  At present, the gcj implementation of static
linkage breaks important areas of the language, including class
loaders and JavaBeans.  Maybe it breaks RMI as well.  Serialization,
probably.  I don't know, and therein lies the problem: static linkage
breaks Java in a bunch of random areas and there's no straightforward
way to find out.

I am in favour of a static linkage mechanism that is not broken.

 > Making static linkage hard to use or bloated does force people to
 > distribute these libraries.
 >
 > To be honest, I have the same motivations with my own project (XWT) in
 > attempting to increase the installed base of xwt.exe, so I can see
 > where you're coming from.
 > 
 > Unfortunately, as you've probably noticed based on the last few months
 > of mailing list traffic, the most common new use for gcj these days
 > seems to be people who want a .java->.exe converter.

That's the most common use for the Windows users on this list at the
present time.  However, it's not our mission, although we're happy to
see that gcj is being useful in this arena.  [ For what our mission
really is, the mission statement is at http://gcc.gnu.org/gccmission.html. ]

 > > That means people will use it, and then ... we have support
 > > headaches.
 > 
 > If support headaches are really the only concern, perhaps we could
 > adopt a policy that static linkage is strictly an experimental,
 > unstable, use-at-your-own-risk feature, and not accept any PRs which
 > cannot be reproduced with dynamic linkage?
 
That would be a good start.

 > BTW, I also think it would be really cool if we could produce
 > statically linked binaries that would dlopen() libgcj.dll/libgcj.so
 > *if available* and use that library instead of the statically linked
 > classes.

Now we're talking about a proper solution. one that has some chance of
meeting the language specification.  Good; this is progress.

Andrew.