Stephen's comments on Value Types

[Thomas W]

Hi Stephen,

Interested by the things you say. Very many of them are valid, but I also
have a different angle on some of them?

Consider an OSS library released for
>
JDK8 that has a method process(Object). The intent is that the method
> accepts anything, we don't care what the type is. When used with
> JDK10/11 it still accepts anything, except that instead of a small,
> known number of types being boxed (for which the library might have a
> process(int) overload, there are now *lots* of boxing operations.
>

Since "Values" are currently objects & must be processed as reftypes, we
can say this is similar to the current situation. So I do not feel this is
too bad.

I guess one thing to look at, is that framework code should ideally not be
repeatedly creating the boxes at many levels -- in such a situation, it
might be slower. For most cases, I expect performance would likely be
similar.

Of course the situation with process(List<?>) is worse again. Here I
> want to accept any list, I don't care what type. In JDK 10/11 it now
> won't even work. Callers won't be able to pass in a List<valuetype>.
> (As opposed to IntList which can be passed in providing it extends
> List<Integer>, and which could be handled specially internally within
> process(List<?>) using instanceof if necessary).


This is why Gavin and myself are considering List<Any>, with List<Any> to
be a supertype of both List<Object> and List<int>. If it could be achieved,
this would give commonality.


> Note that while the method process(List<?>) could be fixed to work by
> using <any T>, OSS
> libraries don't work like that - they can't just have a new release
> as they have to still support developers who can't upgrade.
>

The <?> open wildcard is currently defined to mean '? extends Object', and
could therefore be redefined to mean '? extends Any' without any
source-code change.

Compatibility would obviously still be an important issue, but some of the
difficulties might be reduced.

One question is whether 'Any' is even different (in the VM) from Object --
if it's fully assignable without casting, ArrayList<?> can implicitly
encompass Any and 'Object item' can still be valid.


> TLDR, Object is *already* the Any type, and List<?> is *already* the
> List<Any>. Breaking that is a big problem for me.
>

I'm also interested in Any as a "compiler fiction" translating to Object in
the VM, but specializable. I see the (very close) relationship between
Object and Any as something that works in our favor!


Some other thoughts and vague ideas as I've been mulling on this.
>
> Separating synchronization from Object seems like a Good Thing.
> Possible approach: add interface Lockable with locking methods from
> Object. Remove methods from Object using JDK 9 as a stepping stone via
> deprecation. Use classloading/module linking tricks to add Lockable
> interface to all classes that were compiled in JDK 8 or earlier.
>

I'm suggesting the same thing -- but by abstracting 'Any' without these,
above. Any can then be ancestor to primitives/ value-types and is easily
marked to specialize.

'Any' has to be present in bytecode I think, but in the VM could
potentially be flattened to just implement as Object. This would avoid need
to for check-casts casting from Any -> Object.


> Fixing up the List.remove(int) vs List.remove(Object) problem seems
> like a Good Thing. But its a more general problem: Why not just rename
> the method? Use JDK 9 module linker step to bind the old method name
> to the new method name. (Being able to rename methods and be backwards
> compatible would be a major gain for all large Java systems). Same
> renaming strategy applies to many of the problem cases under
> discussion.
>

Interesting idea, not qualified to comment though.


> Instead of value types, some form of "packed objects" seems like an
> alternative that might have less issues. By packed objects I mean
> where the state of the child object is embedded in the parent object.
> (Child objects are not seen by gc, have no identity and are copied
> where necessary, Null handled with bit flag where necessary. Variables
> extended to be able to point to a child within a parent or an item in
> an array. And yes, this is super-vague, and could be worse than value
> types).
>

Just sounds like Value Types to me, but more hacky. I actually feel value
types are good at this point, I'm not really pessimistic about performance,
we just desire a good solution to Collections/ specialization and
everything will work out fine.


Regards,
Thomas Whitmore