Fwd: The Future of Jandex

[Ladislav Thon]

Hi,

Jandex 2.4.0.Final was released on Wed (with a couple of bigger changes that are technically breaking, but not for ordinary Jandex API callers: 3 new methods on `IndexView`, new storage format version) and now it’s time to talk about $SUBJ.

As you might have noticed, I’m slowly taking over Jandex maintenance from Jason. We have agreed that it’s time to do a 3.0 release with some changes that are visibly breaking for everyone. Hence this wide distribution.

You can find the current plan for 3.0 here: https://github.com/wildfly/jandex/milestone/3, but I’ll repeat the important points here:

- Move to SmallRye, both on GitHub and in the Maven coordinates space. The `groupId` will change, but the package name will not. This has the potential to cause nondeterministic classpath, so configuring Enforcer to ban `org.jboss:jandex` will be a good idea.
- Move to Java 8 as the base.
- Uniform API to access annotations. Currently, each `AnnotationTarget` has a slightly different set of methods to access annotations, and I’d really like to unify that.
- `Indexer.index()` will no longer return `ClassInfo`. The very existence of this return type prevents doing post-processing in `Indexer.complete()`, which we’d need to do to properly resolve some recursive generic declarations. The recently introduced `Index.of()` methods are a nicer way to quickly construct an index for test purposes.
- Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be visible in the index. Hopefully this is just an FYI.
- I’d like to merge the Maven plugin into the main codebase, and hopefully also the `typeannotation-test` artifact.

Also, Jandex will use (at this point, more like continue using) GitHub Issues for issue tracking. The JANDEX project in Red Hat JIRA will be decommissioned.

Of course, the purpose of this email is to let you voice any concerns you may have. Feel free to either reply to this email, or file an issue in the existing Jandex repo on GitHub (it will be transferred to SmallRye, so nothing will get lost), or add a comment to one of the existing issues.

Thanks,

LT

[Martin Kouba]

On 27. 08. 21 10:21, Ladislav Thon wrote:
> Hi,
>
> Jandex 2.4.0.Final was released on Wed (with a couple of bigger changes
> that are technically breaking, but not for ordinary Jandex API callers:
> 3 new methods on `IndexView`, new storage format version) and now it’s
> time to talk about $SUBJ.
>
> As you might have noticed, I’m slowly taking over Jandex maintenance
> from Jason. We have agreed that it’s time to do a 3.0 release with some
> changes that are visibly breaking for everyone. Hence this wide
> distribution.
>
> You can find the current plan for 3.0 here:
> https://github.com/wildfly/jandex/milestone/3

> <https://github.com/wildfly/jandex/milestone/3>, but I’ll repeat the

> important points here:
>
> - Move to SmallRye, both on GitHub and in the Maven coordinates space.
> The `groupId` will change, but the package name will not. This has the
> potential to cause nondeterministic classpath, so configuring Enforcer
> to ban `org.jboss:jandex` will be a good idea.

Hm, so `io.smallrye:jandex` is the new GA? I'm asking because some
smallrye projects use the `smallrye-` prefix in the artifactId and some
use a more specific groupId, e.g `io.smallrye.config`.

> - Move to Java 8 as the base.

+1

> - Uniform API to access annotations. Currently, each `AnnotationTarget`
> has a slightly different set of methods to access annotations, and I’d
> really like to unify that.

+1

> - `Indexer.index()` will no longer return `ClassInfo`. The very
> existence of this return type prevents doing post-processing in
> `Indexer.complete()`, which we’d need to do to properly resolve some
> recursive generic declarations. The recently introduced `Index.of()`
> methods are a nicer way to quickly construct an index for test purposes.

Note that in Quarkus we don't use the Indexer.index() for test purposes
but to lazily index classes on the class path that are missing in the
index built from the app.

> - Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be
> visible in the index. Hopefully this is just an FYI.

Hm, I'm +1 on this but wouldn't this result in much bigger indexes?

> - I’d like to merge the Maven plugin into the main codebase, and
> hopefully also the `typeannotation-test` artifact.
>
> Also, Jandex will use (at this point, more like continue using) GitHub
> Issues for issue tracking. The JANDEX project in Red Hat JIRA will be
> decommissioned.
>
> Of course, the purpose of this email is to let you voice any concerns
> you may have. Feel free to either reply to this email, or file an issue
> in the existing Jandex repo on GitHub (it will be transferred to
> SmallRye, so nothing will get lost), or add a comment to one of the
> existing issues.
>
> Thanks,
>
> LT
>

> _______________________________________________
> wildfly-dev mailing list -- wildf...@lists.jboss.org
> To unsubscribe send an email to wildfly-...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic

[Ladislav Thon]

