Java SE JSR 250 annotations module renamed to

Guillaume Smet guillaume at
Mon Feb 13 15:43:36 UTC 2017

Hi Rémi,

(replied to you but it's more of a general answer to the consensus)

On Mon, Feb 13, 2017 at 3:59 PM, Remi Forax <forax at> wrote:

> so there are 3 cases:
> - your application is modular, in that case one module defines a
> dependency (with requires) on a module* containing the JSR 250 annotation
> and you have nothing to do.
> - your application uses a container that provides a jar containing the JSR
> 250 annotations in the classpath, you still have nothing to do.
> - your application uses the classpath and do not provide any jars
> containing the JSR 250 annotations, you can use --add-modules but be aware
> after some point the JDK will stop to provide this jar (the module is
> marked deprecated).
> perhaps another way to see this is to think that we made a mistake to
> include parts of the Java EE modules inside the JDK when releasing Java 6,
> and we are trying to fix that mistake now, which means removing those
> packages but because we are Java instead of removing them now, we made them
> accessible under a flag and we will remove them in Java 10.

I can understand this point of view but...:
- if we are willing to deprecate this, maybe it would be better not to let
the --add-modules <your-common-annotations-module-name-here> fix spread in
all the projects everywhere and maybe a clear statement about the future of
it would be nice - I may have missed it though - see what they did for
pax-exam for instance:
for instance;
- from what I understand, there are 2 types of annotations in this module:
@Generated and annotations related to injection/lifecycle. While I would
agree to add a dependency for the latter, I find it pretty weird to add a
dependency for @Generated. Or maybe, we should just say to the Java world
"don't use the @Generated annotation when you generate code and please
upgrade all the tooling out there to not depend on it".
- fixing a mistake is always a good thing but as stated by Andrew, they
were advertised as common annotations and part of the JDK so it's
definitely a big change if they get deprecated and removed
- even as a temporary workaround, it's really weird to have to require a
module named for that. It does not really make sense
from an end user perspective.
- as I understand it, the idea is that the new
module should basically be considered a private one and should not really
be used anywhere thus its name?
- the only future-proof solution proposed is to depend on the JSR 250 API
jar - which doesn't look very cool just for @Generated - or get all the
Java tooling out there to remove the usage of the @Generated annotation?

Creating a new @Generated annotation will take years to be used in the real
world, considering everyone will want to keep the backwards compatibility
with Java 8 for a while.

Not sure there's an easy way out but I think these are real concerns that
should be addressed somehow.


More information about the jigsaw-dev mailing list