Re: JVM in the database

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
>
>

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