Oracle and Sun Team Up to Provide .NET Alternative 335
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."
Re:As a sysadmin... (Score:2, Informative)
Re:As a sysadmin... (Score:2, Informative)
Re:That's funny... (Score:2, Informative)
Re:That's funny... (Score:3, Informative)
Re:That's funny... (Score:2, Informative)
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.
Re:Isn't this what EJB was supposed to be (Score:2, Informative)
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
SAP, not .NET (Score:2, Informative)
Read the source (article), Luke!
According to the article linked to by arsdigita [techtarget.com], 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.
Re:Pricing... (Score:5, Informative)
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
It's the developers! (Re:As a sysadmin... ) (Score:5, Informative)
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.
Re:fix java or give it up to the community (Score:2, Informative)
War files are intended to be independent: that's what they're for. They are meant to be a drop-in web application piece.
Fair enough. They are indeed complicated. I happen to believe that their raison d'etre, preventing App-A from redefining classes used by App-B, is a good thing. But you're right. It can be extremely difficult to wrap your head around.
Nah, I'd prefer they standardized the native interfaces on something like GCJ's CNI [gnu.org]. But we're in total agreement that JNI is not sufficient.
Can you be more specific? I think I know what you are intending, but I don't think it's a good idea. Principle of charity, I'll assume that I'm misunderstanding what you intend. Can you be more specific as to what you're intending here?
Just extend from RuntimeException. Problem solved. Checked exceptions are good if and only if the calling code can actually do something about the situation. If that's not the case, extending from RuntimeException will give you the fast track out that you are looking for.
Just don't overdo it.
Not redundant at all. J2EE/EJB components work from interface definitions, not the bean code itself. Without this, you are calling the implementation code directly. Probably not the end of the world in most cases, but a distinct and non-redundant case nonetheless.
Now you're talking app server (Tomcat, right?) configuration. This is hardly the fault of the language, the VM, or the spec.
Just like capitalism, it's the worst choice. Well, except for all the others.
You really should take a look at the EJB 3.0 spec. It really is a lot nicer.
Re:Pricing... (Score:4, Informative)
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.
Re:fix java or give it up to the community (Score:1, Informative)
i'm also sick of J2EE containers with class loaders schemes that are more complicated than my senior year algebraic structures course.
They do what they're supposed to: allow you to deploy/undeploy independant apps on your appserver without a hitch. And they do that well. The problems are:
build a linker into java just like
Well, on unix you just wrap it in a shell script anyway. On mac you wrap gui apps in a bundle. So that's pretty much a windows-only problem. But you can buy commercial ones
then get rid of checked exceptions so i don't have to do try/catch/wrap/rethrows(or do nothing) in 90% of my J2EE code.
NO f*cking way. I like my checked exceptions the way they are.
I like that if joe blow decides he needs to throw another exception, javac will tell me.
I like that it strongly encourages people to deal will error conditions instead of waiting for something to die later - or at least log something.
I like the way eclipse can generate all the boiler plate code for me anyway.
I like that I don't have to dig in the doc to know what can go wrong with a method.
Granted it's a bit of a pain, but we're not writing 50 lines shell scripts here.
And if one guy here thought about starting throwing RuntimeException, or it lesser cousin, some generic superclass, he'd better have earplugs.
then get rid of stateful, local session beans - how redudant is that???
Don't need them? Don't use them! Usually the problem is not that J2EE is badly designed (although there ARE issues), but that devs, more often than not pushed by management and so-called "architects" or "designers" start making everything an EJB.
then find a way to get rid of the 14 million defines i need in my server.xml to specify which implementation of each 'open, standard' interface i need
No argument there
so, java as a language - it's ok java as a platform - SUCKS!
It doesn't. What sucks it the way, willingly or not, people sometimes use it.