From pierce@hogranch.com Mon Jul 6 19:51:43 2026 From: John R Pierce Message-ID: <568D9AD2.6000402@hogranch.com> Date: Wed, 6 Jan 2016 14:53:06 -0800 MIME-Version: 1.0 Subject: [Pljava-dev] huh... Content-Type: multipart/mixed; boundary="===============4314296135619427148==" This is a multi-part message in MIME format. --===============4314296135619427148== Content-Type: multipart/alternative; boundary="------------040705080009070802050706" This is a multi-part message in MIME format. --------------040705080009070802050706 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 * ..... 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 --------------040705080009070802050706 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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:

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
--------------040705080009070802050706-- --===============4314296135619427148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev --===============4314296135619427148==-- From pierce@hogranch.com Mon Jul 6 19:51:43 2026 References: <568D9AD2.6000402@hogranch.com> From: John R Pierce Message-ID: <568D9D41.5010807@hogranch.com> Date: Wed, 6 Jan 2016 15:03:29 -0800 MIME-Version: 1.0 In-Reply-To: <568D9AD2.6000402@hogranch.com> Subject: Re: [Pljava-dev] huh... Content-Type: multipart/mixed; boundary="===============0121892592865363325==" This is a multi-part message in MIME format. --===============0121892592865363325== Content-Type: multipart/alternative; boundary="------------000402010900080007050209" This is a multi-part message in MIME format. --------------000402010900080007050209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------000402010900080007050209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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



--------------000402010900080007050209-- --===============0121892592865363325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev --===============0121892592865363325==-- From pierce@hogranch.com Mon Jul 6 19:51:43 2026 References: <568D9AD2.6000402@hogranch.com> <568D9D41.5010807@hogranch.com> From: John R Pierce Message-ID: <568D9F06.70107@hogranch.com> Date: Wed, 6 Jan 2016 15:11:02 -0800 MIME-Version: 1.0 In-Reply-To: <568D9D41.5010807@hogranch.com> Subject: Re: [Pljava-dev] huh... Content-Type: multipart/mixed; boundary="===============6438369687513844764==" This is a multi-part message in MIME format. --===============6438369687513844764== Content-Type: multipart/alternative; boundary="------------090005070504000902010108" This is a multi-part message in MIME format. --------------090005070504000902010108 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. -- john r pierce, recycling bits in santa cruz --------------090005070504000902010108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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
--------------090005070504000902010108-- --===============6438369687513844764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev --===============6438369687513844764==-- From chap@anastigmatix.net Mon Jul 6 19:51:43 2026 Message-ID: <568DA841.3060509@anastigmatix.net> Date: Wed, 06 Jan 2016 18:50:25 -0500 From: Chapman Flack MIME-Version: 1.0 References: <568D9AD2.6000402@hogranch.com> <568D9D41.5010807@hogranch.com> <568D9F06.70107@hogranch.com> In-Reply-To: <568D9F06.70107@hogranch.com> Subject: Re: [Pljava-dev] huh... Content-Type: text/plain; charset="us-ascii" 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@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev From chap@anastigmatix.net Mon Jul 6 19:51:43 2026 Message-ID: <568DAB54.5070007@anastigmatix.net> Date: Wed, 06 Jan 2016 19:03:32 -0500 From: Chapman Flack MIME-Version: 1.0 References: <568D9AD2.6000402@hogranch.com> <568D9D41.5010807@hogranch.com> <568D9F06.70107@hogranch.com> <568DA841.3060509@anastigmatix.net> In-Reply-To: <568DA841.3060509@anastigmatix.net> Subject: Re: [Pljava-dev] huh... Content-Type: text/plain; charset="us-ascii" 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@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev