Guy,
As far as I understand, the concerns you brought up only apply to a public JRE.
A private JRE is no different than any other library Postgresql links against. It's an implementation detail that does not affect your system-wide applications. Your vulnerability is no greater using an outdated private JRE than it is running an outdated version of Postgresql. All the Java vulnerabilities I am aware of have to do with running untrusted code on a public JRE (neither of which is being proposed). Lastly, nothing prevents you from upgrading the JRE directory yourself if you see fit (the JRE directory is a drop-in replacement with no external dependencies).
It doesn't matter what brand of JRE you use, because only Postgresql uses it. Using the "wrong" brand will not cause your other applications to break (as it would if you were to replace a public JRE). Companies stick to Java 6 company-wide precisely because updating a public JRE would affect their other applications. Replacing a private JRE would not do that.
Gili
On 18/09/2014 3:40 PM, Guy Rouillier-4 [via PostgreSQL] wrote:
As far as I understand, the concerns you brought up only apply to a public JRE.
A private JRE is no different than any other library Postgresql links against. It's an implementation detail that does not affect your system-wide applications. Your vulnerability is no greater using an outdated private JRE than it is running an outdated version of Postgresql. All the Java vulnerabilities I am aware of have to do with running untrusted code on a public JRE (neither of which is being proposed). Lastly, nothing prevents you from upgrading the JRE directory yourself if you see fit (the JRE directory is a drop-in replacement with no external dependencies).
It doesn't matter what brand of JRE you use, because only Postgresql uses it. Using the "wrong" brand will not cause your other applications to break (as it would if you were to replace a public JRE). Companies stick to Java 6 company-wide precisely because updating a public JRE would affect their other applications. Replacing a private JRE would not do that.
Gili
On 18/09/2014 3:40 PM, Guy Rouillier-4 [via PostgreSQL] wrote:
On 9/18/2014 2:44 PM, cowwoc wrote:
> Yes, that's what I meant. I just wanted to reinforce the fact that you
> don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick
> one and bundle it alongside PG and pl/java.
I've been following along as an interested observer, having used PL/Java
in the past, and developing with Java for a living. I don't think
bundling is a good idea. Gili, as you fully understand, Java is a
moving target. Important vulnerabilities are discovered and updates are
pushed out to address. So, any bundled version would be subject to
possibly rapid obsolescence. Then there are organizational constraints
or concerns. Some will only use official JDKs from Oracle/Sun, others
will only use OpenJDK. Some won't move to a new major version until at
least the .1 release, others stick with their Java 6 company-wide
standard even though that version is officially EOL'd.
So, in my opinion the least contentious way to go would be to have a set
of instructions that inform the end user to install the JDK or JRE of
their choice, subject to defined constraints. Then make PL/Java as
painless as possible to install. This should not be a problem with
larger organizations, since most use centrally-administered software
configuration.
Thanks.
--
Guy Rouillier
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
If you reply to this email, your message will be added to the discussion below:http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819541.html
View this message in context: Re: Why isn't Java support part of Postgresql core?
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