pá 27. 8. 2021 v 12:47 odesílatel Martin Kouba <mko...@redhat.com> napsal:

On 27. 08. 21 10:21, Ladislav Thon wrote:
> - Move to SmallRye, both on GitHub and in the Maven coordinates space.
> The `groupId` will change, but the package name will not. This has the
> potential to cause nondeterministic classpath, so configuring Enforcer
> to ban `org.jboss:jandex` will be a good idea.

Hm, so `io.smallrye:jandex` is the new GA? I'm asking because some
smallrye projects use the `smallrye-` prefix in the artifactId and some
use a more specific groupId, e.g `io.smallrye.config`.

Using `io.smallrye:jandex` would be my preference, but I can be convinced otherwise :-) Feel free to add a suggestion to https://github.com/wildfly/jandex/issues/124.

 

> - `Indexer.index()` will no longer return `ClassInfo`. The very
> existence of this return type prevents doing post-processing in
> `Indexer.complete()`, which we’d need to do to properly resolve some
> recursive generic declarations. The recently introduced `Index.of()`
> methods are a nicer way to quickly construct an index for test purposes.

Note that in Quarkus we don't use the Indexer.index() for test purposes
but to lazily index classes on the class path that are missing in the
index built from the app.

I'm not totally sure what you mean here, but would `Indexer.index()` returning `void` prevent you from doing that? You can still construct a full index and then lookup the class form it, no?

(From Jandex perspective, indeed we can't assume we'll be given a complete classpath. So `Indexer.complete()` doing post-processing may still be unable to fully resolve everything. Such is the fact of life.)

 

> - Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be
> visible in the index. Hopefully this is just an FYI.

Hm, I'm +1 on this but wouldn't this result in much bigger indexes?

I don't think it would be _much_ bigger, mostly because there isn't much runtime-invisible annotations out there. Mike Edgar, who is contributing the feature, says the memory impact is minimal. I haven't personally done any measurement. Feel free to look at and/or comment in https://github.com/wildfly/jandex/pull/129.

Thanks for your comments!

LT

[Martin Kouba]

On 27. 08. 21 13:16, Ladislav Thon wrote:
> pá 27. 8. 2021 v 12:47 odesílatel Martin Kouba <mko...@redhat.com

> <mailto:mko...@redhat.com>> napsal:

>
> On 27. 08. 21 10:21, Ladislav Thon wrote:
> > - Move to SmallRye, both on GitHub and in the Maven coordinates
> space.
> > The `groupId` will change, but the package name will not. This
> has the
> > potential to cause nondeterministic classpath, so configuring
> Enforcer
> > to ban `org.jboss:jandex` will be a good idea.
>
> Hm, so `io.smallrye:jandex` is the new GA? I'm asking because some
> smallrye projects use the `smallrye-` prefix in the artifactId and some
> use a more specific groupId, e.g `io.smallrye.config`.
>
>
> Using `io.smallrye:jandex` would be my preference, but I can be
> convinced otherwise :-) Feel free to add a suggestion to
> https://github.com/wildfly/jandex/issues/124

> <https://github.com/wildfly/jandex/issues/124>.

>
> > - `Indexer.index()` will no longer return `ClassInfo`. The very
> > existence of this return type prevents doing post-processing in
> > `Indexer.complete()`, which we’d need to do to properly resolve some
> > recursive generic declarations. The recently introduced `Index.of()`
> > methods are a nicer way to quickly construct an index for test
> purposes.
>
> Note that in Quarkus we don't use the Indexer.index() for test purposes
> but to lazily index classes on the class path that are missing in the
> index built from the app.
>
>
> I'm not totally sure what you mean here, but would `Indexer.index()`
> returning `void` prevent you from doing that?

Absolutely not, we build the temporary index anyway. I'm just saying
that we use this method in production, not just for test purposes ;-)

> You can still construct a
> full index and then lookup the class form it, no?
>
> (From Jandex perspective, indeed we can't assume we'll be given a
> complete classpath. So `Indexer.complete()` doing post-processing may
> still be unable to fully resolve everything. Such is the fact of life.)
>
>
> > - Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`)
> will be
> > visible in the index. Hopefully this is just an FYI.
>
> Hm, I'm +1 on this but wouldn't this result in much bigger indexes?
>
>
> I don't think it would be _much_ bigger, mostly because there isn't much
> runtime-invisible annotations out there. Mike Edgar, who is contributing
> the feature, says the memory impact is minimal. I haven't personally
> done any measurement. Feel free to look at and/or comment in
> https://github.com/wildfly/jandex/pull/129

> <https://github.com/wildfly/jandex/pull/129>.

>
> Thanks for your comments!
>
> LT