Fwd: Small things Java lets you do, but not everywhere.

[Brian Goetz]

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.  

> Begin forwarded message:
> 
> From: Jeremy Barrow <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: 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.

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