Small things Java lets you do, but not everywhere.

[Remi Forax]

De: "Brian Goetz" <brian.goetz at oracle.com> 
À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net> 
Envoyé: Mardi 21 Août 2018 13:57:51 
Objet: Fwd: Small things Java lets you do, but not everywhere. 




BQ_BEGIN
Received via the spec-comments list. Not a comment on any specific extant project; instead, a wish-list, and mostly stuff we’ve seen before — array literals, generic maps, union types. 
BQ_END

- array literals 
we already have them no ? 
new int[] { 2, 3, 5}; 
if you mean supported in the bytecode, yes, we are working on that as a follow up of ConstantDynamic. 

- generics/parameterized fields 
i occasionally want that but mostly to workaround the fact that generics are not fully reified. If we stick with erasure, i do not see any theoretical issue, with reified generics that we want to introduce as part of valhalla, it means that getfield/getstatic also have their semantics overriden to do a cast at least when writing to verify the constraint. 
Now, Java has a kind of pragmatic support of generics, not every constructs are supported because it can be. Parameterized fields (like lambda support of parameterized methods) falls in that category in my opinion. 

- union types 
technically, we already have union types but only for exceptions. 
@jeremy in your message you mix union like in C and union type that are not exactly the same thing. 
For union like in C, the obvious answer is to use an interface instead, with sealed interface, record and value types you can have something similar to an union, 
by example a Token of a lexer can be see as: 
value record Token(String data, Type type); 
sealed interface Type { 
enum Primitive implements Type { INT, DOUBLE }; 
record UserDefined(String name) implements Type; 
} 

For union types, in Java 5 it was decided to use lub (the lower upper bound) instead of the union between two types, i think destroy any hope to have union type in Java even if the type system of Ceylon and now Scala 3 (Dotty) clearly shows that it's a better idea. 

regards, 
Rémi 


BQ_BEGIN



BQ_BEGIN

Begin forwarded message: 

From: Jeremy Barrow < [ mailto:jeremy.a.barrow at gmail.com | jeremy.a.barrow at gmail.com ] > 
Subject: Small things Java lets you do, but not everywhere. 
Date: August 13, 2018 at 6:59:33 AM EDT 
To: [ mailto:amber-spec-comments at openjdk.java.net | amber-spec-comments at openjdk.java.net ] 

Heyo, I just wanted to send off a quick email about some of the things that 
I think would be easy pickings for Amber to tackle. 
More specifically, they're things in the language that are either not 
completely fleshed out due to lack of interest, or, more likely, for some 
technical reason. 

The first one is definitely array literals: 

I've been using Java for 7ish years at this point, and honestly, I don't 
even know if I'm gonna get this right. 
The only place I'm aware of array literals being valid is for a field write. 

Not many people use arrays, as Lists are just better, but _very_ 
occasionally you do have to reach for an array. 
It would be nice if we could expand the array literal use case. 
Just about everywhere an expression could be expected, I think an array 
literal could be valid. 
I can image `return` statements working really well with it, and with the 
new expression switch, the break with value. 


I'll be honest, this is where the "easy pickings" part is no longer true. 


Class local generics (Field local generics?): 

I definitely think I'm not the only one who has written some static field 
that has a map which maps some arbitrary data container to some value, with 
the data container containing some type parameter that tells you what the 
value type is. 

`private static final Map<Key<?>, ?> data = ...` 

It would be a massive boon, if we could write that as something like: 

`private static final <T> Map<Key<T>, T> data = ...` 

Otherwise we have to cast everything we pull out of the map. 
I know it's of the correct type, but the compiler doesn't. 
This leads to some annoying stuff where generics aren't actually helping 
you, which is a bit counter intuitive. 
We have generics for methods, theoretically, it should be possible for 
fields. 

Union types: 
Now, I'll preface this with this might be difficult to translate into the 
VM right now, so erasure might be the only option for now (With type 
signatures being a possible route in the future). 

In a nutshell, declaring fields with union types. 
Right now, I either have to declare three different fields, making my 
memory usage suffer if I have tons of these objects (Which I normally do, 
because this specific class is a Token class for a lexer, and I parse 
massive input sources), also making it more error prone due to having three 
different ways to access the same data. 
Granted union types won't solve the last problem, but it doesn't help it. 
Technically, Java does have union types in catch signatures. 
Obviously, the catch signatures kinda get "collapsed", so it's not really 
the same, as there's a lot more needed under the hood here. 
Possibly. 
I think a quick prototype might be just to treat it as though I had written 
something like, and just erase it to Object: 
`private final <T extends String | Integer | Double> T data;` 
Obviously, we don't have union generics, so that would obviously have to be 
added, and honestly, I think that might be the can of worms I didn't plan 
on. 


So, I'll wrap it up there. 
Obviously, the generics and union types are quite.. large in scope, and 
aren't really easy, but I do think the array literals are something that 
could be touched on. 

Cheers, 
Jeremy. 

BQ_END



BQ_END


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180821/8bfd051c/attachment.html>