Slashdot Mirror
One Runtime To Bind Them All
Sowbug writes "Here's some interesting Saturday night reading: a critical examination of many of the advertised benefits of .NET's CLR (Common Language Runtime) and the other technologies (MSIL, CLS, CTS) that make it possible. It's written from the perspective of a Java advocate, Osvaldo Pinali Doederlein. "
There are a few articles at Microsoft on this topic here and here.
--Metrollica
Exactly. Never. Java is a neat little concept - that has some neat little benefits. But it has caught on for large-scale applications.
Though I suspect that was a typo. Java has caught on for large-scale applications. The reason you can't buy Java apps in Best Buy is because they don't sell large scale applications. They sell boxed programs for PCs and Macs that are almost exclusively written in C++. Java's principle use is for the server side of various business systems.
This is the field MS are aiming for with .NET, too. Indeed, that seems to be its principle purpose: to displace Java from back-end server systems. Microsoft already owns the desktop, and Java is no particular threat there for reasons that don't need to be rehearsed again. For the device market, they have other plans.
I've written a rather large custom application before using Java and Swing - that was back around when the JDK 1.2 had just come out. The base target machine was a P166 with 32MB of ram rinng Win95.
After some work, we had an MDI all-swing application taht worked pretty well and had some a number of nice custom controls. While a little slow on a P166 with 32MB of RAM, it was quite usable and needless to say on anything even a bit more powerful (like the developers screamin' fast P450's) you'd think it was a native app.
So, speed is not really Java's problem on the desktop.
The swing framework I found great and very nice for devloping powerful custom controls with minimal code. I would not say that a good GUI library is what Java lacks either (and there are others to choose from for those that hate Swing as some do).
What I think Java has sufferd from is the large footprint and somehwhat long startup times (though those have been reduced). OS X has helped a lot be really integrating Java into the UI a bit, and doing things like sharing some Java resources for running programs.
So, Java needs some way to help share Java resources to make many desktop Java apps practical.
What Java also needs though is desktop Java programming tools. Some are already there - both Installshield and InstallAnywhere make GREAT Java installers that work well across many platforms. But I would say IDE's have not really helped the Desktop standalone developer. Sure there are a lot of GUI tools, but I think desktop app development needs more than just GUI builders to help you build a good desktop app. While I'm not exactly sure what that might consist of, I think that's an area that needs work.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Nobody has mentioned this yet, so I will. A research version of the CLR implements true generics, but because they only have limited resources, they decided not to include it in the first release. The following is quoted from this interview with Chief C# Language Architect Anders Hejlsberg:
Hejlsberg:
But with respect to the generics that you asked about, I definitely think generics are a very useful concept and you can certainly tell that from all the generics research that's taking place in academia and industry. Templates are one solution to the problem. In our internal discussions, we concluded that we wanted to do it right for this new platform. But what we would really like is to have generics understood by the underlying runtime. This is different from how some of the generic prototypes have been built. Take Java's notions of "erasure" where there's really no knowledge of generics in the system. By having the common language runtime understand the concept of generics, multiple languages can share the functionality. You can write a generic class in C# over in one place and someone else using a different language can use it. But making generics part of the runtime also enables you to do certain things much more efficiently. Instantiation of generics should ideally happen at runtime. With C++, instantiation of templates happens at compile time, and then you have two options: you can either let your code bloat or you can try, in the linker, to get rid of some of the bloat. But, if you have multiple applications, you can forget about it. You're just going to get bloated code.
If you push the knowledge of generics into the common language runtime, then the runtime can understand that when an application or a component asks for a list of "Foo's," it should first ask: "Do I already have an instantiation of a list of "Foo?" If so, use that one. Indeed, if Foo is a reference type, and if we do the design right, we can share the instantiation for all reference types. For value types, such as ints and floats, and we can create one instantiation per value type. But only when an application asks for it. We've done a lot of the design work and groundwork necessary to add generics to the runtime.
It's interesting you asked earlier about the IL because deciding to add generics impacts the design of the IL. If the instructions in the IL embed type information -- if, for example, an Add instruction is not an Add, but is an Add int or an Add float or an Add double -- then you've baked the type into the instruction stream and the IL is not generic at that point. Our IL format is actually truly type neutral. And, by keeping it type neutral, we can add generics later and not get ourselves into trouble, at least not as much trouble. That's one of the reasons our IL looks different from Java byte code. We have type neutral IL. The Add instruction adds whatever the two things are on top of the stack. In a generic world, that could translate into different code when the generic is instantiated.
Osborn: Is that available to all .NET languages?
Hejlsberg:
Yes. Microsoft Research in Cambridge has created a generics version of the common language runtime and the C# compiler. We're looking at how to move that forward right now. It's not going to happen in the first release, that much we know, but we are working on making sure that we do things right for the first release so that generics fit into the picture.