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.bar...@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-comme...@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.
