On 4/8/2016 4:55 PM, Bjorn B Vardal wrote:
Applicability check
> When loading a parameterization of a generic class, we perform an
applicability check for each member as we
> encounter it; in the model outlined here, this is a straight
subtyping check of the current parameterization against
> the restriction domain.
In order to support the subtyping check, the applicability check
should happen in the specializer, and not when loading the
specialization. Both the type information and the class hierarchy are
more easily accessible at that point.
Agree that this is a specialization-time decision. But I'm not sure
what "the specializer" is; in our prototype, we have a class that takes
a byte[] and a set of bindings and produces a new byte[] which we call
the specializer, but that's just one (bad) implementation strategy. So
I'm not sure that "a specializer" is a necessary part of the story, but
yes, this is a decision made at specialization time.
> If there are duplicate applicable members in a classfile where
neither's restriction domain is more specific than the
> other's, then the VM is permitted to make an arbitrary choice.
Seconding Karen's comment, we'd like to avoid "arbitrary" choices, as
both users and JVM implementers need to know how to get consistent
behaviour. Unspecified behaviour may change, and it may also have
corner cases that are treated differently by different JVM
implementations.
Would it be better to reject a specialization where there are multiple
maximally specific applicable members, or to reject templates that
would allow such scenarios?
We plan to reject these at compile time in any case. The only question
is, if some other compiler produces a classfile where there are multiple
applicable specializations, do we want to reject it on principle? It's
more work to reject the classfile than to make an arbitrary choice.
Consider this classfile:
Where[T=String] void m() {}
Where[U=String] void m() {}
Where[T=String, U=String] void m() {}
This classfile is valid. But we don't know that until we've read all
the way to the bottom; when we hit the second m(), we would have to
record "crap, if I don't see an m() that is better than both the first
one and second one by the end, I'll have to bail." That means
accumulating state as we read the classfile that then has to be
validated at the end. Whereas, if we do the purely local thing, we
avoid this check. It's your call, but I didn't want to specify
something that had a cost to prevent something mostly harmless that
happens rarely.
Reflection
We need to specify what the reflection behaviour will be for
conditional members, as it may depend on how each JVM implementation
decides to represent species internally. The current reflection
behaviour is not well specified, and adding conditional members may
add more inconsistencies.
Yep....
JVMTI / class redefinition / class retransformation
This applies conditional members specifically, and also to
specializations in general.
What happens when a generic class is redefined? Will the whole
specialization nest require redefinition, or will the redefinition be
limited to redefined specialization? What about changes to a generic
class (template)? What happens if the restriction domain of a
conditional members changes?
We need to be careful with the terminology, which is hard because we
don't have good terminology yet.
We have "source classes" that are compiled into "class files", each of
which may define more than one "runtime type", which can be reflected
over with "runtime mirrors". All of these are called "classes" :(
Since there's no artifact for a specialization, I don't think we will
support redefinition for a specialization; we'd support redefinition for
a class FILE. And I think the logical consequence is that we then have
to redefine all extant specializations of that classFILE, since the
change could potentially affect all specializations.
*Any-interface*
Will only non-conditional methods be in the any-interface? Or will
conditional methods have a default implementation (e.g. throw
UnsupportedOperationException)?
Yes; the any-interface represents only total members.
Motivation
I think the API migration concern is compelling. But to handle that,
it's sufficient to be able to restrict members to the all-erased
specialization (or else require them to be total). This mechanism
could be very simple, and the resulting API differences seem to be
well justified by the compatibility requirements.
If that were only the case .... :(
Yes, the most egregious examples will be when a method is simply
unsuitable for non-reference parameters, and indeed a simpler "where
all-erased" criteria would fit the bill here, and it's a pretty
compelling place to want to stop.
Here's another migration concern. We want to migrate Streams such that
IntStream and friends can be deprecated. Pipelines like:
List<String> strings = ...
strings.stream().map(String::length)
can now result in a Stream<int> rather than a Stream<Integer> (yay!),
but in order to retire IntStream, there are some methods, like
sum/min/max, that are pretty hard to let go of.
Ideally I'd rather slice along a more abstract dimension (e.g., "where T
extends Arithmable"), but that's a whole new bag of problems that I'd
like to not couple to this one.
Let's say that we agree that the conditionality selectors should be "as
simple as possible" and we're going to work within the target use cases
to determine exactly what that means....
The current proposal is pretty simple, in that it is a pure subtyping
test, is amenable to a meet-rule, and doesn't include not-combinators.
But I agree its not the only place we could land, and we're open to
exploring this further.
In general I like the idea of a facility that allows for method
implementations to be specialized for known types. It can help to get
performance in cases where otherwise some abstraction would get in the
way by forcing us to treat things uniformly. And the spirit of such
specialization is that it should be (at least mostly) transparent, so
users shouldn't usually need to think about how the implementation is
selected in this case.
However, at the Java language level, conditional members have a
significant limitation here. Erasure means that it's only possible to
specialize for primitive types. There's no way to specialize for
String, for example.
Then there is type-specific functionality such as List<int>.sum().
This doesn't strike me as something that belongs in List, any more
than these do:
- List<String>.append()
- List<List<T>>.append()
- List<UnaryOpeartor<T>>.compose()
But due to erasure, these wouldn't be expressible. This kind of API
extension is limited to primitive types. (Later it could be done for
value types more generally, but I don't think it would be good to
allow users to special-case their own APIs for user-defined value
types, but not for T=String.)
Actually, this isn't true (but your general argument about "Is this the
language feature we're looking for" is still entirely valid.) We can
express this *up to erasure*, just as we can with everything else.
If we have, at the source level, a member conditioned on an erased
parameterization:
<where T=String>
void append(T t) { ... }
this is fine. We erase String to 'erased' in the classfile (so it
becomes "where erased T"), but the compiler can enforce that it is only
invoked when T=String, just as we do with:
<T extends Bar> T m(T t) { .... }
In the classfile, the arg and return types are Object, but the compiler
will reject the call if T != String. Where this runs out of gas is
overloads that are erasure-equivalent:
<where T=String>
void append(T t) { ... }
<where T=Integer>
void append(T t) { ... }
which the compiler will reject with the familiar, if frustrating, "can't
overload these methods, they have the same erasure" error. So I think we
can (if we want) extend this treatment to reference types, up to where
erasure gets in the way.
We would get the fluent style of call "(...).sum()", but I don't think
adding methods to List is the right way to get that, especially if it
will only work for primitive types, and if it means that users need to
think about sometimes methods of List more often than necessary.
I would, in fact, be disinclined to add such methods to List. But
Stream<T> -- which is about *computation*, not *data*, seems a different
case. In fact, in addition to the terrible performance that boxed
streams have, telling Java developers that they should sum a stream with
...reduce(0, (x,y) -> x+y)
was likely, we felt, to engender this response (warning, NSFW):
http://s.mlkshk-cdn.com/r/FTAF
Still open to better ideas, though.
