Thanks Brian!

On Fri, Sep 23, 2022 at 12:49 AM Brian Stansberry <brian.stansberry@redhat.com> wrote:

Thanks for all your initiative on this, Ladicek. It's great that we've gotten this in.

On Tue, Aug 30, 2022 at 6:08 AM Ladislav Thon <lthon@redhat.com> wrote:

Hi,

On Wed, Aug 17, 2022 at 10:37 AM Ladislav Thon <lthon@redhat.com> wrote:

On Tue, Aug 16, 2022 at 8:59 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:

On Tue, Aug 16, 2022 at 10:00 AM Ladislav Thon <lthon@redhat.com> wrote:

Upgrading in WildFly should be pretty straightforward, though I remember WildFly still ships its own `CompositeIndex`, which should really be replaced by the one in Jandex.

Is that a blocker to doing this upgrade, or just a good thing to do when we can?

Not a blocker, no, just requires changes -- the IndexView interface has a couple of new methods that must be implemented.

I found that `CompositeIndex` in WildFly actually doesn't implement `IndexView`, so no changes are necessary there.

WildFly can remove it and use Jandex's `CompositeIndex` whenever it wants -- including never, if there's no need.

Thanks; good to know. Intellij tells me we have 190 uses of CompositeIndex, so I expect we'll have to think about it a bit.

I wasn't there, so I don't really know, but I suspect WildFly's `CompositeIndex` predates (and was the inspiration for) the addition of `IndexView` and `CompositeIndex` into Jandex. If so, all usages of WildFly's `CompositeIndex` could be mechanically replaced by Jandex's `CompositeIndex` and everything should work, but as I mentioned before, there's really no need.

LT

 

 

 

I'm not sure if all WildFly components using Jandex have already updated to 2.4.3, though -- if not, it will be more interesting.

IC. That will take some research, given the hundreds of usages on https://mvnrepository.com/artifact/org.jboss/jandex/usages?sort=newest. Besides the ones you mentioned in your first post I see Hibernate ORM and Search and Ironjacamar on there. And then I got tired of clicking through pages.

Gotcha. Quickly looking at the projects you mention, Hibernate ORM and Search would require minuscule changes to migrate away from the deprecated methods in 2.4.3 (but none of that is in production code), IronJacamar is fine. For upgrading to 3.0, they all use the `Indexer` API, so a few more changes would be required in Hibernate ORM, while Hibernate Search and IrocJacamar would require a rebuild (they use `Indexer.index()`, which changed return type, which is binary incompatible, but they ignore the returned value, so the source will compile without changes).

OK, so good news here. I released Jandex 3.0.0 last week, with even better compatibility than before. Using David's Bridger Maven plugin, I was able to restore binary compatibility for 3 out of 4 methods that change return type in Jandex 3.

Specifically for `Indexer.index()`, a synthetic bridge method exists with the `ClassInfo` signature, except it always returns `null`. This means that `Indexer.index()` callers that used to ignore the return value are directly compatible with Jandex 3.0.0 (including Hibernate Search and IronJacamar). For Hibernate ORM, the necessary changes are very small and PRs are up (see https://hibernate.atlassian.net/browse/HHH-15466). Those PRs will make Hibernate ORM compatible with Jandex 3.0, while it is still built against Jandex 2.x. So that upgrade can go in independently.

There's also a PR for WildFly Core, which is basically ready to go, and a PR for full WildFly which depends on Hibernate ORM (see above) and SmallRye OpenAPI. PRs are also up, but SmallRye OpenAPI can't be made compatible with both Jandex 2.x and 3.0 at the same time, so this upgrade will have to be in the same commit as the Jandex upgrade.

That's probably all. I've had green results for `mvn clean install -DallTests` on both WildFly Core and full WildFly locally, so I think it should be smooth.

LT

 

I can do the necessary changes, but I don't know what component versions target WildFly 27 and how their release plans look like.

We probably should try updating to 3.0.0-RC1 immediately and see what breaks... Except I see 3.0.0-RC1 never made it to Central, because of an annoying Maven feature/bug (where if the last module in the build is configured to not deploy, nothing deploys). Funny that no one complained :-) I've released 3.0.0-RC2, it's in Central now, so let's use that.

LT

 

LT

On Tue, Aug 16, 2022 at 4:37 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:

Hi Ladislav,

Thanks for this thorough update. It came in when I was on PTO and I read it but wasn't inclined to reply then. :) And thanks as well for the WFLY-16569 updates.

Do you have a sense for when Jandex 3.0 will go final? We're planning for WF 27 Beta1, likely in early September, and this seems like a good move to make in that release, if it will be ready.

Cheers,

Brian

On Tue, Jun 28, 2022 at 4:19 AM Ladislav Thon <lthon@redhat.com> wrote:

Hi,

last week, I've released Jandex 3.0.0-RC1, and yesterday, I've released Jandex 2.4.3.Final. (A corresponding release of the Jandex Maven plugin is on its way to Central as we speak.)

There's a few breaking changes in Jandex 3.0 and the 2.4.3 release is supposed to make migration easier (or at least require less coordination).

Specifically, Jandex 2.4.3 deprecates these 2 methods because they have a different return type in 3.0:

- ClassInfo.annotations()
- MethodInfo.parameters()

Replacements are, respectively:

- ClassInfo.annotationsMap()
- MethodInfo.parameterTypes()

These 2 replacement methods are present both in Jandex 2.4.3 and 3.0.0[-RC1].

Additionally, certain usages of MethodInfo.parameters() can be simplified using MethodInfo.parametersCount() and parameterType(int). These 2 methods are also present both in 2.4.3 and 3.0.0[-RC1].

Updating to Jandex 2.4.3 is safe, because it's fully compatible with previous releases. A project that uses Jandex 2.4.3 and avoids deprecated methods is almost fully _binary_ compatible with Jandex 3.0 (almost because of the return type change in Indexer.index(), but that should only affect a very small number of existing code paths).

I went through the projects that I know use Jandex and made the necessary changes myself and will submit PRs in the coming days. These projects are:

- Quarkus, including ArC and RESTEasy Reactive
- Gizmo
- Weld
- SmallRye OpenAPI
- SmallRye Async API -- no changes required
- SmallRye GraphQL
- WildFly Core -- no changes required, just updating Jandex
- WildFly Full
- RESTEasy (classic) -- no changes required

If you maintain (or know about) some other project that uses Jandex, feel free to ping me, I'll be happy to help.

Note that there are more changes in Jandex 3.0. All the details can be found in the issue tracker: https://github.com/smallrye/jandex/milestone/3 For your convenience, here's a summary of what's coming in Jandex 3.0 and is technically a breaking change, even though most of them won't likely affect anyone:

- moved Jandex to SmallRye
- bumped minimum Java version to 8
- regularized access to annotations from AnnotationTarget
  - this is why ClassInfo.annotations() needs to change the return type
  - there are methods to access annotations without considering nested annotation targets, too!
- regularized access to method parameters from MethodInfo
  - this is why MethodInfo.parameters() needs to change the return type
  - common parameter-accessing methods on MethodInfo ignore mandated/synthetic parameters
  - special methods exist to access all parameters, including mandated/synthetic
- added a new kind of types, TypeVariableReference, to faithfully represent recursive type variables
- changed Indexer.index() to return void (instead of ClassInfo)
  - required to be able to post-process an index during Indexer.complete()
- added indexing of class-retained annotations
  - Jandex 2 only indexes runtime-retained annotations
  - AnnotationInstance.runtimeVisible() can be used to distinguish
- added a few methods to IndexView
  - navigation for interfaces: getKnownDirectSubinterfaces(), getAllKnownSubinterfaces()
  - navigation for packages: getClassesInPackage(), getSubpackages()
  - breaks projects that implement this interface on their own (which I know at least WildFly and Quarkus do)
- removed IndexReader.getDataVersion()
  - it's been incorrect anyway, and I couldn't find anyone using it

When Jandex 3.0 goes final, which I hope happens in a few weeks, I will publish an announcement with all details on the SmallRye blog. In the meantime, I'll use the previously mentioned projects (and their test suites) to verify that Jandex 3.0 doesn't contain any hidden surprises.

Any questions? Ideas? My inbox and the Jandex issue tracker are always open :-)

Thanks,

LT

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

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His