Vembu has released PL2JSQL 1.0, a PL/SQL to Java migration tool which takes Oracle PL/SQL Packages, Procedures, Functions and Triggers and converts them into Java code that can be deployed in a standalone or any J2EE environment with EJB wrappers for the Java based Business-Logic code.

The PL2JSQL product implements most of the PL/SQL in-built functions as Java APIs. The converted Java code is completely standards based with direct calls to JDBC API and does not involve any intermediate proprietary API.

Check out Vembu PL2JSQL 1.0.

Wow, maybe Vembu can make a EJB 1.1 to EJB 2.0 migration tool as well...

Wow! I would be interested in migration of EJB to Servlet architecture and vice-versa...

Out of curiosity I download and tested the tool against one of my PL/SQL packages. It doesn't even understand the EXTEND method of a SQL collection object!

I also question the benefit of this tool. Who is converting their PL/SQL code to JDBC or SQLJ in the real world today? I haven't heard many, if any, people doing that. Also, how will the performance of the converted code be compared to PL/SQL?

<Eric Ma> Out of curiosity I download and tested the tool against one of my PL/SQL packages. It doesn't even understand the EXTEND method of a SQL collection object!
</Eric Ma>

Sorry to hear about your problem. We have tried to support most of the features used in Oracle 8i PL/SQL.
But we have left out some features like Nested Tables and VARRAY in COllections. If I am not mistaken EXTEND
is used as part of the above two COllection types. We will surely support this in the near future. We had tested the product with about 100,000 lines of PL/SQL code and we also had couple of Beta customers. The PL/SQL Parser itself is tested with Millions of lines of PL/SQ code in the context of our other product which does PL/SQL to Transact-SQL conversion. This product is going to be released soon.


<Eric Ma>I also question the benefit of this tool. Who is converting their PL/SQL code to JDBC or SQLJ in the real world today? I haven't heard many, if any, people doing that. Also, how will the performance of the converted code be compared to PL/SQL?
</Eric Ma>

You may well be right in your assesment. But that is the risk we take. With a conversion tool, and the productivity benefits offered by Java and the ability to move to a multi-tier architecture etc. will some people attempt it is the question. My guess is, there will be at least enough people around to try this out. We do not expect this market to grow to US$ 100s of million. But our hope is it could be a US $ 10 to 20 million market and we could be an important niche player. At least the download we are getting and the 10 or so pricing request we got in a day after this news posting gives us some confidence. With regard to performance, there will be a tradeof if you run the converted Java from the middle layer. But with databases offering the ability to run Java based stored procedures, soon Java could become a language of choice to build stored procedures too. In that case the performance penalty may not be that significant. Even Microsoft has announced that they will support C# inside SQL-Server. That may point to a trend where people want one language for their client, middle-layer and the database.

Thanks
John

from what I understand, does this mean we may not need the EJB-QL,
 but can use straight SQL using SwisSQL Wraper API ???

I want to know how efficient is this generated sql. Has anyone tried using it.
Do they involve trigger conversions ??
There are many questions, but it does raise the eyebrow !!

<Praveen Balakrishnan>
from what I understand, does this mean we may not need the EJB-QL,
but can use straight SQL using SwisSQL Wraper API ???
</Praveen Balakrishnan>

Yes, you are right with our SwisSQL product embedeed in your J2EE application you can just use plain SQL and use features and in-built functions offered by any vendor (Oracle, SQL-Server, DB2, Informix, MySQL, PortgreSQL). SwisSQL will internally do the translation of SQL to the target database. Basically your J2EE application becomes portable acorss databases even if you used proprietary SQL features of a particular database. No need to learn another query language like EJB-QL. We have couple of customers already using our SwisSQL product. They embed it in their J2EE application. The benefits are immense especially for ISVs. You use the power of SQL without worrying about portability.

With regard to Trigger conversion in PL/SQL we have converted it with some limitations currently. We will fix these in a couple of months in our 1.1

Thanks
John
Vembu Technologies
www.vembu.com

I tested the product and I am furious!

On the site: http://www.vembu.com/pl2jsql.html, the editor affirms in the section Features and Benefits:

+++ Standards based, No proprietary APIs :-) :-) :-) :-)

However by testing conversion and by checking the documentation of the product one can read:

+++ Each generated java spin will importation PL2JSQL runtime library: lib/PL2JSQLruntime.jar :-( :-( :-( :-(

<carpediem98 carpediem98>
Each generated java spin will importation PL2JSQL runtime library: lib/PL2JSQLruntime.jar
</carpediem98 carpediem98>

Sorry about the confusion. Actually the runtime jar is an implementation of PL/SQL functions like String Functions (TRIM, TO_CHAR), System Functions , Date Functions etc. etc. We have to implement the Oracle PL/SQL functions in Java inorder to correctly execute the Converted Java procedures.

What we meant by no proprietary API is that we do not have any wrapper on top of JDBC. That is the converted Java code directly uses the JDBC API like Connections, Resultset, etc. etc.

Sorry if our documentation is misleading.

Thanks
John
Vembu Technologies
www.vembu.com

If you have an Oracle based product, using stored procedures and triggers heavily and you want to develop your application into a database-independent, J2EE application running the business logic in the middleware.

Using converter software like this you may stand a chance to do the conversion of the backend in a relatively short time period.

With the extensive use of J2EE and EJBs you don't need such an expensive and complex database like Oracle. Why wouldn't you replace them with cheaper, possibly open-source/free alternatives (e.g. PostgreSQL/MySQL, JBoss ...etc). You will be able to sell your application cheaper since the infrastructure software costs less.

I m also not sure how and why will someone need it. And reliable can it be. Can u rely on this tool to convert 100,000 lines of PL SQL code. How much of QA effort will be needed to make sure it didnt screw up anything.
But i guess from your response above, you may have some people interested in it. All the best - I will keep an eye one it to see where this stands 6 months from now.