Re: Oracle and Java. Does Oracle know something some of us don't?

simonlenn_at_yahoo.com (Simon Lenn) writes:

> I agree with Galen.
>
> I do not understand all this fuss about people jumping about Java.
> Look at Oracle's JSQL (Java SQL) it is Oracle proprietary how about
> Oracle OC4J it is proprietary.

I find this amusing as it seems very much to me that the most "jumping" has been done by those who feel java is no good. The vast majority of posts on Java an Oracle have supported Java as an additional tool which can add functionality to PL/SQL and do so with a lot more ease and a lot more portability than using C or C++.  

> Use JSQL and OC4J your dream of running Java on another database is
> just not possible your code is unportable. Apart from Oracle I do not
> know any other vendor support Java based database development not sure
> how well DB2 supports Java stored procedure.

Well, I think some clarification is needed here. If I write java stored procedures then those procedures ARE portable between Oracle databases running on other platforms. If I wrote the same procedures in C or C++, it is very likely they won't be portable between Oracle databases running on other platforms. I think this is the main sort of "portability" that Oracle has been talking about - not portability between different database vendors.

However, having said that, if there were other database vendors who support Java as stored procedures, then it is very possible to write java stored procedures which will be portable - obviously not all procedures would be portable, especially when they use Oracle specific java classes or reference Oracle specific features. However, you can write java stored procedures which do not use Oracle specific classes or if they do, the classes are instances of abstract or interface classes which are part of the core java API. I have written such procedures which not only would work with any database which supports the same java VM version, they can even run outside the database as stand alone classes. This means they are portable to any java virtual machine which supports the same or higher version of java. In fact, I developed and tested these procedures outside the database using Sun's SDK before testing them within the DB.

I think you need to keep in mind there is a big difference between the JVM and the classes provided by a vendor. The JVM is standardised and if it wants to be approved as a true JVM, it must meet this standard. This means that any java writen using the standard java classes will run on that JVM. Oracle has provided additional classes which are not part of the core java API and would not exist in other vendors applications. If your java uses these classes then of course it won't be portable to other systems unless they also provide those classes.

With respect to portability - I think this is an issue which needs to be looked at from multiple dimensions. As has been pointed out in this group, you will never get 100% portability between database vendors unless your code only caters to the lowest common denominator, which of course is rediculous as it eliminates taking advantage of those features which are unique to the vendor's product and which are likely the very features which prompted you to purchase their product in the first place etc. However, I think portability can be considered from many angles. Writing portable code might mean being aware of system differences and designing/implementing your code in such a way that you can maximise the sharing of code, but acknowledge there will be vendor specific parts which can be implemented as drop-in modules. Essentially, I don't feel portability is an absolute - it is a concept which you should keep in mind and one which is probably nice to work towards as far as practicle, but should not necessarily be the main goal. The benefit of Java in such situations is in its ability to reduce the machine architecture issues relating to portability.
>
> Guys whoever thinks Java is the way to go go ahead and use Java
> perhaps in 3 years you will not have a job. I am serious. Look at
> Sun's stock price if Java was something so exotic why is Sun not
> making a cent from Java. They are earning on servers and spending on
> Java and also spending on law suits sueing MS. The only money they are
> making is from the awards they have won from those law suits. If you
> think I am wrong watch next 3 years where Java will be. Already MS is
> offering the C# SDK for free download. I will leave it to time to
> decide future of Java.
>

Yeah right - and how well will the C# SDK work on my Alpha, HP, Sun, Linux and other non-MS Windows platforms?

I've been hearing "use java and you won't have a job in x years" since java first came out. While I would never state java is here forever, I would also never state it will be gone in x years. Plenty of people have thought they could predict the future of this industry and what would be big and wohat would vanish - nearly all of them have been wrong.

I certainly wouldn't argue that because of Sun's poor stock market performance that this indicated the pending death of Java. In fact, I think Java is now bigger than Sun and even if Sun collapsed, Java will continue to exist. Sun is not the only producer of JVMs and there has been enough investment in Java that it would more than likely outlive Sun. By the way, have you been monitoring Oracle's stock performance? following your argument, we had all better give up Oracle and move into SQL Server!

As mentioned above, I am very hesitant to predict the future. However, I think the whole concept of a virtual machine is one which is going to stick with us. Maybe the "hit" language of the future won't be Java, but I think it will be something which uses similar concepts (e.g. abstract virtual machine). Possibly it will be something related to Java in the way VB is related to the original BASIC, possibly it will be something more lisp like - I don't know. However, I do think it will be something which works at an abstraction level above the machine architecture.

Finally, the whole "use x and you won't have a job in x years" type statements are just plain rediculous. We work in an industry which evolves and changes rapidly - essentially you could make this statement about any language if you make the years variable big enough. One of the great and I think rewarding challenges of this industry is that you have to constantly be aquiring new skills - languages are a bit like hem lines - they go up and they go down. The real skills which are important are not being familiar with a specific language syntax and its quirks, but rather having good analytical, diagnostic, design and engineering skills.
>
> Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<uwulgvg7a.fsf_at_standardandpoors.com>...
> > On Sun, 05 Jan 2003, dmz17_at_nospam.nowhere.com wrote:
> > >
> > > To Microsoft, portability means it runs on all versions of
> > > Windows. To Oracle it means it runs on/in every Oracle
> > > Database.
> >
> > Nope, it means it runs on all versions of SQLServer that runs on
> > all version of Windows.
> >
> > Oracle means it runs on all versions of Oracle on all operating
> > systems.
> >
> > There is no database portability just like there is no OS
> > portability. Oracle custom writes its engine for each OS so that
> > any Oracle application is OS independent, but you will never get
> > database independence unless you write custom code for each
> > database.

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!