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