nate wrote:
>
>> already know how to use them. Imagine if every free OS distribution had
>> included a broken copy of bash and perl and maybe even C and internally
>> modified
>> their code so things still mostly worked.
>
> Were you around back in the late 90s when redhat shipped a broken
> gcc? :)
Pretty much everything was broken back then. Wade through the changes in
sendmail/bind/nfs, etc. And hardly any c compiler would take exactly the
same input as any other. But those things got fixed.
> As for java I suppose having a working java binary in the base install
> certainly would help a bit,
Or NOT having a non-standard thing called java... Or cooperating with
the jpackage group so their rpms would drop in. Or working with Sun to
have their RPM land where packaged things are expected to land.
> but for me the bulk of my work with java
> has been with Tomcat and BEA Weblogic. I'm not even sure today if tomcat
> is available in the base distros,
Yes tomcat is there now - basically the jpackage concept, but instead of
embracing the jpackage repository it is an incompatibly copied version
(probably remnants of work wasted on trying to make it run with their
earlier non-standard flavor of something-like-java).
> And even if tomcat was included it's not exactly the easiest thing to
> use out of the box, even after almost 7 years of using tomcat I still
> find regular old apache 10x easier to manage, so I lean towards more
> basic solutions when they present themselves.
Maybe you haven't looked recently to see how easy it could have been all
along (and this makes my point about driving everyone away from using
java). Take a stock centos5.x install with openjdk and tomcat5 packages
and drop some 3rd party war files in place (like Hudson or Sun's
opengrok). If you don't need to overwrite the root directory you'll
have things working in minutes.
But by now, no application developer expects an end user to have a
working web container as part of their distribution so everything
includes an embedded jetty anyway.
> Java for other uses I believe has been hindered primarily due to
> performance reasons rather than lack of good binaries being included
> in the default distributions.
Ummm, not working at all is a much worse problem than starting up slowly.
> It has a big stigma around it for good
> reason, JVM startup time isn't exactly fast, it tends to have a large
> memory footprint, and I think it wasn't until Java 1.5 that you
> had the ability to share a heap between multiple apps(not sure what
> the right terminology is), but being able to attach an app to an
> already running "common" VM. Maybe not but I think I read something
> about that a few years ago.
Those are the kinds of problems that people figure out how to work
around when they have a working tool in front of them. And they've been
worked out to the point where java is a reasonable language to run in a
cell phone.
> Even though I do have the knowledge to be able to install the "right"
> JVM I tend to avoid java on my own systems wherever possible. It
> certainly has it's use cases, but I don't see it as something that
> should(or could) replace something like C or perl etc on a broad
> scale(at least not yet).
Needing the 'right' jvm, or knowing how/where/why to install it should
never have been required. And if standard jvms had been available in
all the places that c and perl were, not only would it be equally
important as a language it would mean you didn't have to care at all
about the OS running it.
> The thing I dislike most about Java though isn't java itself, it's
> JMX. But that's another topic..
>
> But I do agree that getting java in with a better license at a much
> earlier time would of helped, I'm just not sure how much.
Let's see... Netscape was shipped with an approximately equivalent
license back then. How popular did HTML turn out to be because you
could count on it to work across platforms?
--
Les Mikesell
lesmikesell at gmail.com