forax at univ-mlv.fr
Wed Nov 23 20:00:59 UTC 2016
----- 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`). 
> 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
> 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.
>  http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFileAccModule
More information about the jpms-spec-observers