Java Database Connectivity (JDBC)

I would like to add my voice of concern to Jon's. SQLJ is a VERY significant part of our software development. Is sqlj going away? Is it going to be continued within OTN, but outside the product release?

SQLJ provides several benefits, but perhaps the most significant to us in terms of software developement is the compile time checking of sql statements. How could we do that with pure jdbc? I do not see a clean migration path.

Indeed, I would love some enlightening!

We are also using extensively SQLJ, because we use the Java Wrapper Class generation utility provided by JDeveloper 9.0.3.

We put a lot of bussiness process in the PL/SQL packages this way. This utility allows us to simplify our application design.

We would only need to create wrappers for our PL/SQL packages, and we do not mind if the final result is "Pure JDBC".

Do you guys have any idea if Oracle is substituting this Java Wrapper generation for PL/SQL with other product wrapper generator?

Gentlemen:

Information I have received from 'unnamed' Oracle sources.

1) Oracle was the only vendor to implement SQLJ, and Oracle was NOT successful in getting SQLJ implemented as a standard, thus they are 'taking their ball and going home' and dropping all support.

2) I have NO info on the intent of Oracle with JPUB, but if it is to be maintained, then it must generate the JDBC code.

Good Luck

You are incorrect that Oracle was the only vendor to implement SQLJ. IBM's DB2 supports SQLJ as well. In fact, IBM Websphere Studio 5.1 now provides a native SQLJ editor and debugger.

I was told by Oracle that sqlj is being desupported because it has not been adopted to any great extent. I am curious how many of us are using sqlj, and if we are more than just a handful, I wonder what would happen if all of us posted our comments on this thread. Would Oracle reconsider?

Wishful thinking I guess....

What options do we have if we need to replace sqlj? Any thoughts?

Java pre-processors, like the SQLJ translator, have always been problematic because IDEs have not done a good job supporting them. The advent of JSP editing and debugging in IDEs has started to change all that. The tooling in IDEs required to support JSPs is very similar to that required to support SQLJ. I was starting to believe that SQLJ's time has come. Oracle has always been a strong supporter. IBM is now getting on the bandwagon. With the next release of SQL Server looming on the horizon which promises to support C# in the database, I would think Oracle, IBM, and others would invest even more effort to enhance Java and SQLJ in the database. I'm hoping you are wrong on this one.

I am the SQLJ product manager; it is true that the primary motivation for this desupport is our feeling that there is not so much matket traction. Maybe our sources (support TARs, OTN download) are not accurate and maybe there are more SQLJ users than we thought.

In this respect, it will help if anyone using SQLJ can drop me an email (kuassi.mensah@oracle.com) with the following information:
- since when are you using SQLJ, overall happy/unhappy?
- how many SQLJ applications in deployment
, potential future applications
- client-side or server-side (stored procedures) deployment
- impact of desupport
- other
thanks, Kuassi

I have began using SQLJ. It is very good. I am in the
process of converting all of my JDBC programs to SQLJ/JDBC combination. The result is much simpler code and more powerful.

Please continue to support it.

Thanks,

Ben

Also, Informix and IBM (Informix buyer) still support
SQLJ.

Ben

Read the following two recent articles to see that IBM is actively pushing SQLJ.

http://www7b.boulder.ibm.com/dmdd/library/techarticle/0302tsui/0302tsui.html

http://www7b.boulder.ibm.com/dmdd/library/techarticle/0202campbell/0202campbell.html

"IBM will be pushing for SQLJ to be included in the J2EE platform and the
JDK. SQLJ parallels the JDBC model and covers all the basic functionality ..."


I hope that Oracle continues to support SQLJ.

Ben

I applaud Oracle - it is a strong decision.
Do not warry, who are used SQLJ - you can use a old libraries. I suggest to rewrote an application in an idle time to JDBC - your applications will be ~5 times faster.
The complexity of JDBC statements is the same.

I sympathize with you all because it really stinks to lose support for some tool that you really like. However, I don't use SQLJ myself because I don't find JDBC all that difficult, the number of lines of code between SQLJ and pure JDBC are roughly equivelant, and with pure JDBC I don't have to maintain 2 source files for my code. (.java and .sqlj) Personally, I don't like the idea of a precompiler mangling my code... I'm one of those strange people that are picky about tabs, spacing, and other such nonsense.

Anyway, hopefully, Oracle will continue to support this product since it is an extremely valuable tool for a large number of developers.

If your apps ever deal with many long SQLs (half a page or a page long), then if you don't have sqlj, then you
have to do something like:

String sql;
sql = "select table1.id, table1.address1," +
"table1.address3 + .........."
... 20 lines go here ... +
"order by ....";


res = stmt.executeQuery (sql);

Then, go through each field, to retrieve it.


Compare the above approach with the SQLJ approach, you
will see which one is better. I suggest all skeptics
to read SQLJ tutorials and you will see why SQLJ has
its place and why IBM is pushing SQLJ to be part of J2EE.

Ben

I am not a SQLJ user either but have years of
embedded SQL in C/C++ as well as other 3rd GL stuff

SQLJ has the advantage of compile time checking
for syntax and I think (at least for IBM) it also
has precompiled execution plan also.

But for us folks who have to write cross-DB platform
applications, SQLJ just isn't applicable.
The other neg. thing about SQLJ is that there are no
decent debugger for it.?

As for embedding 20 lines of SQL in java code, I think
it's prob. bad practice anyway. That should be resource
driven or converted into SP.

