Sun to Add Variance to Java in 1.5?

Ahe writes "I have been working on a joint project between Sun Microsystems, The University of Aarhus, and The Alexandra Institute. As you might know, Sun has for long been commited to adding generics to Java. Our project was to extend this with variance annotations for more flexible typing of parameterized classes and arrays. Recently Sun has released the project result as a new prototype with variance. If you like variance, please vote for this bug."

Comments

Somebody understood something ?

[IIEFreeMan]

I did not but I would be interested to learn (I know what generics are but not variance)

Thanks

Re:Somebody understood something ?

[hummassa]

kind of simple, really...

covariance: CT: container ISA CQ: container iff T ISA Q; so you can assign each contained Q to a T inside a CT, i.e., Write a Superclass Value To The Subclass Container;

contravariance: CT ISA CQ iff Q ISA T; so you can assign some T from a Q in CQ, i.e., Read a Superclass Value From the Subclass Container;

bivariance or invariance: CQ ISA CQ iff Q ISA T and T ISA Q; basically, you can only read or write to/from some container Equivalent types (the same type, actually, in Java);

ok? hope to have helped;

Massa

Re:Somebody understood something ?

[noselasd]

>ok? hope to have helped; Yes, you contributed quite a lot to common confusion with thisone.

Re:Somebody understood something ?

[Hard_Code]

Why was this modded funny? This was the explanation of variants that was necessary.

And remember, if you vote on that bug you are NOT voting for generics. That has already been agreed upon. You are voting for adding "variance" to generics, which is explained in the parent post.

Re:Somebody understood something ?

[be-fan]

En anglias:

Convariance means that, you can add a Derived to a list of Base without casting.
Contravariance means that you can unpack a Derived from a list of Base without casting.
Invariance is what you have in C++, where a list of Derived and a list of Base are two different things.

Re:Somebody understood something ?

[cplesner]

An introduction explaining the basics of variance will be made available soon, probably within a day or two.

Re:Somebody understood something ?

[fizbin]

Minor correction:

Contravariance means that you can unpack a Base from a list of Derived without casting.

Re:Somebody understood something ?

[Horny Smurf]

you mean, all your base are unpacked to us?

Re:Somebody understood something ?

[Anonymous Coward]

The C++ comment is misleading.

If you have list of Base or Derived as _values_ then you need the exact type.

If you have list of Base _pointers_ then you can easily add or remove Derived objects.

Polymorphism only works through pointers, and it just so happens that in Java, thats all you have (for objects at least).

Re:Somebody understood something ?

[Anonymous Coward]

Couldn't this be performed automatically based on the method signatures? If you have a class in which the generic type appears only in parameter lists, then it is convariant. If the generic type appears only as the return type, then it is contravariant.

(And isn't your definition of contravariant the wrong way round? Given List you'll always need to cast a Derived on get (as normal); but you could have List and get into a variable declared as Base)

I think this avoids introducing any ugly notation - at the cost of the ability to break things inadvertently.

Re:Somebody understood something ?

[Anonymous Coward]

I'm all for variance because it is complicated and ugly. C++ is complicated and ugly and it looks like Java and C# will move even further in that direction.

Features like these will only hasten the move towards dynamically typed languages like Python, Smalltalk, Ruby, and CLOS.

Dynamic typing may some dangerous, but the main thing that static typing prevents: calling a function that doesn't exist, happens in code about as often as dereferencing a null pointer. We don't see people shoveling syntax and static checking into languages to prevent that error, do we?

Re:Somebody understood something ?

[Anonymous Coward]

I think they meant "variants", but someone with a dry-clean-only shirt was using dragon point and speak again.

Re:Somebody understood something ?

[Anonymous Coward]

Er, no, the underlying type theory terms are "covariance" and "contravariance" (not "covariants" or "contravariants").

Definitely a bug!

[Twylite]

Generics are at best a trade-off: compile-time type safety in exchange for less readable code. A poor trade-off at best.

Java never has and never will suffer the catastrophic consequences of type casting that C++ can. Type casts are all subject to runtime checks, so that the worst possible result is that an exception will be thrown. Where C++ has no safety without generics, Java has runtime safety.

