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