Proposal: #ClassFileAccModule

[Remi Forax]

fair enough,
i agree.

Rémi

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Mardi 22 Novembre 2016 17:48:35
> Objet: Proposal: #ClassFileAccModule

> Issue summary
> -------------
> 
>  #ClassFileAccModule --- The `ACC_MODULE` constant is currently
>  specified to have the value 0x8000.  This is the last available bit
>  remaining across all of the various `access_flags` fields of a class
>  file, and thus should be reserved for some unspecified future purpose
>  where it may be useful to use the same value in all such fields.
>  Alternative candidates for `ACC_MODULE` include 0x0040 (overlaps with
>  `ACC_VOLATILE` and `ACC_BRIDGE`) and 0x0080 (`ACC_TRANSIENT` and
>  `ACC_VARARGS`). [1]
> 
> Proposal
> --------
> 
> Do not change the value of this constant.
> 
> The high-order bits of the `access_flags` field have long been used to
> characterize the unusual, non-class nature of some class files:
> 
>  - `ACC_ANNOTATION` (0x2000) indicates an annotation type, even though
>    `ACC_ANNOTATION` does not apply to fields or methods, and
> 
>  - `ACC_ENUM` (0x4000) indicates an `enum` type, even though `ACC_ENUM`
>    does not apply to methods.
> 
> A binary module descriptor is a new kind of unusual class file, hence we
> have done the obvious thing and allocated the high-order bit 0x8000 for
> `ACC_MODULE`.
> 
> We could try to be more clever here, but that would require attempting
> to predict the future.  There are still plenty of other ways to encode
> potential future features; a value class could, e.g., be indicated by
> 0x0100.  In the worst case the `access_flags` field could simply be made
> wider in some future version of the class-file specification.
> 
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFileAccModule