> >But that shouldn't be a reason to not use it, as
> your >idea that you should select your technologies
> solely on >the size of their jarfiles is idiotic.
>
> Please mind your words. Professional software
> engineers know that user requirements are never
> idiotic or foolish.
>
Au contraire. A lot of those "requirements" are idiotic and foolish, you're just not supposed to say so in their face.
So you have to use more circumspect language, going on about "practical considerations", telling customers that their requirements will lead to unwanted side effects or, in extreme cases, telling them that doing things the way they think they want will cause massively higher development cost (that almost always sways them to see your point).
> For me an expected file size can be a very real
> requirement. For example in applet situations.
> Downloading 40 MB for a simple Swing application can
> be unacceptable.
>
Hardly. The number of serious computer users who are still on slow dialup connections can be counted on the addresses in one subnet ;)
And most of those are probably going to want a CD shipped anyway.
> It is a different story when you install a server.
> Perhaps then a few megabytes do not count. Did you
> forget why flash is so sucesful compared to Java
> applets? Been there done that.
>
Mostly that's because of the incorrect (for the last 5-10 years) assumptions like "Java is slow", "noone has Java installed", "Java is a security risk", "Java is ugly" (the vast majority of Flash applets are just flashing buttons...).
And we're talking about application server client libraries here. Those are most likely to be used over a LAN, not the internet, and the download will (if the browser is configured right) only have to happen once anyway.
> Other problems related to just loading a bunch of Jar
> files are related to loosing control over which
> classes you use. This is especially dangerous when
> you do not a dependency management system like Maven
> or one of its competitors.
>
Hardly dangerous. There's far more classes in the core libraries, you have no control over their use either...
> This can lead to
> - security problems
No more than with small packages. Just choosing the smallest package because there's less classes in it and THEREFORE it's more secure is idiotic because it's a massive fallacy.
> - situations where programmers access internal
> classes directly just because it is possible and they
> are under time pressure
Never seen that happen.
Those classes if they're meant to be used are well documented and no risk, if not they're undocumented and more trouble to use than they're worth.
> - potential classpath problems such as having the
> same class twice in your classpath without knowing
> it.
>
Not with well written packages. In fact with small hobby project packages (which most of those tiny packages are) that risk is far higher.
> In larger software projects with time pressure and
> real customers these things can bounce back. Usually
> all those problems occur in the last hours before
> your final packaging :)
>
I've worked on major applications with many dependencies.
It's hardly ever a problem, and if it is it's always easily resolved (as it's usually just something like 2 different versions of the same jar ending up in a deploy, one of which can harmlessly be removed).
The only times it causes problems is when kids with no experience who think they know it all start putting things like Apache commons jars in JDK/ext/lib directories (or their appserver equivalents), something that should never be done but among youngsters remains a popular alternative to learning how to properly set up a classpath.
Ignorance of the foolish should never be the reason to not do the right thing.
Let the fools burn their fingers, they might learn not to play with fire.
[Message sent by forum member 'jwenting' (jwenting)]
http://forums.java.net/jive/thread.jspa?messageID=265879