Re: [Pljava-dev] huh...

was perusing the oracle document on their 12.1 release, deprecated
features. found this gem.

8.1.17 Changes for Oracle JDBC and SQLJ

In Oracle Database 12c, some features are deprecated or desupported that
affect JDBC, UCP, SQLJ, JPublisher, and Java in the Database (Oracle
JVM). The JDBC Javadoc also contains a page for all the deprecated APIs.

The following features are deprecated or desupported in this release for
Oracle JDBC and SQLJ:

*

Deprecation of SQLJ Inside the Server
<https://docs.oracle.com/database/121/UPGRD/deprecated.htm#BABCGBBE>

* .....

8.1.17.1 Deprecation of SQLJ Inside the Server

SQLJ usage inside the database server is deprecated in this release. The
capability of translating and running SQLJ applications inside the
database will not be available in later releases. SQLJ can only be used
as a client tool to translate the applications that can connect to
Oracle Database and run as a client. SQLJ cannot be used inside stored
procedures, functions, or triggers.

um, isn't SQLJ their version of pljava ?

--
john r pierce, recycling bits in santa cruz

On 1/6/2016 2:53 PM, John R Pierce wrote:
> was perusing the oracle document on their 12.1 release, deprecated
> features. found this gem.

oops, forgot the link to the document.
https://docs.oracle.com/database/121/UPGRD/deprecated.htm#UPGRD60127

On 1/6/2016 3:03 PM, John R Pierce wrote:
> On 1/6/2016 2:53 PM, John R Pierce wrote:
>> was perusing the oracle document on their 12.1 release, deprecated
>> features. found this gem.
>
>
> oops, forgot the link to the document.
> https://docs.oracle.com/database/121/UPGRD/deprecated.htm#UPGRD60127

and doing some more reading and googling and it struck me, they aren't
talking about PLJAVA style java inside the database, rather they are
talking about SQL inside of a Java app, whether its in the database or
external. EG, instead of JDBC class methods, SQLJ was a preprocessor,
similar to Pro*C/ECPG.

so, we can ignore this whole discussion before it gets started. <crickets>

--
john r pierce, recycling bits in santa cruz

On 01/06/16 18:11, John R Pierce wrote:

> EG, instead of JDBC class methods, SQLJ was a preprocessor, similar to
> Pro*C/ECPG.

Exactly. Kind of a cool idea, they've got some sample app code up
on oracle.com, and there's an old tutorial on the wayback machine:

https://docs.oracle.com/cd/A91202_01/901_doc/java.901/a90212/sampapps.htm#1005043

http://web.archive.org/web/20030530081254/http://www.sqlj.org/tutorials/sqlj-sigmod/index.htm

They made a reference implementation way back in 1998, based on a
parser for Java 1.1, and they released it public-domain to encourage
adoption by multiple vendors, which did in fact happen:

http://web.archive.org/web/20030621161812/http://www.sqlj.org/implement.htm

It included a Java preprocessor, which would translate your program to
an equivalent one that depended on a runtime library (classes in
the sqlj.runtime package, which are also in the reference implementation).
For code that was released public domain, it's remarkably scarce on the net,
but I did find a tarball back in November.

The sqlj.runtime package could be implemented on top of jdbc, in which
case you could run your translated program as a remote client, or it
could be implemented in the server and you could run your code there.

There were three pieces in total: "SQLJ part 0" was the preprocessed,
embedded SQL/Java, which became ISO/IEC 9075-10 Object Language Bindings
(SQL/OLB).

"SQLJ part 1" was "Java methods as SQL procedures" and "SQLJ part 2"
was "Java classes as SQL types", and both of those pieces got combined
as ISO/IEC 9075-13 Java Routines and Types (SQL/JRT) which is what
PL/Java (partially) implements. SQL/OLB and SQL/JRT are pretty cleanly
separated parts of the SQL standard, except there is a couple obscure
mentions of the sqlj.runtime package in the text for SQL/JRT. For
example, a method returning setof composite type would be allowed to
return an sqlj.runtime.ResultSetIterator, and in addition to the
Java property sqlj.defaultconnection defined to "jdbc:default:connection"
(which PL/Java does supply), there is also supposed to be a property
sqlj.runtime giving the name of a class implementing
sqlj.runtime.RuntimeContext. That appears in SQL/JRT with no explanation
whatever and was baffling until I dug up the SQL/OLB info.

So the term SQLJ has referred both to things PL/Java is and things
PL/Java isn't, and it's not completely obvious how to read that
Oracle announcement, but the way I am reading it is that they will
drop the support for preprocessed "SQLJ part 0" programs server-side,
but will still allow you to use them over JDBC, and they probably
aren't dropping support for part 1&2, SQL/JRT, PL/Java-like stuff.

-Chap
_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

On 01/06/16 18:50, Chapman Flack wrote:

> So the term SQLJ has referred both to things PL/Java is and things
> PL/Java isn't, and it's not completely obvious how to read that
> Oracle announcement, but the way I am reading it is that they will
> drop the support for preprocessed "SQLJ part 0" programs server-side,
> but will still allow you to use them over JDBC, and they probably
> aren't dropping support for part 1&2, SQL/JRT, PL/Java-like stuff.

I looked at some current Oracle docs online and it seems pretty clear
that when they say SQLJ they mean the preprocessed embedding; all the
rest they just call "Java in Oracle Database".

-Chap
_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev