Why Arrayish implements Cloneable?
glen at organicdesign.org
Wed Apr 27 20:36:27 UTC 2016
Adding Serializable (and/or Cloneable) to Arrayish makes it harder to
extend. Not every implementation of Arrayish necessarily wants to
allow serialization or cloning. Can you have an Arrayish interface
and some sub-interface like SerializableArrayish extend it for your
purposes? Then people can easily extend Arrayish without the added
What about making the type of your new primitive array Arrayish &
Serializable? I haven't used intersection types in Java so that may
be more trouble than it's worth, but I thought I'd throw it out there.
On Wed, Apr 27, 2016 at 4:06 PM, John Rose <john.r.rose at oracle.com> wrote:
> A2.0 entails splitting current types of the form <any T> T in into interfaces and implementations.
> That is, in a future VM we will have polymorphic, generic interfaces (Arrayish, etc.) and built-in
> linearly stored implementations of the same, what we are familiar with as "classic arrays".
> We *could* deem that either or both of the marker interfaces Serializable and Cloneable on all T
> are, in fact, implementation artifacts, limited to classic arrays, and not pushed into the generic APIs.
> In fact, on second thought, we *should* do this for Cloneable, since it is not an API. The generic
> method <any T> clone()T is part of the array API, but it is not at all dependent on Cloneable.
> What about Serializable? Perhaps we can mandate (another way) that all Arrayish's will be
> serializable, without putting in the marker interface. But I think that's a losing battle.
> It might in fact be the case that many (or even all?) array implementations would chose to
> include both Cloneable and Serializable, but that's not necessarily true in all possible worlds.
> — John
> P.S. I was reading Smullyan on modal logic last night, hence the modal connective in that
> last statement.
> On Apr 27, 2016, at 7:45 AM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
>> Currently, the array classes (int.class, String.class) are totally magical and spring into existence when referenced. They all happen to have some common supertypes (Cloneable, Serializable).
>> This patch moves things forward incrementally (see John's talk on Arrays 2.0, http://medianetwork.oracle.com/video/player/1785452137001) by providing all arrays with a real supertype, Arrayish, which exposes element accessors. This allows, for example, abstraction over array types (<T extends Arrayish>), as well as being a precursor to some other cool stuff.
>> On 4/27/2016 10:32 AM, Paul Benedict wrote:
>>> Oh, okay ... so basically when you let the native "any" type be boxed, you're exposing the same functionality through an interface.
>>> On Wed, Apr 27, 2016 at 9:25 AM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>> Because array types (int, String) *already* implement
>>> Cloneable and Serializable.
>>> On 4/27/2016 10:18 AM, Paul Benedict wrote:
>>> I only ask because Cloneable is typically looked at as a poor
>>> mechanism for
>>> duplicating objects. That's the sentiment, anyway, widely
>>> popularized by
>>> the Effective Java book.
Glen K. Peterson
More information about the valhalla-dev