#225 - Wish list for Java 8 and 9
17 views
Skip to first unread message
Weiqi Gao
Jan 12, 2009, 7:51:41 AM1/12/09
to java...@googlegroups.com
Now that the Java 7 feature set has been redefined and (provisionally
and non-bindingly) finalized (again), and my (and I think a lot of
others') favorite features are not in it, I think it's time to start
compile a wish list for Java 8 and Java 9.
and non-bindingly) finalized (again), and my (and I think a lot of
others') favorite features are not in it, I think it's time to start
compile a wish list for Java 8 and Java 9.
Here's mine:
Java 8:
Reified generics
Removal of dead features (java.awt.Button, etc.)
Java 9 (or whatever Sun decides to call it, having version numbers go up):
Closures
Macros (the kind that's IDE friendly, not the C kind)
I believe closures needs to be on the table forever. The moment
everyone cave in to the "Java has used up all its complexity budget"
line of thinking, Java will be dead.
I'm not saying that I disagree with the claim that "Java has used up all
its complexity budget" here. I do not know about Java's internals to
make up my mind. But the fact that multiple proposals (with feature
complete implementations, and specifications) exist seems to favor the
argument against that claim.
I understand that things aren't always decided on technical grounds.
Funding, competitive positioning of vendors, trends in technologies
external to Java, etc., all impact the direction of Java.
But still, the rank and file Java developers need to know Java *is
moving forward* and not *standing still*, for some definition of moving
forward.
--
Weiqi Gao
weiq...@gmail.com
http://www.weiqigao.com/blog/
Jess Holle
Jan 12, 2009, 8:27:22 AM1/12/09
to java...@googlegroups.com
Weiqi Gao wrote:
> Now that the Java 7 feature set has been redefined and (provisionally
> and non-bindingly) finalized (again), and my (and I think a lot of
> others') favorite features are not in it, I think it's time to start
> compile a wish list for Java 8 and Java 9.
>
> Here's mine:
>
> Java 8:
>
> Reified generics
> Removal of dead features (java.awt.Button, etc.)
>
A large benefit of modularization ala Jigsaw is that you don't have to > Now that the Java 7 feature set has been redefined and (provisionally
> and non-bindingly) finalized (again), and my (and I think a lot of
> others') favorite features are not in it, I think it's time to start
> compile a wish list for Java 8 and Java 9.
>
> Here's mine:
>
> Java 8:
>
> Reified generics
> Removal of dead features (java.awt.Button, etc.)
>
remove stuff like this (which you really can't without breaking a lot of
applications). Instead it goes into an obsolete/deprecated module which
you just never load if you don't use it.
Ideally Javadoc gets updated to hide such cruft by default as well.
Then you get the best of both worlds -- nothing breaks, but you don't
have to pay for cruft in any real sense.
--
Jess Holle
Reinier Zwitserloot
Jan 12, 2009, 11:02:10 AM1/12/09
to The Java Posse
agreed, Jess.
Also, going on a cruft-hunting expedition first, and adding closures
later, is clearly the wrong way around.
Adding closures will result in loads of cruft. Lots of APIs are
fundamentally awkward today (fork-join first and foremost, but its not
the only one) due to lack of closures / easy syntax for anonymous
inner classes / some way to pass a method handle (a.k.a. delegate).
All of those I conveniently call 'closures', usually, because they
accomplish mostly the same stuff.
Once 'closures' in any sense of the word is added, there's more cruft
to shoot down.
Also, going on a cruft-hunting expedition first, and adding closures
later, is clearly the wrong way around.
Adding closures will result in loads of cruft. Lots of APIs are
fundamentally awkward today (fork-join first and foremost, but its not
the only one) due to lack of closures / easy syntax for anonymous
inner classes / some way to pass a method handle (a.k.a. delegate).
All of those I conveniently call 'closures', usually, because they
accomplish mostly the same stuff.
Once 'closures' in any sense of the word is added, there's more cruft
to shoot down.
mikaelgrev
Jan 12, 2009, 11:56:38 AM1/12/09
to The Java Posse
> A large benefit of modularization ala Jigsaw is that you don't have to
remove stuff like this ...
Then you need Swing 2.0 as a new module that doesn't have
java.awt.Button as a base class. But on the other hand I'm all for
Swing 2.0.. (and that is NOT JavaFX)
Cheers,
Mikael Grev
Peter Becker
Jan 13, 2009, 4:49:23 AM1/13/09
to java...@googlegroups.com
I don't know. Cruft-hunting should be a traditional thing and getting
cruft out of the system might be less controversial than adding
something new. And once the cruft is gone people might be more willing
to take on new things.
Peter
--
What happened to Schroedinger's cat? My invisible saddled white dragon ate it.
cruft out of the system might be less controversial than adding
something new. And once the cruft is gone people might be more willing
to take on new things.
Peter
What happened to Schroedinger's cat? My invisible saddled white dragon ate it.
Bill Robertson
Jan 14, 2009, 9:39:28 AM1/14/09
to The Java Posse
I can see that for "obsolete" libraries, but I have trouble seeing
that happening for reified generics. Don't reified generics start at
compile time? i.e. is the type erasure is done by javac? If so, I
don't see how a modular runtime could help.
that happening for reified generics. Don't reified generics start at
compile time? i.e. is the type erasure is done by javac? If so, I
don't see how a modular runtime could help.
Reinier Zwitserloot
Jan 14, 2009, 10:18:07 AM1/14/09
to The Java Posse
Well, unfortunately cruft hunting can only go so far even with a
module system. You can't just fix java.util.Properties, which would
surely fit with 'cruft hunting'. (currently horridly designed, it
should not extend HashMap at all, and even if it did, it should be a
HashMap<String, String> instead of the current renditionof <Object,
Object>,but for backwards compatibility reasons, what we got is what
we got).
You can't even kill off old codgers Vector and Hashtable, because,
again due to backwards compatibility reasons. (Some AWT/Swing methods
take a Vector. Even if you replace this with a more generic List,
existing class files break because that would make it an entirely
different method. If you take them out then either old code breaks, so
there isn't much point in stuffing them in a module, or you also have
to take all those swing classes out into the old module, which would
mean that old code can't pass a Button instance to new code anymore.
Annoying, isn't it)?
Just a clarification on the concept of killing some crud. There's
plenty that can be modularized, but certainly not everything we now
see as a mistake.
module system. You can't just fix java.util.Properties, which would
surely fit with 'cruft hunting'. (currently horridly designed, it
should not extend HashMap at all, and even if it did, it should be a
HashMap<String, String> instead of the current renditionof <Object,
Object>,but for backwards compatibility reasons, what we got is what
we got).
You can't even kill off old codgers Vector and Hashtable, because,
again due to backwards compatibility reasons. (Some AWT/Swing methods
take a Vector. Even if you replace this with a more generic List,
existing class files break because that would make it an entirely
different method. If you take them out then either old code breaks, so
there isn't much point in stuffing them in a module, or you also have
to take all those swing classes out into the old module, which would
mean that old code can't pass a Button instance to new code anymore.
Annoying, isn't it)?
Just a clarification on the concept of killing some crud. There's
plenty that can be modularized, but certainly not everything we now
see as a mistake.
Reinier Zwitserloot
Jan 14, 2009, 10:28:24 AM1/14/09
to The Java Posse
Bill: Yes, and no. It's complicated.
Generics could show up in 3 places:
Types, Signatures, and Objects.
Generics are not, are definitely, and are kind of, erased,
respectively, in those 3 places. To be specific:
Generics information from TYPES is not, and has never been, erased. If
you write:
public List<String> foobar; //this is a field.
then the fact that foobar is a List<String> is available in the class
file, and even available via reflection if you use the right methods
(which are admittedly very awkward, but you can get it with some
effort).
Generics information from SIGNATURES is erased.
If you write:
public void foobar(List<String> x) {}
public int foobar(List<Integer> x) {}
javac will not even compile it, eventhough normally 2 methods with
different parameter lists are separate even if they share a name.
That's because internally, generics isn't encoded in a method
signature. In java, method names are expanded with their parameter and
return type, so the above would become:
com.package.ContainingClass.foobar(Ljava/util/List;V)
com.package.ContainingClass.foobar(Ljava/util/List;I)
which is not okay - being only different in return type is not
allowed. This isn't a big concern and is not generally covered by what
is meant with 'we should reify generics', but its important to know
that this can pretty much never be fixed without serious overhauling
of the JVM.
Generics information from OBJECTS is erased, but this is a JVM thing:
If you write:
new ArrayList<String> foobar;
then what actually happens is that you just create an ArrayList. Yes,
javac does not encode the <String> part of it in the classfile (you
couldn't even if you wanted to; you can't put annotations there and
there's no JVM directive to state generics parameters when
constructing an object), but other than this lack of encoding
parameters when calling methods / constructors, the JVM is perfectly
free, in a future version, to start tracking this stuff. For example,
in the statement:
List<String> foo = new ArrayList<String>();
what can actually be recovered by the JVM at runtime is this:
List<String> foo = new ArrayList();
In that situation, the only possible legal construction that can show
up on the right hand side is <String>, so a future JVM could in theory
attach this to the object instance and make that "String" relation
retrievable via a new addition to the reflection API. Things get more
difficult in situations like:
List<? super Double> foo = new ArrayList<Number>();
Here the compiler really can't infer the 'Number' on the RHS from the
generics signature on the LHS (which is the only thing a java v1.5 or
1.6 class file carries inside it) - it knows it has to be either
Number, or Double, or Object, or Serializable. Those are the only four
options. But which one of those is it?
This boils down to objects not being part of the class file
architecture; objects are created by the runtime itself. Class files
merely contain the code that explains to the runtime how and when to
create them. So, the answer for this last one is 'it's complicated'.
Generics could show up in 3 places:
Types, Signatures, and Objects.
Generics are not, are definitely, and are kind of, erased,
respectively, in those 3 places. To be specific:
Generics information from TYPES is not, and has never been, erased. If
you write:
public List<String> foobar; //this is a field.
then the fact that foobar is a List<String> is available in the class
file, and even available via reflection if you use the right methods
(which are admittedly very awkward, but you can get it with some
effort).
Generics information from SIGNATURES is erased.
If you write:
public void foobar(List<String> x) {}
public int foobar(List<Integer> x) {}
javac will not even compile it, eventhough normally 2 methods with
different parameter lists are separate even if they share a name.
That's because internally, generics isn't encoded in a method
signature. In java, method names are expanded with their parameter and
return type, so the above would become:
com.package.ContainingClass.foobar(Ljava/util/List;V)
com.package.ContainingClass.foobar(Ljava/util/List;I)
which is not okay - being only different in return type is not
allowed. This isn't a big concern and is not generally covered by what
is meant with 'we should reify generics', but its important to know
that this can pretty much never be fixed without serious overhauling
of the JVM.
Generics information from OBJECTS is erased, but this is a JVM thing:
If you write:
new ArrayList<String> foobar;
then what actually happens is that you just create an ArrayList. Yes,
javac does not encode the <String> part of it in the classfile (you
couldn't even if you wanted to; you can't put annotations there and
there's no JVM directive to state generics parameters when
constructing an object), but other than this lack of encoding
parameters when calling methods / constructors, the JVM is perfectly
free, in a future version, to start tracking this stuff. For example,
in the statement:
List<String> foo = new ArrayList<String>();
what can actually be recovered by the JVM at runtime is this:
List<String> foo = new ArrayList();
In that situation, the only possible legal construction that can show
up on the right hand side is <String>, so a future JVM could in theory
attach this to the object instance and make that "String" relation
retrievable via a new addition to the reflection API. Things get more
difficult in situations like:
List<? super Double> foo = new ArrayList<Number>();
Here the compiler really can't infer the 'Number' on the RHS from the
generics signature on the LHS (which is the only thing a java v1.5 or
1.6 class file carries inside it) - it knows it has to be either
Number, or Double, or Object, or Serializable. Those are the only four
options. But which one of those is it?
This boils down to objects not being part of the class file
architecture; objects are created by the runtime itself. Class files
merely contain the code that explains to the runtime how and when to
create them. So, the answer for this last one is 'it's complicated'.
Peter Becker
Jan 14, 2009, 4:07:59 PM1/14/09
to java...@googlegroups.com
On the type level you also have the problems that
1) you can't implement two interfaces which differ only in their type
parameter, e.g. you can't be Comparable<String> and Comparable<Date>
(I had sensible examples, but I forgot them). This relates to the
signature problem in some ways, but the two methods you would need to
implement in the example are actually a legal overload.
2) you can't do "T.class" in a MyClass<T>
(http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ206).
You can do a magic incantation to get that information ((Class<T>)
((ParameterizedType)
this.getClass().getGenericSuperclass()).getActualTypeArguments()[0]),
but that's pretty weird and also breaks if you suddenly get wrapper
objects (e.g. you can't write a generic JPA Dao if you want to use
Spring's transaction mechanisms since they use AOP wrappers). That's
when you start passing a Class<T> as extra parameter, which is
confusing for ~100% of developers and it always means your API
suddenly gets warts.
Peter
1) you can't implement two interfaces which differ only in their type
parameter, e.g. you can't be Comparable<String> and Comparable<Date>
(I had sensible examples, but I forgot them). This relates to the
signature problem in some ways, but the two methods you would need to
implement in the example are actually a legal overload.
2) you can't do "T.class" in a MyClass<T>
(http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ206).
You can do a magic incantation to get that information ((Class<T>)
((ParameterizedType)
this.getClass().getGenericSuperclass()).getActualTypeArguments()[0]),
but that's pretty weird and also breaks if you suddenly get wrapper
objects (e.g. you can't write a generic JPA Dao if you want to use
Spring's transaction mechanisms since they use AOP wrappers). That's
when you start passing a Class<T> as extra parameter, which is
confusing for ~100% of developers and it always means your API
suddenly gets warts.
Peter
Tom Hawtin
Jan 15, 2009, 12:17:19 PM1/15/09
to The Java Posse
On Jan 14, 3:28 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> com.package.ContainingClass.foobar(Ljava/util/List;V)
> com.package.ContainingClass.foobar(Ljava/util/List;I)
>
> which is not okay - being only different in return type is not
> allowed. This isn't a big concern and is not generally covered by what
> is meant with 'we should reify generics', but its important to know
> that this can pretty much never be fixed without serious overhauling
> of the JVM.
Adding generic type information to method calls and using that
> com.package.ContainingClass.foobar(Ljava/util/List;V)
> com.package.ContainingClass.foobar(Ljava/util/List;I)
>
> which is not okay - being only different in return type is not
> allowed. This isn't a big concern and is not generally covered by what
> is meant with 'we should reify generics', but its important to know
> that this can pretty much never be fixed without serious overhauling
> of the JVM.
together with the generic type information already present on methods
in the class file doesn't seem a great stretch to me. The question is
what sort of bangs-per-buck are you getting. The bucks are small, bit
the bangs are barely a fizzle, IMO. But I think thats a general
problem with reification.
> what can actually be recovered by the JVM at runtime is this:
>
> List<String> foo = new ArrayList();
Tom
Peter Becker
Jan 15, 2009, 4:10:55 PM1/15/09
to java...@googlegroups.com
On Fri, Jan 16, 2009 at 3:17 AM, Tom Hawtin <tack...@tackline.plus.com> wrote:
>
> On Jan 14, 3:28 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>> com.package.ContainingClass.foobar(Ljava/util/List;V)
>> com.package.ContainingClass.foobar(Ljava/util/List;I)
>>
>> which is not okay - being only different in return type is not
>> allowed. This isn't a big concern and is not generally covered by what
>> is meant with 'we should reify generics', but its important to know
>> that this can pretty much never be fixed without serious overhauling
>> of the JVM.
>
> Adding generic type information to method calls and using that
> together with the generic type information already present on methods
> in the class file doesn't seem a great stretch to me. The question is
> what sort of bangs-per-buck are you getting. The bucks are small, bit
> the bangs are barely a fizzle, IMO. But I think thats a general
> problem with reification.
>
> On Jan 14, 3:28 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>> com.package.ContainingClass.foobar(Ljava/util/List;V)
>> com.package.ContainingClass.foobar(Ljava/util/List;I)
>>
>> which is not okay - being only different in return type is not
>> allowed. This isn't a big concern and is not generally covered by what
>> is meant with 'we should reify generics', but its important to know
>> that this can pretty much never be fixed without serious overhauling
>> of the JVM.
>
> Adding generic type information to method calls and using that
> together with the generic type information already present on methods
> in the class file doesn't seem a great stretch to me. The question is
> what sort of bangs-per-buck are you getting. The bucks are small, bit
> the bangs are barely a fizzle, IMO. But I think thats a general
> problem with reification.
You could make the same point for any overloading. If you can
distinguish between
singleParameterMethod(A param);
and
singleParameterMethod(B param);
why not distinguish
listParameterMethod(List<A> param);
and
listParameterMethod(List<B> param);
?
The conceptual difference seems very similar. Even more extreme if you
include arrays -- but I'd rather ignore those.
>> what can actually be recovered by the JVM at runtime is this:
>>
>> List<String> foo = new ArrayList();
>
> It gets more paradoxical with the like of Collections.emptySet
The problem exists only if you look at a mutable version, otherwise
the empty set can be seen as being of any type. Once you require
mutability it is only fair to request the specification of a type
parameter.
Peter
Reinier Zwitserloot
Jan 15, 2009, 6:27:36 PM1/15/09
to The Java Posse
Ah, but, screwing around with the meanings of method signatures would
make some serious backwards incompatibility issues.
Fortunately class files have version info so you could do some trick
whereby new class files do set a difference, but if an old class file
code wants to acess a new class file with this thing going - I don't
see how that would work.
On Jan 15, 10:10 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
make some serious backwards incompatibility issues.
Fortunately class files have version info so you could do some trick
whereby new class files do set a difference, but if an old class file
code wants to acess a new class file with this thing going - I don't
see how that would work.
On Jan 15, 10:10 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
Tom Hawtin
Jan 16, 2009, 8:23:33 AM1/16/09
to The Java Posse
On Jan 15, 11:27 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Ah, but, screwing around with the meanings of method signatures would
> make some serious backwards incompatibility issues.
It would allow a proper superset of what was previously legal.
> Ah, but, screwing around with the meanings of method signatures would
> make some serious backwards incompatibility issues.
> Fortunately class files have version info so you could do some trick
> whereby new class files do set a difference, but if an old class file
> code wants to acess a new class file with this thing going - I don't
> see how that would work.
obvious rules to handle the situation when it does occur are: declare
adding such an overloading a binary incompatible change for old
versions; or declare one of the the overloads as the default for old
versions.
Tom Hawtin
Weiqi Gao
Jan 16, 2009, 1:04:48 PM1/16/09
to java...@googlegroups.com
You can now vote for how this closure drama will end at Java.net:
http://today.java.net/pub/pq/242
and "Closure added in Java 9" is one of the choices.
Here's how this thing will end:
+ No closure in Java 7
+ No closure in Java 8 (People who killed closure for 7 won't relent
for 8.)
+ Massive talent drain away from Java (cool language designers will
work on ABJ--anything.but.java, cool programmers will latch on to what
the cool language designers design)
+ Closure-denialists finally see the light
+ Closure added to Java 9 (everyone will say it's too late, but it
won't be)
+ Everyone lives happily ever after
Don't think this scenario is plausible? This is exactly how the "Open
Source Java" theme played out.
Reinier Zwitserloot
Jan 16, 2009, 8:28:20 PM1/16/09
to The Java Posse
Until we sort out if we want Structural types or not, and if we want
long returns or not, java will never have closures. These concerns
need to be explained adequately, there needs to be a clear majority,
and everyone needs to stop whining about syntax (syntax can be fixed.
syntax can be learned. syntax is a thing of taste and there's no way
to even rationally argue about a lot of it. Let it go).
There's one thing I will say for CICE: It is the most conservative,
supporting neither structural types nor transparent returns. However,
you can retrofit both of them on top of CICE by adding a new
annotation for the SAM type that marks it as supporting transparent
return, and/or adding FCM's or BGGA's structural type syntax along
with conversion rules. I don't see how staggered introduction would
hamper either the syntax or the implementation.
> weiqi...@gmail.comhttp://www.weiqigao.com/blog/
long returns or not, java will never have closures. These concerns
need to be explained adequately, there needs to be a clear majority,
and everyone needs to stop whining about syntax (syntax can be fixed.
syntax can be learned. syntax is a thing of taste and there's no way
to even rationally argue about a lot of it. Let it go).
There's one thing I will say for CICE: It is the most conservative,
supporting neither structural types nor transparent returns. However,
you can retrofit both of them on top of CICE by adding a new
annotation for the SAM type that marks it as supporting transparent
return, and/or adding FCM's or BGGA's structural type syntax along
with conversion rules. I don't see how staggered introduction would
hamper either the syntax or the implementation.
Vince O'Sullivan
Jan 19, 2009, 5:35:15 AM1/19/09
to The Java Posse
On Jan 12, 12:51 pm, Weiqi Gao <weiqi...@gmail.com> wrote:
> Now that the Java 7 feature set has been redefined and (provisionally
> and non-bindingly) finalized (again), and my (and I think a lot of
> others') favorite features are not in it, I think it's time to start
> compile a wish list for Java 8 and Java 9.
I wish for it to arrive before my children have grandchildren.> Now that the Java 7 feature set has been redefined and (provisionally
> and non-bindingly) finalized (again), and my (and I think a lot of
> others') favorite features are not in it, I think it's time to start
> compile a wish list for Java 8 and Java 9.
Casper Bang
Jan 19, 2009, 1:22:36 PM1/19/09
to The Java Posse
I heard cryopreservation companies are preparing special package deals
for developers who want to be sure to see it arrive.
for developers who want to be sure to see it arrive.
Steven Herod
Jan 19, 2009, 2:04:44 PM1/19/09
to The Java Posse
Didn't I see a Java 9 banner in 'Futurama'?
bannerbruce
Jan 25, 2009, 12:43:46 PM1/25/09
to The Java Posse
Reified generics
Closures
the long awaiting module system
...
Closures
the long awaiting module system
...
Reply all
Reply to author
Forward
0 new messages