Re: JVM in the database

  • From: Lothar Flatz <l.flatz@xxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Mon, 18 Nov 2019 15:34:09 +0100

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

    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@xxxxxxxxx <mailto:xt.and.r@xxxxxxxxx>> 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@xxxxxxxxx <mailto:steve.harville@xxxxxxxxx>>
        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@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.

                mwf

                *From:*oracle-l-bounce@xxxxxxxxxxxxx
                <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
                [mailto:oracle-l-bounce@xxxxxxxxxxxxx
                <mailto:oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of
                *Mladen Gogala
                *Sent:* Saturday, November 16, 2019 9:21 AM
                *To:* oracle-l@xxxxxxxxxxxxx
                <mailto:oracle-l@xxxxxxxxxxxxx>
                *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



--




Other related posts: