Size problem

Sun Jan 12 22:51:00 GMT 2003

>>>> We need to start building libgcj as a DLL. That will make a big
>>>> difference. I don't believe anyone is working on this yet.

If that means that every executable becomes exe + libgcj.dll, and that you
have to distribute two files instead of one, then please no. What would be
the next step? A gcj registry full of guids?
Really. No, thanks. That is no progress. Please, make it an optional option
for the afficionados.
In my impression, shared objects (.so, .dll) are based on a deeply and
widely spread misconception that such strategy would have advantages. It
doesn't. In fact, none of the proposed advantages do ever materialize; on
the contrary, they create the notorious dll hell. No matter how well you
organize the shared object system, in the end, you will end up with a dll
hell. It is fundamental to the approach.
(1) it creates a need for installers. I don't want to deal with installers.
It's an utter waste of time. I want xcopy deployment.
(2) it doesn't mean anything if something works on your development machine,
because dependencies will be resolved on the users' machines, which are
potentially all different. So, in some places your application works, in
others it doesn't. I don't want to deal with emails and phone calls
concerning such problems and spend time figuring out. No thanks. If it links
on my machine, that's it. Finished. Done. No phone calls.
(3) you must deploy dependencies anyway, because you can never be sure that
such dll is present on your user's machine, and in the right version.
(4) you end up with multiple versions of the same shared object, cluttering
the machine. Maybe some other application still uses it? We have to leave it
there. And the crap accumulates...
(5) if one application, independent from your application, installed
previously or later, doesn't play by the rules, it f*cks up the system for
everybody. I don't want my application to be dependent of someone else's
f*ck ups and I don't want to f*ck up potentially someone else's application.
(6) dlls must be bug-for-bug backwards compatible. Being simply API
compatible doesn't help. You must preserve all side effects of your or
someone else's old mistakes, providing you know of them. Therefore, after a
while a dll looks like a trashcan full of old deprecated crap (a bit like
the JRE); and still you will never manage to be truly backward compatible.
Deployment becomes a purely stochastical process, without deterministic
outcome, depending on luck, the weather, and the accumulated history of a
particular machine of what you installed, uninstalled, partially installed,
and all halfway failed installs. I really don't want to link to something
outside the executable to figure out if it's there and in the right version.
Been there. Done that. Never again.