Genericity? One of the most anticipated and debated enhancements to the Java language in Sun’s new 1.5 release is generics. John Anthony and Scott Chalfant provide an introduction to this new feature and help you explore some of its more-advanced features and avoid potential difficulties.
An Introduction to Generics in Java
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Cool to see that Microsoft dares to compare generics in .NET and Java; here’s a snippet from an article (March 2003):
“Meanwhile, Sun Microsystems® has proposed the addition of generics in the next version of the Java language, code named “Tiger”. Sun has chosen an implementation that does not require modifying the Java Virtual Machine. As such, Sun is faced with implementing generics on an unmodified virtual machine.
The proposed Java implementation uses similar syntax to templates in C++ and generics in C#, including type parameters and constraints. However, because it treats value types differently than reference types, the unmodified Java Virtual Machine will not be able to support generics for value types. As such, generics in Java will gain no execution efficiency. Indeed, the Java compiler will inject automatic downcasts from the specified constraint, if one is declared, or the base Object type, if a constraint is not declared, whenever it needs to return data. Furthermore, the Java compiler will generate a single specialized type at compile-time that it will then use to instantiate any constructed type. Finally, because the Java Virtual Machine will not support generics natively, there will be no way to ascertain the type parameter for an instance of a generic type at runtime and other uses of reflection will be severely limited.”
(from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv…)
http://mindview.net/WebLog/log-0050
Sun’s done a lot of things right too. like it or not, i can take a java/swing app and run it anywhere right now. including, with many times very little modification, on a web applet.
wake me up when this is possible with C#. because it won’t be for many many years if ever since there is no standard cross platform windowing toolkit that ships standard like java with any sun compliant JRE (that means not windows default JRE, which is a piece of shit).
on top of all this is insurmountable real-world proof of java’s power in the enterprise arena with business logic development using java beans, java’s the default language on the AP, and as of TODAY i can assign students java labs and they don’t have to pay a cent for expensive IDEs (visual studio .net) no matter the platform, and they can run it on any OS they choose without fear of an unimplemented or buggy feature.
sorry, but no thanks. if microsoft had designed C# to not be windows dependent for interfaces (system.windows.forms), open sourced the compiler and provided ports for linux/mac out of the box i MIGHT speak differently.
i can take a java/swing app and run it anywhere right now. including, with many times very little modification, on a web applet
Anywhere? You call Windows, Solaris, Linux, and Mac OS X, anywhere? Some of us use FreeBSD, NetBSD, OpenBSD, etc. Of these, only FreeBSD has a recent native JRE/JDK, and that is only at version 1.3. Also, from a distribution point of view, Java applications suck. To my knowledge, very few operating systems and computers ship with a recent version of the JRE. Expecting users of your software to download a runtime that is several megs in size from a dial-up connection is just plain ridiculous. Additionally, Java Web Start runs great under Windows, Mac OS X and I presume Solaris, but is a piece of crap under Linux. Maybe someone can tell me why they decided to make Linux users run a separate installation program for it?
because it won’t be for many many years if ever since there is no standard cross platform windowing toolkit that ships standard like java with any sun compliant JRE (that means not windows default JRE, which is a piece of shit).
wx.NET and GTK# will be cross platform, maybe not standard on Microsoft platforms, but they will be the standard for the free world, and will be a relatively small install on Microsoft windows. Either way, Swing is a piece of garbage. It is very overengineered, cumbersome to use, and a very poor performer. SWT seems a little saner, but puts you in the same position as GTK# and wx.NET, not included standard.
as of TODAY i can assign students java labs and they don’t have to pay a cent for expensive IDEs (visual studio .net) no matter the platform, and they can run it on any OS they choose without fear of an unimplemented or buggy feature.
As of TODAY I can also develop using C# without paying a cent for expensive IDEs. SharpDevelop is an excellent solution for those of us without money to spend on IDEs. How is C# or .NET in general any more buggy or unimplemented than Java? I’ve had nothing but positive experiences with both so far.
Personally, I think neither Java nor .NET (and clones) will ever be strong performers on the desktop because Sun and Microsoft hold these platforms in a very tight death grip.
Perhaps we should put our hopes on Parrot and possibly an adaptation of C# to Parrot.
the authors of this article should learn a bit about “Design Pattern”(specially the builder pattern) in order to avoid stupid trick used to manage collections(see listing 1-3), which by the way doesn’t solve the need to store different classes in a single collection…
Personally, I think neither Java nor .NET (and clones) will ever be strong performers on the desktop because Sun and Microsoft hold these platforms in a very tight death grip.
Surly you mean .NET will become the default for Desktop apps, cos MS has a tight grip on it, and are forcing it through.
And where MS goes, a percentage of the OSS community blindly follows. (not that having a .NET runtime is nessersarly a bad thing for Linux/etc).
re: Why have gernerics if no speed incress is given
As it makes development less error prone. A good thing.
Take a look at this code:
1 public <T extends Comparable> T max(T t1, T t2) {
2 if (t1.compareTo(t2) > 0)
3 return t1;
4 else return t2;
5 }
When you call this method with two ints, they will both be boxed to Integers. So for an operation that could be done in a few cycles, this one creates *two* temporary objects. The performance will be horrible.
In .NET the same code would not produce any temporary objects.
I think we had the same discussion some weeks ago.
Didn’t we?
Carsten
It looks like STL, doesn’t it ? Well, why not.
DG
Take a look at this code:
1 public <T extends Comparable> T max(T t1, T t2) {
2 if (t1.compareTo(t2) > 0)
3 return t1;
4 else return t2;
5 }
—————-
Generics don’t add anything in that example. How is that any different from the following that doesn’t use generics?
1 public Comparable max(Comparable t1, Comparable t2) {
2 if (t1.compareTo(t2) > 0)
3 return t1;
4 else return t2;
5 }
I agree that generics in Java just plain sucks.
“Generics don’t add anything in that example. How is that any different from the following that doesn’t use generics? ”
You don’t have to cast the return value back to an int. But other than that there is no difference.
Well, take your Java app that you “wrote once” and go ahead and deploy it everywhere. Then when you hear the complaints that it looks like it was developed for a completely different platform that where it is being run on, you’ll know why. There is nothing I personally hate more than ported or cross-platform software that doesn’t make any attempt at following the interface guidelines of the system I am running it on. Keep your application’s core cross-platform, but do make the attempt to use a native feeling interface for each platform.
// Take a look at this code:
public class Wrapper<T> {
private T wrapped;
public Wrapper() {}
public Wrapper(T wrapped) {
this.wrapped = wrapped;
}
public void setWrapped(T wrapped) {
this.wrapped = wrapped;
}
public T getWrapped() {
return wrapped;
}
}
// And then:
Wrapper<Collection> w = new Wrapper<List>();
w.setWrapped(new java.util.HashMap());
// throws ClassCastException
// Shouldn’t that be detected at compile time?
// Note that this problem also applies to arrays:
Collection[] cs = new List[1];
cs[0] = new HashMap();
// again throws ClassCastException
Don’t like them, don’t use them?
Does anyone else find it awkward that you have to explicitly state the version of the target VM when using some of the new features? For example, previously we had -source 1.4 for assertions among other things, now we have -source 1.5 for generics. The other way around would make more sense to me, for example specifying -source 1.3 and the compiler will tell you if you use any features that won’t run on a 1.3 VM.
Also, they shouldn’t be afraid to improve or even change the VM, if supporting generics properly require you to do some rewriting, so be it. If they can’t do it properly, bite the bullet and call it autocasting and not generics. They’re never going to hear the end of the comparisons to .net regarding generics now.
Actually, Generics do add something useful to the original max() function: it requires that all parameters be of the same type.
The second max() function using Comparable doesn’t have this requirement, allowing you to do:
Comparable c = max (new Integer (42), “some string”);
Does that make any sense? It should generate a runtime exception, if anything.
The main reason for me choosing Java as my main programming language was because of the syntax! Plain and simple, it was was easier to learn than C++. Now SUN has embarked in adding “Generics” to the language, basically adding complexity to the language. I am opposed to adding such things to the Java programming language. If they want to add complexity than suggest something Bjorne Stroustrip’s C++.
My two cents(US).
The generics not being visible in bytecode is not necessarily a problem. It is already the case that if you use the class Integer or any of the other object versions of primitive values in the code the JIT will in many cases catch the special cases and generate a separate version of the method that handles primitive values directly as you would want them to. This optimization does not even have to be updated most likely, maybe just a bit more aggressive statistical analysis of how often a given type is used to call a generic method. Basicly having the generics support on the bytecode level is not terribly interesting since you would do the analysis needed to optimize generics with or without knowing they exist.
You can happily code without getting into generics. You will see it but you don’t have to use it.
And how often does that happen in real life, not just example code? How many times have you had a ClassCastException? Very very rarely, and when you do get those exceptions, they are … exceptional cases of grossly misunderstanding what the code was meant to be doing.
Without Generics, the type safety of the language must be overridden to utilize general purpose data structures. With the need to cast whenever a general purpose data structure is being utilized, the usefulness of compile time type safety checking is greatly diminished, as it’s constantly being manually overridden by the programmer. If the programmer makes a mistake in a typecast, the error will not be evident until runtime debugging.
Generics allow the benefits of compile time type safety checking to be fully utilized in a strongly typed language where the use of general purpose data structures is desirable.