Java Gets Templates

lastberserker writes "Call them all you want - generics, parametrized types, thingamagic mumbojumbo - but (tada!) Java gets templates in 1.5 release. Nice landing after 5+ years of dancing around a bush. Competition is good, pardon my pun."

Comments

Re:OMG templates totally rule!

[jilles]

Sounds like you don't get the point. The reason templates are useful is because it reduces the amount of code you need to write for common situations in a typesafe way. This makes your code more compact (duplicate code) and less error-prone (it's all type safe and you only write it once).

BTW. generics are old news. The prototype compiler and the proposal have been available for at least a year. On the javalobby there's a link to some additional language extensions: http://www.javalobby.org/thread.jsp?forum=61&threa d=6009 (lets hope /. gets this right). Lets hope all these goodies end up in 1.5.

Re:OMG templates totally rule!

[Wrexen]

Templates are useful for tons of things other than generic containers. Consider something like this in C++

template <class T> T Max(T x,T y) {
if(x>y)
return x;
else
return y;
}

The compiler can determine at compile-time if you're comparing similar types, and error if you're not. Also, it doesn't need to do any run-time type checking to figure out which > to use.

The Java equivalent would return an Object and take two Objects as parameters. All the type safety you work so hard to preserve is lost, and at run-time you're taking a performance hit every time this is called for a myriad of reasons.

Re:OMG templates totally rule!

[lightspawn]

The compiler can determine at compile-time if you're comparing similar types, and error if you're not. Also, it doesn't need to do any run-time type checking to figure out which > to use.

The Java equivalent would return an Object and take two Objects as parameters.

No, the java equivalent would use an interface, probably called "comparable" or somesuch.

Good, but need to avoid a few problems

[magnum3065]

Doing mainly C++ development I've learned to love the STL and most recently the Boost libraries and I've long regretted that Java didn't support templates. It always confused me that with as much emphasis was placed on strong typing in Java that there was so much need for casting.

Although I'm glad to see the introduction of templates, I'm also concerned about how some of the problems I've encountered with C++ templates will be avoided. The biggest problem I've encountered has been the lack of interface checking.

For example the templated function for_each(begin, end, function) iterates from 'begin' to 'end' calling 'function' on each item inbetween. However there is no mechanism to specify that the type of passed to 'begin' and 'end' must have an equality operator and an operator* and 'function' must take one parameter of the type returned by *begin. This can cause very strange compiler errors when a user tries to pass a variable that doesn't support the proper operations to be compatible with the function. These errors actually appear to occur within the templated code, not the user-written code and can make determining the cause of these errors very difficult.

The Boost Concept Check library provides a way for programmers writing templated C++ code to enforce the interface requirements on the templated parameters in a way that gives more informative error messages. However this is rarely used, even in the Boost libraries. The documentation on the Boost Concept Check gives a good example of the kind of errors that C++ programmers dread.

In order for Java templates to be successful they will need to provide some manner of enforcing requirements on the interface necessary for the templated code to work and provide useful errors at compile time if it doesn't.

Re:How sad

[Hellkitten]

Damn I hate replying to myself

It seems I may have misunderstood the parent post. Reading through it again I believe he meant something like

class MySortedList<Comparable Element>{
void insert(Element e) {
/* now we can do this: */
int i = e.compareTo(another_element);
/* because we can be sure that e implements
comparable */
}
}

which it seems the specification doesn't support, and it should have. (to be really useful)

Re:Not really the point.

[Kynde]

Its sad how many ./ers dont truely understand o/o concepts or the many other cool features of Java. Hell many still think the only place Java exists is within Applets.

Although I agree with you, I must say that "understanding object orientation" amongst programmers is little like "understanding humour" amongst ordinary people. Everybody think they do.

Any language (that I know of, and that is quite a bunch) can be used to write "proper OO code" aswell as plain-old imperative programming.

I think Alan Cox put it well when he said "object orientation is a state of mind". Linux kernel is really object oriented on many many levels.

Obligatory "parametrics != generics" comment

[Anonymous Brave Guy]

Since no-one has yet pointed it out that I can see, it should be noted that what we're talking about here is parameterised types, and to a limited extent, parameterised methods. This is still quite some way from what you can do with serious generics in other languages.

There is an obvious comparison with C++ templates here, and although those are not the best generics around themselves, they do have a few very useful tricks up their sleeves. In Java, you can now do parameterised containers, and to a limited extent you can do generic algorithms, although the lack of things like operator overloading cripples these from birth. You can't, AFAICS, do some of the funky stuff with traits classes, and things like template metaprogramming, expression templates and Andrei's tricks combining templates and inheritance -- the stuff that's used in several of the best C++ libraries today to give them an edge -- are out of the question for now.

That's a shame, because one of the great things about C++ templates is that using them is pretty easy, but there's quite a bit of power under the hood for people actually implementing class and function templates, such as the designers of those libraries. That means improved performance and/or flexibility for Joe Developers everywhere, even if only a few people know and use the features under the hood.

Re:Good, and when do we gets enumerated types?

[Anonymous Coward]

Check JSR-201 "Extending the JavaTM Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import"

Re:Too little, too late

[addaon]

Sun (or at least the people I've spoken to at Sun, who do represent their company) never said that generics weren't necessary. They said, with surprising honesty, that no one had yet come up with an implementation of generics that made sense for the virtual machine. The current implementation of java with generics has been available for around 18 months (externally for what, 12 months?), and has been a compromise implementation, giving a highly requested feature at some cost, perhaps, in the potential beauty of the implementation. The reason that generics weren't included with Java 1.0 is that no one could agree on how to do them; Sun has since realized that they won't be perfect, regardless, but that it's time to push them out the door. Probably, their publication of this stuff is prompted by C# (which uses, more or less, the same flawed-but-usable implementation). But I really do respect Sun's restraint in trying to make it as good as possible.

--

Re:How sad

[bunratty]

You should be able to write this as:
class MySortedList<Element implements Comparable> {
void insert(Element e) {
/* now we can do this: */
int i = e.compareTo(another_element);
/* because we can be sure that e implements comparable */
}
}

Re:Too little, too late

[DmitriA]

Wrong! C# uses a RADICALLY different implementation of generics - Java opted for 'erasure' approach because they needed to preserve backward-compatibility. So that means that all generic type information is removed by the compiler/translator and that code is replaced with polymorphic subtyping with casts (essentially, using the same collections of Objects but everytime you insert or retrieve an element, it will do a cast) - thus, horribly slow runtime performance.

Next version of C# will support generics in the VM and that will remove the need for casts and allow you to do other nifty stuff like polymorphic recursion, getting specific runtime information that Vector is really that and not a Vector - in Java, you would have to look at the actual elements to determine that.
In fact, Microsoft Research people that presented a paper on generics in .Net at PLDI '01 claim that this is the first ever implementation of generics with support in the VM itself. But I think if Sun had the time to do it in Java in the beginning, they would've opted for a similar design, but since they hadn't and now they can't go around changing all the VMs and losing compatibility with all the code that is out there, that wasn't an option for them

Re:Too little, too late

[Anonymous Coward]

Here's more information about C# vs. Java generics: http://www.gotdotnet.com/team/csharp/learn/Future/ VCS Language Changes.aspx.