As for IBM, i think they are pushing it hard b/c there
are millions of coders out there on IBM platforms
(you name it: COBOL, PLI, RPG, FORTRAN, C/C++ on OS/2,AIX
talking to DB2 or IMS... all supporting embedded SQL)
already familiar with the embedded SQL concept and
it makes sense strategically for them to push
the technology.

As for the merit of SQLJ vs. JDBC, I think they serve
different purpose as well as market.

I wasn't trying to start a SQLJ/JDBC war, so I probably should have just kept my mouth shut. I'm a little jaded when it comes to the Pro*C/C++ compiler, so I really didn't like SQLJ when we tried it. We have had many many issues with Pro*C/C++ in the past that consisted of perfectly valid SQL statements not compiling, problems with versioning mismatches between the SQL and PL/SQL parsers, not to mention the strange requirements to make it work with C++. Anyway, if it works for you and you like using it great. I hope it stays around for a very long time.

Kuassi Mensah,

Currently we are using SQLJ. But maybe considering updating our persistence layer using Object-Relational persistence technologies such as EJB, JDO or the like. But it would be good if Oracle continues the support for SQLJ for newer JDKs such as JDK 1.4.x and above, at least we can continuely upgrading to new JDK versions, and this would give us more time for migrating all of our persistent lay to other persistence technology.

As for the questions requested earlier:
- since when are you using SQLJ, overall happy/unhappy?

Our project started using SQLJ about 4+ years ago, back in 1999. Advantage: Fewer coding to do, compile time check. Disadvantage: Not accepting dynamic SQL stmt changes. Not supported by other IDE. JDeveloper 3.1 nor 9i does complete compilation correctly from scratch, we had to create ANT tasks to build the whole project first, then let JDeveloper handle partial/complete compilation.


- how many SQLJ applications in deployment
, potential future applications

Currently one application for our project. I personally prefers ORM technologies or other persistence technology for future application, because it seems like Oracle DBMS 9i+ does pretty good SQL Statement optimizations, or at least it's faster compared to Oracle 8i, the explain plan for Oracle 9i seems to be optimized automatically therefore we don't have to give hints or other manual optimizations. This is one reason why I prefer using ORM technologies, the maintenance is easier. Do you agree?


- client-side or server-side (stored procedures) deployment

We have server-side stored procedures. Some components uses stored procedure heavily, while other components use fewer or none.


- impact of desupport

We may have to consider different persistence technology. We'll need to spend more time for migration. Older SQLJ doesn't seem to be compatible with JDK 1.4+ (We'll need to investigate further), if not compatible, then we cannot upgrade to newer version JDK.



Thanks,
Benjamin Chi

Kuassi Mensah,

Currently we are using SQLJ. But maybe considering updating our persistence layer using Object-Relational persistence technologies such as EJB, JDO or the like. But it would be good if Oracle continues the support for SQLJ for newer JDKs such as JDK 1.4.x and above, at least we can continuely upgrading to new JDK versions, and this would give us more time for migrating all of our persistent lay to other persistence technology.

As for the questions requested earlier:
- since when are you using SQLJ, overall happy/unhappy?

Our project started using SQLJ about 4+ years ago, back in 1999. Advantage: Fewer coding to do, compile time check. Disadvantage: Not accepting dynamic SQL stmt changes. Not supported by other IDE. JDeveloper 3.1 nor 9i does complete compilation correctly from scratch, we had to create ANT tasks to build the whole project first, then let JDeveloper handle partial/complete compilation.


- how many SQLJ applications in deployment
, potential future applications

Currently one application for our project. I personally prefers ORM technologies or other persistence technology for future application, because it seems like Oracle DBMS 9i+ does pretty good SQL Statement optimizations, or at least it's faster compared to Oracle 8i, the explain plan for Oracle 9i seems to be optimized automatically therefore we don't have to give hints or other manual optimizations. This is one reason why I prefer using ORM technologies, the maintenance is easier. Do you agree?


- client-side or server-side (stored procedures) deployment

We have server-side stored procedures. Some components uses stored procedure heavily, while other components use fewer or none.


- impact of desupport

We may have to consider different persistence technology. We'll need to spend more time for migration. Older SQLJ doesn't seem to be compatible with JDK 1.4+ (We'll need to investigate further), if not compatible, then we cannot upgrade to newer version JDK.



Thanks,
Benjamin Chi

Our group recently migrated several applications away from Oracle Forms. While most of the applications were migrated to C/C++/Pro*C I fought hard to move the application I was responsible for to Java/SQLJ.
SQLJ was one of the selling points to our manager since it would shorten our development schedule. Most of our developers were comfortable with Pro*C and SQLJ allowed a smooth transition to Java.
As far as IDE integration is concerned we use Ant to build which allows us to avoid being trapped by any IDE.
The decision to use SQLJ was made back in June and now I wish I had seen this forum and the desupport notice before starting to use SQLJ.
I think SQLJ is a needed and integral tool for development on any database centric application.

OK.
That means, if one wants to continue to use sqlj, the only possible option is IBM sqlj.
Does anyknow know if IBM sqlj supports the Java language features new to 1.4 and 1.5
- assert
- generics
- enhanced for loop
- ...
I browsed the IBM pages to find definitive information on that, but didn't find any.
Thanks

Starting with Oracle Database 10g release 10.1.0.4, SQLJ is resupported.