Module-system requirements
David M. Lloyd
david.lloyd at redhat.com
Tue Mar 17 13:19:36 UTC 2015
On 03/16/2015 03:46 PM, mark.reinhold at oracle.com wrote:
> 2015/3/11 2:46 -0700, david.lloyd at redhat.com:
>> On 03/11/2015 08:23 AM, David M. Lloyd wrote:
>>> On 03/09/2015 03:56 PM, mark.reinhold at oracle.com wrote:
>>>> ...
>>>>
>>>> Either way, this use case suggests a new requirement for the Development
>>>> section:
>>>>
>>>> - _Annotation digests_ --- When packaging a module into an artifact it
>>>> must be possible to augment its definition with a summary of all of
>>>> the type- and package-level annotations that are present in the
>>>> module, together with an indication of the types and packages to
>>>> which each annotation applies. This digest must be easily readable
>>>> from module artifacts, and at run time those parts of it related to
>>>> annotations retained for run time must be available through an
>>>> appropriate reflective API.
>>>>
>>>> Comments?
>>>
>>> If we're looking to extend this into the domain of Java EE annotations
>>> (for example), we'd also have to add method and field annotations to the
>>> list.
>>
>> Actually this is not true after all. Other than possibly examining
>> constructor annotations to decide if a class is a CDI managed bean that is.
>
> Do such constructor annotations really need to be in the digest? Or
> do such classes already carry class-level annotations to indicate
> that they're to be managed by the CDI framework?
By my understanding, such classes do not need class-level annotations;
however I must say that the interactions between CDI, the EE platform
spec, the injection spec, and the common annotations spec are (in my
opinion) murky at best (and are often the subject of much internal
debate), so this might be a better question for the Java EE 7 EG.
>>> And SE 8 type annotations might add some strange color to this as
>>> well.
>
> Hrm. I suppose we could summarize all the annotations in a module,
> regardless of the kinds of elements they're applied to, but is that
> overkill?
Yeah probably; maybe what is needed is an @Indexed meta-annotation...
We have a project which specifically creates annotation indexes for JARs
for use by our containers, including member and type annotations. Even
though our developer spent a great deal of time and effort to minimize
the size of the generated indexes, they are still often quite large with
respect to the original classes (on the order of 15% uncompressed for a
couple JARs that I can see test results for, though by storing the index
in the JAR we can shrink the total growth to under 10%). Indexing
rt.jar from a recent JDK resulted in a file size of 4.1 MB. If a more
optimal-than-JAR format is established, especially one which flattened
the constant pool across all classes, the relative percentage would
probably be even larger. Having an @Indexed annotation would ease this
quite substantially though; most of the annotations in the index aren't
actually directly useful or relevant to the consumers of the index.
--
- DML
More information about the jpms-spec-observers
mailing list