StandardCharset vs. StandardCharsets

[mark.reinhold at oracle.com]

2011/4/29 16:28 -0700, mike.duigou at oracle.com:
> Hi Mark;
> 
> I'm still not on your wavelength on this issue. For two reasons:
> 
> - Collections, Arrays, Channels, Objects aren't typically used for
> holding constants. They are either factories or collections of static
> utility methods. Only Collections actually defines any constants and
> those probably should have been put on the respective interfaces.

The constants in the Collections class weren't put into the related
interfaces because that would have polluted any implementing class or
subinterface with that constant name.  Constants in interfaces are
almost always a bad idea.

> The closest example seems to be PosixFilePermission (an enum)
> vs. PosixFilePermissions (static utility methods). The one difference
> is that PosixFilePermission is exhaustive, no other permissions are
> possible, vs the standard charsets where they represent only a subset
> of the available charsets. AFAIK even ME distributions have more than
> just the standard charsets.
> 
> For the standard charsets we've got no methods, only constants. Is
> Charsets preferred only because we want to avoid putting these
> constants on Charset itself for the previously cited performance
> reasons?

To be clear, I'm not objecting to the prefix "Standard" -- I'm just
arguing in favor of the suffix "s".

> - The standard charset constants do seem like an enum. The enumeration
> they belong to is easily named and part of the platform
> specification.

Conceptually, I agree.

>                Putting these definitions all into one class makes
> membership obvious--the standard charsets are the ones in this
> class.

Yep.

>        Charsets not defined in this class are not standard and thus not
> guaranteed to be available. (which is an interesting point, though the
> standard charsets are now visible in the platform we still don't
> provide a way to test whether a given charset is a member of the set of
> standard charsets).

That is an omission, but I wonder if anyone cares?  (A possible fix would
be to define StandardCharsets.ALL as a set containing all the singletons
defined in the class.)

> Barring history and implementation details I don't see why we wouldn't
> be defining these constants as an enum implementing Charset the same
> way as we've defined the jsr203 Standard* enums. The enum members would
> have more implementation than the jsr203 Standard* enums, ie. more than
> identity but almost all of that is constant data itself.

That would require Charset to have been defined as an interface, which
in turn would've added substantial complexity to the original design.
At any rate, it's water under the bridge at this point.

> What makes these constants *not* an enumeration?

If I have the enum type

    enum Foo { BAR, BAZ }

then the following assignment works:

    Foo x = Foo.BAR;

A statement of that form does not work with your StandardCharset class:

    StandardCharset x = StandardCharset.US_ASCII;

That's because StandardCharset is a final class and it does not extend
Charset, nor any other class or interface except Object.  It's just a
holder for a bunch of convenient constants, like java.util.Arrays and
j.u.Collections, etc.  The only difference is that it defines some
static constant values but no static methods.

In short, the hallmark of an enum type is that its members all have the
same type, and that type is the enum type itself.  This is true whether
you use the fancy enum construct from Java 5 or the older hand-coded enum
pattern.  Your StandardCharset class is not an enum type.

In order to fix this you could change StandardCharset to extend Charset,
but then you'd have to jump through some hoops to make the standard
charset implementation classes extend StandardCharset rather than plain
Charset, and you'd have to be careful not to allow anyone to extend
StandardCharset.  Offhand this seems to require moving the standard
charset implementations into the java.nio.charset package itself.

That's an awful lot of effort for just a handful of constants.

> I'm not trying to be difficult on this, honestly.

I understand.  Me neither.

- Mark