As for readability, C++ has two major benefits over Java: a preprocessor and typedefs. Without at least one of these features, generics make code almost unreadable. Little wonder that developers new to C++ are very cautious about getting involved with generics, or that old hands know how long it has taken for the STL to become mostly stable (I say mostly, because using STL with threads in cross-platform development is a recipe for disaster).

Java is starting to look very much like something designed by a committee. A pity, because at its core it is still a good thing.

Re:Definitely a bug!

[DeadSea]

I can see myself using generics when designing APIs. Lets say that I currently have a method that returns a list of Strings. Internally I store those Strings in a Vector so that I can add to it easily. I want users to be able to access these Strings so I create a getStrings() method. Since want the user to know that they are Strings and not have to do any casting I currently do something like this:

public String[] getStrings(){
String[] s = new String[vector.size()];
return vector.toArray(s);
}

Maybe in the future I could just store them in a list and return that list because it is a string list specifically:

public List<String> getStrings(){
return list;
}

Re:Definitely a bug!

[scrytch]

Unfortunately, since Java's generics act solely through type erasure, you're still screwed -- all Java generics do is insert invisible casts into your code, with all the overhead you expect from that. Type erasure is overall a good thing -- the fact that Foo is a subclass of Foo is very useful, and lets you avoid many of the ugly traits hacks in C++, and it does give good hints to the compiler, but at the same time, lack of a typedef also removes many of the things that are still useful in traits classes, and all the extra casts you don't see still cost as much as the ones you write by hand.

The current release of jsr104 will even create mysterious ClassCastExceptions in some cases because the type inference is unsound. The documentation even warns of being able to do invalid casts (e.g. a String to a JFrame), which casts doubt on the safety of the complier. If that's the case, you can be sure that the jsr104 compiler is going to have one or more of its features axed before it makes it into tiger.

Re:Definitely a bug!

[elflord]

Generics are at best a trade-off: compile-time type safety in exchange for less readable code.

Given the choice between explicitly using a parameter, and using a nebulous "Object", I'd say that the template code is easier to read, because the parameter conveys more meaning than the word "object" (which offers no clue about what "type" is being used)

Where C++ has no safety without generics, Java has runtime safety.

Wrong. See dynamic_cast.

As for readability, C++ has two major benefits over Java: a preprocessor and typedefs

Shows how much you know -- you've named what are arguably two of the most botched legacy features of C++.

Without at least one of these features, generics make code almost unreadable.

This is not true. What makes code difficult to comprehend is complexity (allocaters, classes with several parametrised types, etc). Fortunately, C++ offers features that make complexity manageable (though typedefs don't deal with templates as well as they should)

(I say mostly, because using STL with threads in cross-platform development is a recipe for disaster

No, naively assuming that every STL implementation on every platform is thread safe is a recipe for disaster. Well, duh! The same is true even for straight C code -- you need to use thread safe versions of the library functions.

Re:Definitely a bug!

[scrytch]

Should read: ... The fact that Foo<Bar> is a subclass of Foo ...

Wouldn't it be nice if any disallowed HTML were just passed through as literal text instead of being stripped out?

Re:Definitely a bug!

[iabervon]

The only way in which generics make code less readable is the awful angle brackets; otherwise it's a bit more verbose but no less clear, and verbosity has been an aspect of Java from the beginning.

In C++, the reason people are scared of templates is that they're actually quite complicated, with historical stability problems and continuing unexpected behavior. Java only supports the more obvious cases.

Java has been designed by committee from the start, but it's always been an extremely conservative committee; they only include features that a lot of people agree on and of which there are working implementations which have been tested enough to verify that the feature behaves as expected. They're also perfectly happy to not add a feature if it would cause problems, or to send it back for more discussion. C++ has had a lot of problems due to idealism and abstract discussion.

It is significant that, in working on generics and variance, they've gone through the entire Collection library and considered how it should be modified to support all existing code while giving benefits to new code.

Re:Definitely a bug!

[rlowe69]

I don't know what compiler you are using, but your example

public String[] getStrings(){
String[] s = new String[vector.size()];
return vector.toArray(s);
}

is not liked well by the Eclipse compiler because toArray(s) returns Object[]. Instead it prefers:

public String[] getStrings(){
String[] s = new String[vector.size()];
return (String[])vector.toArray(s);
}

Re:Definitely a bug!

[j7953]

You probably know this, but you usually don't want to return your internal list variable:

public List getStrings() {
return Collections.unmodifiableList(list);
}

(I haven't looked at Java's proposed generics yet, so I don't know how that would look with generics. I think that you might have to cast the result of unmodifiableList since by default it returns a List of Objects, not a List of Strings.)

Re:Definitely a bug!

[looseBits]

Of course, this would be much better (you don't need the array length to be the size of the vector, it just needs to know what class it is):

return (String[]) vector.toArray(new String[0]);

or even

private static final String dummy[] = {}; ...
return (String[]) vector.toAyyar(MyClass.dummy);

Re:Definitely a bug!

[rlowe69]

Nice, I will definitely use that. Thanks.

Re:Definitely a bug!

[pediddle]

That's what I hate about Java's collections API. If it's a list, and if it provides set() et. al., then why can't you use it? "Intentional" runtime errors like UnsupportedOperationException are just as bad as a ClassCastException. Generics is meaningless when classes don't obey their contracts.

A List is a List, and it is modifiable. A new class, UnmodifiableList, which doesn't provide set() or add(), is the only answer.

Re:Definitely a bug!

[jovlinger]

but... but...

Foo<Bar> isn' a subtype of Foo (which in this context should be read Foo<Object>), is it? So why should it be a subclass?

That would require covariance in the type parameter implying subtyping, and a clear counter-argument is
void set_element(<param>). For Foo<Bar>, it accepts only Bar, but for Foo it accepts any Object. Thus, treating a Foo<Bar> as a Foo will cause runtime errors.

Java has already made this mistake with arrays.

They so should have done the Right Thing and taken a more powerful generics system which allows mixins to be expressed.

Re:Definitely a bug!

[burner]

It's true that it doesn't need to be of that size, but you're going to create a wasted object if you do it this way.

toArray() will use the array given unless it's too small, so it's more efficient (and not any harder on the eyes or programmers fingers) to use an array of length vector.size().

Variance?

[robkill]

I assume the correct term is Variants. I realize this is "leading edge" of java development, but are there any links that don't require being a member of the Java Development Consortium?

Re:Variance?

[iabervon]

Nope, actually "Variance". The idea is that sometimes you need to know that something is exactly of some type, sometimes you need to know that something is "at least" of some type (i.e., equal or a subtype), and sometimes you need to know that something is "at most" of some type.

Say you have a List, and you want to do:

Number num = list.get(0);

In this case, you need to know that the list contains elements which are Number or a subtype of Number, so you declare that you're taking a List<+Number>

If you want to put a Number into the list, you need to know that the list can contain Numbers, which means that it has to be a list of "at most" Numbers (i.e., it is not a List of something more specific, which would not accept a Number). You thus declare that you're taking a List<-Number>.

If you're going to do both, you require that the list contain nothing that's not a Number and that it be able to contain anything that is a Number, so you declare it to be List<=Number> (the = is optional in this case).

If you don't care what type the elements are, you can use List<*>, rather than the equivalent List<+Object> (a list which contains Objects and subtypes; unrestrictive, since everything that's not a primitive type is a subtype of Object). This is somewhat clearer, since it means that you don't care at all.

Of course, actual code is more likely to use type variables rather than Number; sort(), for instance, takes a List which is exactly of some unspecified type and a Comparator which does not require anything more specific than that type.

Variance is a neat idea, but what's the rush? The issue is dealing with arrays. Traditional arrays require that a variable of Number[] get a value of at least Number[] (i.e., +Number in the new syntax), but they allow you to store a Number in the array, even if the array is actually of a subtype of Number; if it doesn't fit, you get a runtime exception. However, the extra type information for generics isn't around at runtime, so nothing can stop a List<Number> from being stored into an array of List<Double> which has been passed into a method which takes an array of Object (at compile time, it is an array of Object getting a List<Number>, at runtime, it is an array of List getting a List, but then a[0].get(0) might be an Integer not a Double like it's supposed to be). So the idea is to get a version of arrays like the variance-using Lists above into the language to be used with generics, which implies including variance at the same time as generics, so that unsafe arrays mixed with generics can be prohibited.

Re:Variance?

[Anonymous Coward]

For the very few times this will matter, wouldn't it just be cooler to create a Collection abstraction for yourself that forces you to use something like this. Like Collection c=new VarianceCollection(Number.class);

I completely fail to see where you would ever need to know if something is at most of some type unless you don't know how to use inheritance properly. Even if you did, you can always use reflection to see if .class is equal to what you are casting it to.

It wouldn't be hard. You could even use Interfaces. There is no need to modify the language that I can see to implement this. Maybe add a constructor and exception to the Collections API. (Technically, I don't think the constructor wouldn't be part of the Collections API.)

What confuses me is that they are adding variable arguement lists. Why? What's wrong with passing a HashTable? Are people that afraid of new Integer(x)? You can even modify the HashTable for those people that don't like the absence of pass by reference. I think most people that complain for more features just have a lack of imagination, or they are anal about something that makes no difference.

Why do we need generics? Casting doesn't involve much of a penalty, but if you want to enforce a particular type of object, why not just implement a collection wrapper to force it? If you make .add(Object o) into .add(MyIntereface o), you can do everything you need, with only 20 lines of code I might add.

There is absolutely no arguement for generics. I don't consider having to cast from Object being a pain, an arguement.

Everyone that has ever complained for these "features" in my mind has never actually understood java, thus they are probably just C++ coders that don't want to learn a new language. It looks like their language, but they can't be bothered to use an interface, so they'll continue to complain about multiple inheritance until Java is C++.

Re:Variance?

[BenTels0]

I completely fail to see where you would ever need to know if something is at most of some type unless you don't know how to use inheritance properly. Even if you did, you can always use reflection to see if .class is equal to what you are casting it to.

Not you -- the compiler would need to know. Like with all parametric polymorphism of this kind, it is all about moving type correctness checks from runtime to compile time.

What confuses me is that they are adding variable arguement lists. Why?

As far as I can tell, they aren't -- methinks /. made a booboo.

Why do we need generics?

So that we may employ static type checking instead of dynamic. I.e. compile-time type checking instead of dynamic checking at runtime. That way the compiler can catch error in the way a(n instance of a ) class is used instead of your program having to deal with errors all over the place or even coming to a crashing halt. Not needing the dynamic type check (I do believe the idea is that the compiler will leave it out in these cases) is a bonus in the running time area (I am loathe to call that an "efficiency" concern), but it is not the primary point.

Casting doesn't involve much of a penalty, but if you want to enforce a particular type of object, why not just implement a collection wrapper to force it?

First of all, it's not that simple -- what you are proposing is not overriding a method but overloading it. That means the original method which takes an Object remains accessible and callable through instances of your new class. So you have to remember to overload that method more or less like so:

public void add(Object o) {
/* We already know !(o instanceof MyInterface),
because that would have been sent to the wrapper method */
throw new <pick an exception>;
}

Which is a pain. Small one, but still. Not to mention, you'd have to do this every time you want to use a Collection type safely, for every type you want to put in your collection. And you still have to deal with runtime errors afterwards.

If you make .add(Object o) into .add(MyIntereface o), you can do everything you need, with only 20 lines of code I might add.

That's true, but it makes using Collections just that little more inconvenient. Generics provides more or less all the benefits you want, without all the extra hassle.

There is absolutely no arguement for generics. I don't consider having to cast from Object being a pain, an arguement.

How do you feel about static type safety?

Re:Variance?

[iabervon]

Everyone that has ever complained for these "features" in my mind has never actually understood java, thus they are probably just C++ coders that don't want to learn a new language. It looks like their language, but they can't be bothered to use an interface, so they'll continue to complain about multiple inheritance until Java is C++.

Generics aren't at all the same as C++ templates, although they draw on C++ experience to avoid the C++ problems, like most of Java. This is like how Java includes single inheritance like C++, but not multiple inheritance, which is complicated to specify, use, and implement. The issues with C++ templates are the type variable computations and the different resulting object files for different types; Java skips these, and manages to implement generics entirely at compile time.

Guy Steele was an author of an ACM paper about adding generics to Java and Gilad Bracha is the specification lead for the JCP group. So two of the people who complained for these feature are authors of The Java Language Specification, and one of them was an original language designer. I'd defer to them on what fits the spirit of the language.

Java's design goals include that any unsafe memory usage be prevented, either at runtime, or, ideally, at compile time. Generics help with this. While it seems to be true of Java that you have to write 20 lines of code whenever you want to do something, this is not actually a design goal.

What is variance?

[DeadSea]

I've done some googling and I've come up with some quick answers. It seems it makes Java generics act more like C++ Collections in some cases.

From http://forum.java.sun.com/thread.jsp?forum=316&thr ead=389987&start=15&range=15&tstart=0&trange=1 5:

> I can't quite get my head round what combination of
> VM, compiler and/or language changes would iron out
> the following incompability between arrays and
> generics:
>
> Cat[] cats = new Cat[10];
> Animal[] animals = cats; // legal
>
> List cats = new List(10);
> List animals = cats; // illegal
> according to JSR-14

This problem is addressed in the "variance" extension to
the generic type system, which will be included in the
imminent JSR14 prototype 2.0. Details are enclosed in
the prototype.

Also a link to a MIT research paper on variance from that thread.

Re:What is variance?

[jovlinger]

The compatibility problem is that the arrays get it wrong.

Given animals aliased to cats, it would be statically type safe for me to say animals[0]=new Dog();. But this causes a runtime error. Runtime errors on assignment!?! Array subtyping is NOT a feature (although I would have to think for a bit what to replace it with before removing it).

Re:What is variance?

[mtorgersen]

The variance proposal included in the JSR14 prototype also applies to arrays. This may be the alternative to current runtime-checked array covariance, that you are looking for. You can declare animals to be invariant:

Animal[=] animals;

In which case assigning an array of Cats to animal is a static type error:

animals = new Cat[10]; // Compile-time error!

Or you can declare it to be covariant in a statically checked way, by writing:

Animal[+] animals;
Cat[=] cats = new Cat[10];
animals = cats;

In which case assigning elements into animals is forbidden:

animals[0] = new Dog(); // Compile-time error!

So you get to choose, at the point of declaration, whether your compiler should enforce covariance or assignability for your array variable. In both cases, absence of runtime store-check errors is guaranteed. Of course you can still read elements out of a covariant array.

For completeness, let me mention that you can also have contravariant arrays types:

Cat[-] cats;
Animals[=] animals = new Animal[10];
cats = animals; // Yes, really!
cats[0] = new Cat();

The contravariant array cats can hold any array into which you can insert a cat. This includes arrays of Animal, or of Object, for that matter. Contraintuitive at first, perhaps, but try thinking about it a couple of times, or run some examples using the JSR14 compiler.

Reading from a contravariant array is possible, but lets you assume nothing about what you read out:

Object o = cats[0]; // OK
Cat c = cats[0]; // Compile-time error!

Would this scheme be a worthy substitute for current array covariance, in your oppinion?

Insightful? Come on!

[hummassa]

Ok. This is my first real drooling mad rant. Forgive me.

[rant]
about C++ casting (covariant model of generics): old-style casting was never of real use. use new_style_casts(x) and you have run-time checking, too. other stuff said about this is C++ ignorance.
[/rant]

ohboy, I had to get it off my chest.

Re:Insightful? Come on!

[Anonymous Coward]

Great point. I love it when a Java programmer looks down on C++ it like a BASIC(non-compiled version) programmer looking down on a assembly language programmer. Java only compile half way, and as a result it's still an interpreted language. The can make the interpreter sound nice by calling a virtual machine.

Re:Insightful? Come on!

[(startx)]

It's great that you got that off your chest. Now, what the hell did you say?

Relation to covariant return types? (4144488)

[valstadsve]

How does this bug relate, technically, to RFE 4144488, which is pretty high on the vote count already? It seems they are requesting pretty similar stuff, so I'm curious if this is a tactical move to ensure the tiger is variant. Should we vote for both, or just this one?

I want both of them, anyway. Good luck.

Re:Relation to covariant return types? (4144488)

[gafter]

No relation at all. That is for covariant
return types on methods, this is for
covariant (and contravariant) generic type
parameters.

Thank you.

[hummassa]

Now I have to wipe clean my keyboard, mouse, and work desktop machine 'cause you made me laugh while drinking my sugary black tea.

It's confusing, yes, but... it's not my fault. I just tried to make it more or less more more or less confusing!! :-)

bye

Re:Thank you.

[dr.robotnik]

ahem. was that syntactic sugar in your tea?
</couldn't resist>

Short description of variance

[Ahe]

The term variance covers co-variance, contra-variance, and bi-variance. In the 1.5 prototype you can use variance annotations on parameterized types.

+ means co-variant (think read-only).
- means contra-variant (think write-only).
* mean bi-variant (niether read nor write).

You are familiar with co-variance from arrays in Java.

When an array of Integer is a subtype of array of Number, arrays are said to be covariant in their element type. Consider:

Number[] ns = new Integer[10];

With generics, you can have a list of Numbers:

List<Number> nl = new List<Number>();

However, since generics are added without changing the JVM, nl can only refer to lists of exactly Number, e.g., this is wrong:

List<Number> nl = new List<Integer>();

So why is this wrong, consider arrays:

Number[] ns = new Integer[10];
ns[0] = new Double(0.0); // run-time error

Since ns refers to an array of Integer, we cannot put Double in to it. The mechanism that catches this is called store-check.

Since the JVM is not modified, we cannot implement a store-check for generic classes. Variance annotations allows us more flexibility, however.

Consider this method:

void copy(Collection<+Number> src, Collection<-Number> dst) {
for (Number n : src) { dst.add(n); }
}

Here we use variance annotations to state that we will only read from src and only write to dst. In this way we are allow to make a call like this:

List<Integer> il = new List<Integer>();
List<Object> ol = new List<Object>();
copy(il, ol);

Sometimes we are not interested in reading or writing elements, so we can say:

List<*> list_of_unknown_type = ...;

Then we can only use methods like size() on list_of_unknown_type.

Re:Short description of variance

[liloldme]

holy shit! that's some ugly stuff right there -- I hope it never makes into the Java language.

Re:Short description of variance

[valstadsve]

So if I understand this correctly, you were able to avoid the JVM changes that seemed to implied by the previous prototype, by using annotations instead.

I think this is great news. Do you think youll get it through the business decision paper mill in time for Tiger?

Re:Short description of variance

[ENOENT]

Yeah, I agree. It's the C++ syndrome of adding bunches of new language features in the hopes that one of them will fix the problems introduced by all of the previous additions.

Re:Short description of variance

[Ahe]

No changes to the JVM were necessary for the previous release. What variance does to generics is adding the flexibility that programmers would expect IMHO.

Try programming with generics, but without variance, and you will see what I mean.

Generics more readable

[AT]

Huh? Generics make code more readable!

When using non-generic containers in Java, you are usually forced to make a cast when accessing its members. For example:

String s = (String) list.get(0);

It gets worse if you are making multiple calls, because you usually need parentheses to bind the cast:

String s = ((Foo) list.get(0)).fooMethod();

However, with generics, you don't have to write the cast, because the type is implied. The bytecode is the same, but the code is much clearer:

String s = list.get(0).fooMethod();

Tell me how that is less readable. Anybody who thinks generics are unreadable is probably thinking of the worst C++ template abuses, needless complexity, and obscure syntax. Thankfully, Java generics are simple and clear.

Links don't work!

[Anonymous Coward]

None of the links work unless you have a login at Sun's Java site. Any links to this info else where.

Which leads me to a rant about articles that link to content that is not readily accessible? What's the point, a casual reader can't access the information.

Re:Links don't work!

[Anonymous Coward]

More to the point, either the slashdot janitors are sun-registered developers (yeah right), or they don't bother checking links in stories.

Re:Links don't work!

[cakoose]

It's free registration. Just like the NY Times. But yeah, I hate the NY Times links...keep forgetting my login.

JDC =

[Anonymous Coward]

Java Developper Connection ;-)

By the way, you seem to know how to register to a free web service as you posted using your /. login :o)

Links

[bonniot]

The research article presenting the theory of variance.

There is a discussion about this on Lambda the Ultimate.

These links don't require registration :-)

Variance homepage

[cplesner]

The variance extension now has a homepage at http://www.daimi.au.dk/~plesner/variance.

Reinventing The Wheel (Again)

[othertimothy]

Gee, sometimes one wants to know if an object could be considered as some other type. Hmmm, writing methods that don't need to know the concrete type until run-time. Perhaps Sun should consider looking at a mature OO programming language like CLOS aka Common Lisp Object System. Lisp solved many of these problems long ago. From my perspective, the real value of Java is proving the concept of byte size virtual machine code for run anywhere capability. The real cost savings for continued programming in Java is not the language features but the massive amount of ready-built infrastructure that comes in the JDK and JDK extensions. It is interesting to watch that as the popular OO programming/scripting languages evolve, the more they resemble Common Lisp at least in terms of features.