Slashdot Mirror
Oracle and Sun Team Up to Provide .NET Alternative
segphault writes "Ars Technica has an article about the new partnership between Sun and Oracle, designed to provide an alternative to .NET." From the article: "According to Ellison and McNealy, their mutual goal is the production of a complete Java-centric enterprise datacenter architecture that leverages Solaris 10 and Oracle's Fusion middleware. Designed specifically as an alternative to Microsoft's .NET technology stack, the new platform is competitively priced and based on robust frameworks."
I'd have to 100% disagree with you here. "java has a mind of its own" is an extremely ignorant statement. While the quality of many java applications is below acceptable, critizing the virtual machine and its related frameworks and apis from the perspective of a systems adminstrators is doing nothing but spreading FUD. Java has several advantages that the majority of other technology stacks lack. That advantage is choice. This being said it is a double edged sword. Don't like writing SQL? Use hibernate, toplink, iBatis, torque, OJB, castor or about 20 other functionaly similar technologies. The main problem imho with java is to write an end to end application you have to be proficient in a breadth of technology stacks. With this choice comes responsibility which in many cases leads to failure.
if sign.nil? Sig.new
Sorry, I'm as big a Microsoft fanboy as any, but this is just wrong. .NET and COM are completely different. COM is basically a convention for interoperating between C/C++ programs. .NET is its own virtual machine and set of languages. ODBC may be similar to JDBC, but that has nothing to do with .NET! .NET uses something called ADO.NET, which is nothing at all like ODBC.
Karma: -2147483648 (Mostly affected by integer overflow)
Yeah, you're just plain wrong. A wide selection of apps will run on mac OS/linux.
Same binary code, and as long as you stay within the System namespace you should be fine. True if you use some external dll that pinvokes things (only supplying methods for windows), or you pinvoke things yourself, its not cross platform. However it's generally bad practice to pinvoke things yourself, and many libs that use PInvoke provide cross platform solutions.
No cross platform solution can really be perfect, especially when the platforms are made by seperate organizations.
a bit harsh, probably.
.NET is only now planning to release a persistence framework, after literally thiking about it for 2 years, and it hasn't seemed to affect their market share.
:-)
but, they had this pie in the sky idea that EJB would become an enterprise component model for distributed computing.
Session beans were designed to be kind of a modern day CORBA implementation, in fact using IIOP as their wire level protocol.
Entity beans were designed to be a kind of coarse grained persistent component model.
And for 1999, it was a novell concept.
What people ended up trying to do with them is create web applications.
Entity beans were used, often poorly, as a general OR mapping system, which is a tough way to go.
Session beans were used occasionally for remoting, but mostly for either state tracking or state sharing.
Both Entity and Session beans are almost always used locally, hence their introduction of the Home interface.
EJB as an enterprise component model, where applications achieve this SOA style architecture never happened.
Internally, IBM product devisions agreed on EJB as a communications platforms for integrating their applications. This never happened.
IBM's push for this made the EJB specification process very political.
For example, IIOP was pushed as the wire level protocol so it would support legacy C++ CORBA implementations. However, I don't know of any J2EE application that communicates with a C++ CORBA app over IIOP. I'd love to hear if there are some out there.
I'm not saying I had a better solution at the time, but when it did come out (and I knew several people on the original EJB committee), I felt it would not achieve its goals.
My take on it then was XML on the wire, XML as an IDL, with pluggable transports. Yes, even in 1999, some of use were doing this!
But, this is basically what we see with SOAP/WSDL.
This has turned out to have it's own limiting issues, though.
Personally, I would have provided very minimalist interfaces for a lot of this. Then, I would have allowed someone else to take the arrows.
Heck,
And they took 6 years so far to build WCF (indigo).
In any case, 1 more interesting note.
I had the opportunity once to corner some of the J2EE leads and architects at day long private meeting at Sun.
Their response was basically apologetic, although the architects were really hung up on JDO. Marketing told us that they have devoted 99% of their efforts to Web Services.
Furthermore, we were told that the Java group is being put under the manager who really pushed Solaris to where it is now, and that in time Java/J2EE should being to improve.
I have a lot of interesting Sun/Microsoft stories, actually, but those are for another day
Read the source (article), Luke!
According to the article linked to by arsdigita, this is not about .NET at all, but about SAP. It looks to me like Oracle is actively porting its middleware to Java in order to claim that they are easier to develop for and less proprietary than SAP's counterparts. Sun and Oracle will promote each other's non-competing products as a part of this deal.
For example, VB programmer may with some training be able to move his old VB code's business logic to .NET server.
.NET.
It is not just a matter of training - VB.NET has many differences from VB.
and that way looking far ahead of Java where you can only 'plug in' with Java only.
I really don't know how people come up with statements like this. The facts could not be more different. There are more than 200 different languages than run on the JVM. A large proportion of them integrate well with Java, and can used Java classes and libraries. There are implementations of LISP, Ruby, Python, Basic, Modula, Pascal, Fortran and even COBOL. There are currently far more languages implemented on the JVM than on
I'm in the same boat. I look after everything under the sun. Everything from shitty little 2 server ASP websites to 20 server clusters with TB's of backend disk.
I have java servlets used by over 2000 people 24x7. When was the last time I had to restart the JVM? Dec 2002. I also have 8 java (jsp) web applications used by 200,000 ISP customers 24x7. JVM uptimes range from 2 years to several months. On the flipside, i have applications that need to be restarted every week.
The difference? The developers.
"Of course you can mix and match data structures between these languages.
.net's CLI/CLR allows you to do."
.NET.
.NET is certainly a better platform for some languages in some ways than Java, but to assume there are no problems is false. Have a look at the journal of the developers of SmallScript on this matter - it is illuminating!
Liar... certainly not in the way that
You can use any class or data structure written in one language on the JVM in any other, providing it is a compiled class. There are no restrictions. In OOP languages you can inherit from any other class, no matter what the language the original was written in. Just like
The words "byte code" apparently shot right over your head, just like many of the crappy things about Java.
Why can't we have a polite debate?
The JVM was designed to run Java -- and it shows.
and the CLR was designed to run languages like C#, J# and VB.NET - and it shows! Perhaps you ought to read some of the development blogs of various language implementors.