Re: Attention PL authors: want to be listed in template table?

Peter Eisentraut wrote:

>Thomas Hallgren wrote:
>
>
>>Well, yes. But use the word environment in singular please :-) To my
>>knowledge the security is full-proof with all other VM's since they
>>all use the standard runtime libraries.
>>
>>
>
>It's not quite as simple as that. There are a bunch of VMs and a bunch
>of libraries (and a bunch of compilers), and they can be combined in
>many permutations. Not all of them work with PL/Java at the moment,
>but we should not hardcode support for just one of them.
>
>
AFAIK, there are only two flavors of the Java Runtime library out there.
The one that Sun provides (and small variants of it, such as the ones
that IBM, HP, and BEA) and the "classpath" clean-room implementation.
All variants of the former are OK with respect to security and only GCJ
has a working environment of the latter. In particular, only GCJ has a
functional standards conformant Java Native Interface (JNI) API to the
latter and PL/Java is built on JNI.

Should however, someone come up with another Java environment built on
"classpath" that has JNI support, then there will be another potential
environment for PL/Java. TMK, there's no such environment and none in
the making. I have serious doubts that there ever will be. IMO it would
be perfectly safe to hard code support for a trusted "java".

>>The GCJ support is as
>>experimental as the GCJ in itself and cannot be trusted in
>>production.
>>
>>
>
>You should not say that too loud when someone from Red Hat is
>listening. :-) To my knowledge GCJ is Ready(tm) as of version 4.0.
>And it's being used. Distributions such as Fedora and Ubuntu will ship
>(or do ship?) with everything compiled using GCJ to the extent
>possible. And there are people, in particular at or near Red Hat, who
>have been specifically charged for several years now to make sure that
>every piece of Java code out there compiles with GCJ.
>
>
Don't get me wrong. I like GCJ and the idea of compiled Java executables
but I try to look at it's potential and usefulness in a realistic way.
If Red Hat wants to tout that it's production ready, that's up to them.
I'm not a marketing guy.

GCJ currently that has limited security. It is 2 years behind mainstream
in versions (they don't have Java 5 yet and their Java 1.4 support is
not complete). It is not stable and the performance is nowhere close to
the commercial implementations. I think the GCJ team is aware of this
and I seriously doubt that it is surprise to the people at Red Hat.

Try using GCJ to run Java applets in a web browser. You can't really
since such applets cannot be trusted. I doubt the browser vendors make
attempts to prevent it though ;-)

>Regarding the security issue: Word from Andrew Haley of Red Hat is that
>it has simply been too much work to implement security up to now. This
>should not affect the judgement of the quality of GCJ, it's simply a
>missing feature.
>
>
Security is some "feature" to "simply miss". Especially if we talk about
a VM.

>Of course, I don't intend to undermine your judgement as the author
>about what you consider experimental or not, but you should expect that
>if you put your code out there, people will use it in whatever way they
>see fit, and in particular with whatever Java toolchain they see fit.
>
>
I do indeed expect that. But the PostgreSQL community cannot take
responsibility for all that may happen when people do that.

PL/Java is designed to run perfectly safe with a JVM that has the
correct features implemented. GCJ has serious issues with security and I
don't see that PL/Java, nor PostgreSQL should make any attempt to fix
them. How safe is PostgreSQL running on an unsafe operating system?

Regards,
Thomas Hallgren