SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Oracle Corporation (ORCL) -- Ignore unavailable to you. Want to Upgrade?


To: Hardly B. Solipsist who wrote (10828)5/26/1999 6:06:00 PM
From: MikeM54321  Read Replies (1) | Respond to of 19080
 
Hardly,
Thanks. Great response.

I understand 8i is another version of the RDBMS, but I didn't make myself too clear in my post. The Java version of Oracle8, "purpose," was confusing to me. Now it's a little more clear after reading your comments.

Can you tell me who is the target for 8i? Is it for enterprise customers to deploy over their Intranet? Or will it be purchased by customers for them to deploy database information, via a browser on an Extranet? I still don't quite get who the target is for the 8i product. Maybe it's something that can't be answered until they start selling a lot of product?

I knew that IBM was devoting tremendous resources to a Java project, but really didn't know what they were doing. To tell you the truth, we hear so very little about it, I thought they may have dropped it. And this kind of has me concerned about Java's future. But apparently they are still working on it? I wonder why IBM keeps it so under wraps. Seems like they would promote the heck out of it to keep the Java furor alive.

You also addressed another concern I had. That is speed. You say JDBC access is much faster if you are "inside." I believe I understand what you are saying. But say once the JDBC does it's thing, and you are on the LAN(not even considering the Internet) with a browser. You hit the database, then you want results. But don't you still run into that same old snag of having the Java applet being sent down the pipe to do the processing. It's not only slow, but tends to crash the browser. And each time you have to re-access the database, the JDBC on the big iron maybe doing great, but it still has to spit the results down to a client's browser for processing, right?

I know the crashing problem can be eventually solved, but what about the speed, back and forth, down the pipe? How is this ever going to be worked around? Or is this the $64,000 question?<G>
MikeM(From Florida)



To: Hardly B. Solipsist who wrote (10828)5/26/1999 6:15:00 PM
From: WTSherman  Read Replies (2) | Respond to of 19080
 
<The purported advantage of this is that JDBC access is much
faster if you are "inside", and there is the opportunity to use all
of the RDBMS infrastructure to make the Java engine scale to thousands
of simultaneous users. From what I can tell from remarks of people
I know that have used the product, Oracle has done a pretty good job
with this part. (Certainly a lot better than you can do with the JDK.)

Java is not just a language to write annoying applets that crash your
browser -- it is gaining real momentum as a language to write large
enterprise applications<


The real risk for ORCL is that customers will actually use these JAVA elements, only to find out that the performance is terrible and that ORCL has led them down the wrong path.

Personally, I think this is a major risk. Java is not ready for enterprise application deployment and anybody who thinks it is hasn't tried to develop applications with Java and actually seen how they perform.

It's very easy to make them look good in demo's and in a vendor's lab. Its a much different thing in the real world of customer environments and applications.