the holy graal?
Am 18.11.2019 um 15:21 schrieb Tim Hall:
Now interestingly, imagine the following scenario...
Graal works so well they rip out Java from the database and it's just another language supported on top of Graal.
They implement PL/SQL on Graal.
They implement SQL on Graal.
Everything ends up with the "same bytecode", regardless of where it started.
They implement ZX81 basic on Graal.
My teenage self explodes in due to some temporal feedback loop...
On Mon, Nov 18, 2019 at 12:55 PM Mladen Gogala <gogala.mladen@xxxxxxxxx <mailto:gogala.mladen@xxxxxxxxx>> wrote:
Yes, Tim is right. XML stuff in the database is implemented using
Java. Whatever is horribly slow (multi-media, spatial) is
implemented using JVM in the database.
On 11/18/19 7:12 AM, Tim Hall wrote:
I think he means not applying the Java patches. The combo is a-- Mladen Gogala
Java and a "all the rest patch". You can choose not to apply the
Regarding the "we don't use Java in the database" point, are you
sure about that? Over the years a bunch of functionality has been
implemented using the JVM. Some things subsequently got
incorporated into the kernel. Some didn't. I don't know off the
top of my head, but I remember the early XML stuff
(DBMS_XMLQUERY) and InterMedia used the JVM under the hood. While
it's in there, there is a possibility you are using it.
On Mon, Nov 18, 2019 at 11:17 AM Sayan Malakshinov
<xt.and.r@xxxxxxxxx <mailto:xt.and.r@xxxxxxxxx>> wrote:
Hm, does it require anything else besides critical patch
updates? Or don't you install them at all?
On Mon, Nov 18, 2019 at 1:16 AM Steve Harville
We never install Java in the database because we don't
like doing all those Java security patches.
On Sun, Nov 17, 2019 at 2:33 PM Mark W. Farnham
<mwf@xxxxxxxx <mailto:mwf@xxxxxxxx>> wrote:
I believe that for most of the things that are
frequently done in java, execution of the code on the
client (and significantly not on RDBMS licensed cpu
resource) is fine (if not superior), while the tight
coupling of PL/SQL with the Oracle kernel and the
avoidance of network trips and latency makes PL/SQL a
superior choice for things that could in theory be
done with java stored in the database and executed
there on licensed cpus.
In theory once the human readable syntax is
translated into some sort of pcode, machine code, or
rdbms calls, any source language could in theory be
stored in and executed the same way PL/SQL is.
Storing the source code in the database does avoid
looking for it <wherever> if and when security or
cross dependencies require a program unit to be
recompiled, but that is merely (at least for the
language structures that are compatible) merely
providing the language syntax parser as available to
the RDBMS. Common runtime additional passes after the
language syntax is out of the way is something that
was becoming very effective in the mid 1970s on
timesharing operating systems. With a 7 pass
optimizing PL/I subset G compiler available that was
a superset of Pascal, for example, you could build a
Pascal compiler that generated PL/SQL, which was then
handed to the PL/I compiler.
I’m not holding my breath.
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of
*Sent:* Saturday, November 16, 2019 9:21 AM
*Subject:* Re: JVM in the database
From my experience, JVM in the database gets very
little use. I am not sure why is that, Java is the
new COBOL and everybody is doing applications in
Java. OO programming which is very useful and very
modern, as you can see here:
is mostly done in Java and Python. Just about
everybody is doing Java. However, the Java OO
orientation might be the answer why people don't use
it in the database. When you write a trigger, a
function or a procedure and store it in the database,
you want it to be as streamlined and efficient as
possible. You don't want all that OO chaff that
defines strings, regular expressions or alike. PL/SQL
which is mostly procedural in nature, is far better
suited for DB work than all that OO clutter in Java.
Having said that, I am sure that in the long run,
Java will prevail. Databases on Millennium Falcon
will probably run Java internal procedures, which may
bring into question completing the Kessel run in less
than 12 parsecs. However, at that point I will have
6' of earth on top of me and will not care.
On 11/16/19 2:06 AM, Noveljic Nenad wrote:
For what purposes would you use JVM in the database?
Please consider the environment before printing
Bitte denken Sie an die Umwelt, bevor Sie dieses
This message is intended only for the individual
named. It may contain confidential or privileged
information. If you are not the named addressee
you should in particular not disseminate,
distribute, modify or copy this e-mail. Please
notify the sender immediately by e-mail, if you
have received this message by mistake and delete
it from your system.
Without prejudice to any contractual agreements
between you and us which shall prevail in any
case, we take it as your authorization to
correspond with you by e-mail if you send us
messages by e-mail. However, we reserve the right
not to execute orders and instructions
transmitted by e-mail at any time and without
E-mail transmission may not be secure or
error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or
incomplete. Also processing of incoming e-mails
cannot be guaranteed. All liability of Vontobel
Holding Ltd. and any of its affiliates
(hereinafter collectively referred to as
"Vontobel Group") for any damages resulting from
e-mail use is excluded. You are advised that
urgent and time sensitive messages should not be
sent by e-mail and if verification is required
please request a printed version.
Please note that all e-mail communications to and
from the Vontobel Group are subject to electronic
storage and review by Vontobel Group. Unless
stated to the contrary and without prejudice to
any contractual agreements between you and
Vontobel Group which shall prevail in any case,
e-mail-communication is for informational
purposes only and is not intended as an offer or
solicitation for the purchase or sale of any
financial instrument or as an official
confirmation of any transaction.
The legal basis for the processing of your
personal data is the legitimate interest to
develop a commercial relationship with you, as
well as your consent to forward you commercial
communications. You can exercise, at any time and
under the terms established under current
regulation, your rights. If you prefer not to
receive any further communications, please
contact your client relationship manager if you
are a client of Vontobel Group or notify the
sender. Please note for an exact reference to the
affected group entity the corporate e-mail
signature. For further information about data
privacy at Vontobel Group please consult
Tel: (347) 321-1217
-- Best regards,
Oracle performance tuning engineer
Oracle ACE Associate
Tel: (347) 321-1217