Re: JVM in the database

the holy graal?

Am 18.11.2019 um 15:21 schrieb Tim Hall:
> Now interestingly, imagine the following scenario...
>
> The Multilingual Engine based on Graal goes live, allowing Javascript
> stored procedures and then other languages like Python etc.
> 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...
>
> Cheers
>
> Tim...
>
> On Mon, Nov 18, 2019 at 12:55 PM Mladen Gogala
> <gogala.mladen_at_gmail.com <mailto:gogala.mladen_at_gmail.com>> 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.
>
> Regards
>
> On 11/18/19 7:12 AM, Tim Hall wrote:
>> I think he means not applying the Java patches. The combo is a
>> Java and a "all the rest patch". You can choose not to apply the
>> Java one.
>>
>> 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.
>>
>> Cheers
>>
>> Tim...
>>
>> On Mon, Nov 18, 2019 at 11:17 AM Sayan Malakshinov
>> <xt.and.r_at_gmail.com <mailto:xt.and.r_at_gmail.com>> wrote:
>>
>> 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 <mailto: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 <mailto: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>
>> [mailto: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
>> <mailto: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 <https://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
>>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>

-- 





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