amber-dev Digest, Vol 15, Issue 24

[Benjamin Komen]

Outlook voor Android<https://aka.ms/ghei36> downloaden

________________________________
From: amber-dev <amber-dev-bounces at openjdk.java.net> on behalf of amber-dev-request at openjdk.java.net <amber-dev-request at openjdk.java.net>
Sent: Monday, May 28, 2018 12:00:00 PM
To: amber-dev at openjdk.java.net
Subject: amber-dev Digest, Vol 15, Issue 24

Send amber-dev mailing list submissions to
        amber-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fmailman%2Flistinfo%2Famber-dev&data=02%7C01%7C%7C44bd4971bb5c4daedf0d08d5c4929890%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636631056260142330&sdata=qrId4UFbrP9HbFolh%2FGk9pVjm6fHFvZ8%2BkviAxRyW8s%3D&reserved=0
or, via email, send a message with subject or body 'help' to
        amber-dev-request at openjdk.java.net

You can reach the person managing the list at
        amber-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of amber-dev digest..."


Today's Topics:

   1. RFR: implementation for JEP 334: JVM Constants API (jbvernee)
   2. RFR: implementation for JEP 334: JVM Constants API (jbvernee)


----------------------------------------------------------------------

Message: 1
Date: Sun, 27 May 2018 11:57:46 +0200
From: jbvernee <jbvernee at xs4all.nl>
To: amber-dev at openjdk.java.net
Subject: RFR: implementation for JEP 334: JVM Constants API
Message-ID: <40a48e8f3b9efa0650d17a3284bf66da at xs4all.nl>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hello,

1. After looking around some more, I also noticed that you can make the
return type of `FieldTypeDescriptor::arrayType` in `Class` more
specific:

```
@Override
@SuppressWarnings("unchecked")
public Class<T[]> arrayType() {
     return (Class<T[]>) Array.newInstance(this, 0).getClass();
}
```

I don't think I'm wrong in assuming that this always returns
`Class<T[]>`? I imagine that could be very useful.

---

2. It's unfortunate that the return type of `describeConstable` in
`EnumDesc` and `VarhandleDesc` can't be simplified any more currently.
The cause seems to be that `DynamicConstantDesc` implements `Constable`
on it's own, and does so with a less specific type parameter than is
needed for the simplification. I can think of 2 ways to work around
this. The first is to not let `DynamicConstantDesc` inherit from
`Constantable` itself, but leave that up to the subclass, so it can use
a more specific type parameter. For `EnumDesc` for instance that would
be `Constable<EnumDesc<E>>`, then the return type of `describeConstable`
could be `Optional<ConstantDesc<EnumDesc<E>>>`. I'm not sure how
important it is for `DynamicConstantcDesc` to be a sub type of
`Constable` though.

The other solution, which does keep it as a sub type, would be to add an
additional type parameter to `DynamicConstantDesc` for the type with
which to implement `Constable` i.e.:

```
public abstract class DynamicConstantDesc<T, C extends ConstantDesc<?
super T>>
         implements ConstantDesc<T>, Constable<C> {
```

Then `EnumDesc` would extend `DynamicConstantDesc<E, EnumDesc<E>>`, and
return `Optional<ConstantDesc<EnumDesc<E>>>` (similarly for
`VarhandleDesc`). Basically `C` is the type implementing
`DynamicConstantDesc` here. The default implementation of
`describeConstable` in `DynamicConstantDesc` would have to be removed
(making it abstract), or change it's implementation to return
`Optional.empty()`, since there is no easy way (afaik) to return
something that satisfies the new return type. So that pretty much forces
subclasses to implement `describeConstable` themselves. Right now, both
subclasses of `DynamicConstantDesc` override it any ways, and with the
help of the factory methods `DynamicConstantDesc::of` an implementation
looks trivial, so that shouldn't be too much of a problem for future
subclasses (?).

It's the question if doing this is worth it for the sake of simpler
return types for the subclasses. I think it is, since the abstract base
is just a template to build classes on top of, but the subclasses and
interfaces are what you end up using mostly (how often do you see
`AbstractList` in code?) and you want their types to be specific and not
some erased version.

(I hope I didn't make any mistakes, I can't build the JDK right now, so
it's mostly been copy-and-pasting code into my own IDE)

Best regards,
Jorn Vernee


------------------------------

Message: 2
Date: Sun, 27 May 2018 21:04:11 +0200
From: jbvernee <jbvernee at xs4all.nl>
To: amber-dev at openjdk.java.net
Subject: RFR: implementation for JEP 334: JVM Constants API
Message-ID: <48b986f608525a5e7164f326f88d04da at xs4all.nl>
Content-Type: text/plain; charset=US-ASCII; format=flowed

> It's unfortunate that the return type of `describeConstable` in
> `EnumDesc` and `VarhandleDesc` can't be simplified any more currently.

I might have gotten lost in my own train of thought a little bit there.
I missed the fact that you can also change the return types to
`Optional<ConstantDesc<ConstantDesc<E>>>` for `EnumDesc` and
`Optional<ConstantDesc<ConstantDesc<Varhandle>>>` for `VarHandleDesc`,
without changing anything else. Those are at least a little bit simpler.


End of amber-dev Digest, Vol 15, Issue 24
*****************************************