Re: JVM in the database

Hi Steve,

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 <steve.harville_at_gmail.com> wrote:

> 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_at_rsiz.com> 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.
>>
>>
>>
>> mwf
>>
>>
>>
>> *From:* oracle-l-bounce_at_freelists.org [mailto:
>> oracle-l-bounce_at_freelists.org] *On Behalf Of *Mladen Gogala
>> *Sent:* Saturday, November 16, 2019 9:21 AM
>> *To:* oracle-l_at_freelists.org
>> *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:
>>
>>
>>
>>
>> https://cacm.acm.org/careers/238279-object-oriented-programmingthe-trillion-dollar-disaster/fulltext
>>
>>
>>
>> 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?
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Nenad
>>
>>
>>
>> https://nenadnoveljic.com/blog/
>>
>>
>>
>> ____________________________________________________
>>
>> Please consider the environment before printing this e-mail.
>>
>> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>>
>>
>> Important Notice
>>
>> 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 further explanation.
>> 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
>> www.vontobel.com.
>>
>> --
>>
>> Mladen Gogala
>>
>> Database Consultant
>>
>> Tel: (347) 321-1217
>>
>>

-- 
Best regards,
Sayan Malakshinov
Oracle performance tuning engineer
Oracle ACE Associate
http://orasql.org

--
http://www.freelists.org/webpage/oracle-l