Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL in the press again

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: PostgreSQL in the press again
Date: 2004-11-14 09:54:48
Message-ID: 41972B68.2080301@mailblocks.com (view raw or flat)
Thread:
Lists: pgsql-advocacy
Christopher,
Thanks for clearing a few things up. I think what you wrote made a lot o 
sense. Not surprisingly, I have some opinions concerning the things to 
"hate" :-)

> The problem with Java is twofold:
> 
> 1.  Naive system implementations wind up gratuitously using a lot of
>     memory.
> 
> 2.  The garbage collection system makes it particularly difficult to
>     be aware of how the "memory life cycle" works.  Which helps keep
>     developers naive for somewhat longer...
> 
> In the case of eRServer, the way the snapshot system was constructed
> led to "gratuitous memory use," and that's not an obvious result of
> either 1. or 2.
> 
I agree with this. That's why I included "the right skills" in my 
original claim. It's a known fact that Java get's bashed a lot because 
it gives you freedom under responsibility and people tend to forget the 
latter.

> The things to "hate" about Java aren't about any of this.  It's more
> like:
> 
>  - Java runs, in a "supportable" manner, on way fewer platforms than
>    PostgreSQL
> 
An argument that holds true in theory. I wonder what percentage of 
potential replication users that would be lost in real life due to 
portability issues when moving to Java. My guess is zero or perhaps 
fragments of a percent. I seriously belive that the loss contributed to 
"religion" would be greater.

On the Java plus side, you can distribute one runnable binary for all 
platforms where it *does* run as opposed to source that requires the 
user to have a complete build environment. So perhaps this actually 
works in Java's favor.

>  - If you pick libraries that are functional enough to be useful,
>    then you likely have to get a Sun JDK with pretty proprietary
>    licensing
> 
Here I disagree with some emphasis. The JRE in itself contains far more 
useful libraries than any C/C++ compiler package that I'm aware of. And 
if you want to complement what you have, go to Sourceforge, Apache, or 
any other Open Source site where a lot of very useful packages can be 
found. Many of them with production quality.

The JDK/JRE licensing in itself has never been a problem in any projects 
where I have been involved, nor any other Java project that I'm aware 
of. You just don't bundle the JRE, you assume that the customer has it 
installed.

>  - Due to licensing complexities, it's WAY more complex to deploy
>    Java-based apps than C-based apps.  The average Linux or BSD
>    distribution contains hundreds if not thousands of apps 
>    deployed in C; doing the same for Java has proved more than
>    troublesome.
 >
Funny, I've been writing Java apps for the better part of 6 years now. 
I've *never* experienced any licensing complexities *what so ever*. Many 
thousand users use Java on Linux and FreeBSD and they are not violating 
any licenses.

Can you please explain where and how you see license problems pop up?

All and all, I think the licensing question is non existent for people 
who want to provide utilities written in Java. Sourceforge today counts 
13192 Java projects which is very close to the number of C (13762) and 
C++ (14066) projects. A vast majority (95%) of those projects are 
OSI-Approved Open Source. I have no doubt that Java will be #1 by this 
time next year. On the Apache site, you'll find other really useful (and 
free) Java utilities.

In other words, if licensing was a problem you wouldn't see the Java 
community expanding the way it does today, using free Open Source as a 
primary vehicle.

Regards,
Thomas Hallgren


In response to

Responses

pgsql-advocacy by date

Next:From: Gaetano MendolaDate: 2004-11-14 19:05:58
Subject: Re: PostgreSQL in the press again
Previous:From: Christopher BrowneDate: 2004-11-14 07:11:48
Subject: Re: PostgreSQL in the press again

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group