Re: JVM in the database

A use case is when you want to list the content of an oracle directory. I think when you need to do some things at OS level, java is the best choice. Because java is platform-independent.

regards
Ahmed Fikri

Am Mi., 11. Dez. 2019 um 16:06 Uhr schrieb Sayan Malakshinov < xt.and.r_at_gmail.com>:

> Hi Tim,
>
> Thanks for mentioning about OS commands, I've just remembered that i use
> internal Java to execute them with timeout parameter:
> https://github.com/xtender/xt_shell
>
> ср, 11 дек. 2019 г., 17:51 Tim Hall <tim_at_oracle-base.com>:
>
>> Hi.
>>
>> I suspect a lot of this comes down to one of the following:
>>
>> - The functionality didn't exist outside of Java at the time the solution
>> was first required, and people have stuck with it.
>> - The Java version was faster at the time, for the specific use case.
>> - Familiarity. Someone can find an easy example in Java, so they just go
>> with it.
>> - PL/SQL feels static, when the world is moving.
>>
>> Examples:
>>
>> When I first started using Java Stored Procedures for BLOB exports there
>> was no alternative. The file handling stuff I wrote in Java was because
>> UTL_FILE couldn't do it. Even when more functionality was added, there are
>> still things that are a pain in PL/SQL, like listing the files in
>> directories. I know these can be done with the scheduler or external
>> tables, but it's a pain compared to using Java. Running OS commands from
>> PL/SQL was another use case. You can now used the scheduler, but for a long
>> time you couldn't, and I would still say they are more painful.
>>
>> In one job we used UUIDs for the primary key in a bunch of tables. The
>> Java UUID generator was faster than SYS_GUID() at the time. Not sure if
>> that is still the case. We had some other maths stuff that was faster in
>> Java, but natively compiled PL/SQL was comparable, so we went that route.
>>
>> Cheers
>>
>> Tim...
>>
>

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