Slashdot Mirror
James Gosling On .NET And The Anti-Trust Trial
gwernol writes: "There's a short but interesting interview with James Gosling over on ComputerWorld. He talks about the differences between J2EE and .NET and also about the Microsoft anti-trust trial. Some interesting perspectives from the founder of Java."
I read this comparison last November. The author, Dean Wampler, Ph.D., concludes the following:
.NET are most appropriate for large-scale, high availability applications. The documented tests say little about how well these frameworks support those applications.
.NET and Java Pet Stores support the same features, but they implement different "nonfunctional" requirements. The .NET version assumes a single hardware/OS/database combination and makes performance paramount. The Java version supports multiple hardware/OS/database combinations and ranks performance as less important. In fact, both frameworks can support either emphasis. Hence, comparing the two code bases is misleading.
.NET is a well-designed framework with good tools. J2EE provides greater freedom, but the J2EE community can't ignore the need for tools that create powerful and efficient applications in a timely manner."
"The experimental flaws of the Microsoft tests render the performance comparisons unusable. All tests must be run on the same test bed and a more suitable application must be chosen. J2EE and
The
For developers who are comfortable with limited choices,
The Ultimate Linux Bookmark
Microsoft released their shared-source CLI and C# implementation a couple days ago. I've been playing with it on my FreeBSD box, and while it's hardly the Java killer Microsoft's making it out to be, it's an interesting piece of work. If you've got a spare FreeBSD or Windows XP box lying around, download the source, compile it and play around with it some; it's always nice to know something about the platform before you start bashing it mercilessly :-)
"The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
If you're refering to this arcticle, it's worth noting (yet again) that 1.3.1 has been out for OS X for nearly six months now. That was just a bug fix update, and therefore it was hardly -just- released. Which isn't to say that Apple isn't at all behind the Java curve, but it's not as bad as some make out. It has also been stated that Apple will preview 1.4 in May at the WWDC, and that they hope to be in sync with Sun by the release of 1.5.
Here is an interesting article, describing how Microsoft is trying to get Java developers to write J# (java) code for the .NET platform. Unfortunately .NET only runs on the Windows platform, which has Sun a bit upset.
--It's Pimptastic!--
you are wrong man. Emacs was made at MIT. RMS contributed some to it. Gosling then made Emacs for Unix. RMS then took that code to build GNU Emacs, so RMS in some sense did steal from Gosling, but also did work on Emacs before Gosling.
Yeah. Yeah. I mean, abused and ripped off was also in there just to some extent.
I do find it obvious that there are some things in C# that are like Java. However, it seems to me that this is generally moot considering both languages where heavily inspired from C++. When you do your homework, you find that C# is actually quite different the Java:
+ C# is completely OO - even an Int32 is an Object. Java uses primitive types.
+ C# uses Delegates for Event Handling (think function pointers, but different).
+ C# supports the use of Properties instead of Getter and Setter methods.
+ C# supports Indexers which allow objects to be treated as Arrays.
+ C# forces explicit Method Overriding (via the virtual/override or new keywords).
+ C# supports namespaces. Unlike Java's packages, namespaces do not rely on a file/folder structure.
+ The C# Abstract or "Virtual Machine" (CLR) is not designed for C#, rather for language neutrality (to an extent). Java and the JVM, however, are closely tied.
I could go on. Whethor or not you think that these differences are Good Things(tm), the point is, they are definitely different langauges. Although there may have been some inspiration from Java, I'd be hard pressed to call it a "Java Ripoff".
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
"The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
+ C# is completely OO - even an Int32 is an Object. Java uses primitive types.
That is flat out silly. Java provides object wrappers for it's primitive types.
If you want to talk about non-OOP features, C# is full of them. Like structs for example. Who came up with that idea? And how about pointers? WTF? As far as Indexers go (and pretty much all the differences between Java and C#), they are just syntactic sugar that really just makes code confusing to read compared to Java.
The C# Abstract or "Virtual Machine" (CLR) is not designed for C#, rather for language neutrality (to an extent). Java and the JVM, however, are closely tied.
That's a hoot! The fact is that CLR doesn't support anything that can't be accessed from C#. That's why implementations of other languages have had to drop features like multiple inheritance before CLR implementations. All CLR does is provide a Procrustian cot for other languages to lie on. Head over the top? Lop it off!
There are many programming languages available for the JavaVM, including Lisp, Scheme, JavaScript, JPython, Prolog, and Eiffel. The fact is that the JVN is very little, if at all more language centric than is the CLR.
Although there may have been some inspiration from Java, I'd be hard pressed to call it a "Java Ripoff".
If it isn't a Java ripoff, then why is everyone comparing it to Java?
The fact is that Microsoft never innovated anything - and C# is just another Microsoft clone of somebody else's real innovation, plus marketing spin.
Interesting point. However, a System.Int32 does inherit from System.ValueType, which inherits from System.Object. Whethor or not this is a "good" thing or not, I think it shows the differences between (the) C#/CLR and Java/JVM, which was my main point. Maybe it's more accurate to state, "C# is more OO then Java".
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Object wrappers for primitives is not the same as the primitives themselves being treated as objects. Anyone whose used a true OO language like Smalltalk cringes and the inconsistency in Java between primitives and objects. Even C++ tries to make them as interchangeable as possible especially with templates.
For instance in Java there's no way to pass just a primitive like "5" or 2.6 to a method that takes an object while in C# and Smalltalk you can.
If you want to talk about non-OOP features, C# is full of them. Like structs for example. Who came up with that idea? And how about pointers? WTF?
The above comments how that you've somehow confused object oriented with Java which unfortunately are not the same thing. An object oriented system has 3 main qualities i) encapsulation or information hiding ii) inheritance and iii) polymporhism. All three of which can be done with C# structs (or value types). Secondl, I am immensely confused what the existence of an explicit pointer type has to do with whether a language is OO or not.
As far as Indexers go (and pretty much all the differences between Java and C#), they are just syntactic sugar that really just makes code confusing to read compared to Java.
Really? So is easier to read than On what planet?
That's a hoot! The fact is that CLR doesn't support anything that can't be accessed from C#. That's why implementations of other languages have had to drop features like multiple inheritance before CLR implementations. All CLR does is provide a Procrustian cot for other languages to lie on. Head over the top? Lop it off!
The Java VM was designed to run Java while the CLR was designed to be language agnostic. The fact that C++ can run on the CLR is a testament to this fact.
- You're using J2EE. That implies you probably should be using JBuilder 6 Enterprise which has numerous J2EE features for automating configuration of EJB's. If you're not using the enterprise edition, then your comparison is lacking in credibility, as Visual Studio .NET enterprise edition is approximately the same price.
- You have to edit four files to add a field to an EJB? Let me assume for a minute that you're using container managed persistence, which is the only scenario that would require such changes. Most tools will allow you to define the new field in your local interface, and will then propagate that field to your implementation class and your ejb-jar XML file. The second XML file, I will assume, is a custom deployment descriptor. Again, I would hope you're using a vendor's tool to manage this thing. But even if not, I find your indignaton towards all of this "work" somewhat amusing.
To put this tremendous amount of work in context, how much work does it take to add a field to a regular database table wtih a SQL call in JDBC, or for that matter, ADO.NET? That would require:
- doing a DML statement on the table to add the column at easiest. In some environments this may require several DML statements to create the new table, re-populate it with old data, populate it with the new column's data, then drop the old table and rename the new one.
- changing 1-2 method call signatures to take in extra parameters for inserts and updates.
- changing the JDBC code for reading, updating, and inserting to take the new field into account
- possibly adding the field to a data object that holds the data in memory.
Phew! I'm glad there's alternatives to EJB, it's so much easier without it.
Now, on to the next cow:
Deploying a JAR to two different places (jBoss and Tomcat). Firstly, I question what the problem is. You would deploy an EJB JAR to a jBoss instance and a WAR to tomcat, or you could just put it into one big EAR file and fo'gettaboutit. If you have two servers, then the ant optional tasks package could very easily do this work for you with approximately 3 lines of XML configuration.
The best part about your post is that "there probably are better ways". Yes, there are. Hire a consultant for 3 or 4 hours to help you out, it will probably be worth the $1000+. If you're missing GUI tools for jBoss, that would be because it doesn't really have any. Use a commercial server if you're not willing to hand-craft your config & deployment.
-Stu
C# has value classes, operators, multidimensional arrays, and easy and efficient interfaces to native code.
JDK 1.5 is going to include autoboxing of primitives. Operators aren't going to happen, by design. Multi-dim arrays, not really important to those outside of high-performance computation. Easy trap-doors to native code is a plus for C#, yes.
And Sun really has a double standard there: when Apple exposes all their native platform APIs to Java, that's fine. It's just not fine when Microsoft does it
You're ignoring some proven facts here, such as smoking gun memo's from Microsoft executives ordering the "pollution of Java". Adding keywords & extensions were not violations of the contract -- breaking RMI and JNI, and not supporting JFC/Swing were violations. Apple didn't break compatibility; Microsoft did.
What can open source developers do with Java before Sun is going to try and sue them?
What can Slashdot readers do when someone who's on a rant starts spouting FUD? Drop the drama, please.
Today, it's a huge system with incompletely specified APIs, lousy support for high-performance computations, and no independent third party implementations (all compliant Java2 implementations depend to a large degree on Sun's source code).
How are the API's incompletely specified?
How is high performance computation support "lousy" when most studies to this effect show that it's getting better every JDK release?
And IBM's JDK is *not* dependent on any Sun code.
If Sun doesn't clean up its act quickly, after seven years of lobbying for Java and using it for lots of software, I'm dropping it.
It's one thing to be objectively critical of Sun's complex behavior. It's another to be venting frustration unobjectively. Guess which of the two you're doing.
-Stu
Really? So
Math.Add(myList.getObjectAtIndex(0), myList.getObjectAtIndex(1));
is easier to read than
Math.Add(myList[0], myList[1])
On what planet?
-------
For the record, Java has never had any method
named getObjectAtIndex(). There are a few methods
named getObject() in the sql package, but to perform
the operation you're suggesting, you could do either:
Math.add(myList.get(0), myList.get(1))
That is assuming (incorrectly) that Java has a
static method in Math called add();
it does not. If you want to perform addition,
you'd simply say:
int val = myList.get(0) + myList.get(1);
or if you're using arrays instead of a Collection,
you could say:
int val = myArray[0] + myArray[1];
While I'm at it, on "what planet" is
myList[0], myList[1]
"easier to *read*" than myList.getObjectAtIndex(0)?
My first language is English, not C syntax, so
words written in a human language tend to come
off as "easier to *read*".
I'd rather read and write something like:
myArray at: myIndex
which is the truly "easier to *read*" syntax
of Smalltalk which isnt based on C syntax like
practically every major language in use today.
(apologies if I come off as too bitter but
it sucks that Smalltalk doesnt have the market-
or mind-share that all these beloved C syntax
langs do)
-
Max Korn