Re: JVM in the database

  • From: Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • To: Tim Hall <tim@xxxxxxxxxxxxxxx>, Sayan Malakshinov <xt.and.r@xxxxxxxxx>
  • Date: Mon, 18 Nov 2019 07:55:17 -0500

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



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.


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


            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,




                Please consider the environment before printing this

                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

            Mladen Gogala

            Database Consultant

            Tel: (347) 321-1217

-- Best regards,
    Sayan Malakshinov
    Oracle performance tuning engineer
    Oracle ACE Associate

Mladen Gogala
Database Consultant
Tel: (347) 321-1217

Other related posts: