[Isomorphic]

This comment is very strange.

Are you aware that this transition to Jakarta offers no functional benefit and the reason for it is Oracle’s losses in the courts?

That’s what this is - this is not innovation and not the “latest and greatest”, this is just everyone going through a compatibility nightmare because of Oracle’s legal maneuvering.

Meanwhile, we are actually innovating: you should look at Reify, also, stay tuned for announcements around AI.

Anyway, if there is some specific use case that you believe Wildfly will address, feel free to explain the use case and we can offer an approach that does not involve enthusiastically embracing Oracle’s courtroom losses.

Meanwhile, we have to maintain cross-version compatibility, because that’s what most customers require. But, if you are really in need, you can accelerate development of a compatibility layer that no other customer has requested- via Feature Sponsorship.

Finally, note that there are no security vulnerabilities that actually apply to our product and there has only been one legit vulnerability in our 20+ year history, and that was minor (information exposure only).

[Crack]

SmartClient (I'm using the non-GWT version) may be also used as a part of an application, working together with other libraries, and that's how we are using it at my company.

The situation with javax/jakarta is really annoying, and incompatible dependencies are blocking upgrades to current versions of web frameworks, or starting new projects using them. For us it means being stuck with Spring Boot 2.7, which currently isn't a problem, but will start being one next year.

[eliasbalasis]

SmartClient (I'm using the non-GWT version) may be also used as a part of an application, working together with other libraries, and that's how we are using it at my company.

The situation with javax/jakarta is really annoying, and incompatible dependencies are blocking upgrades to current versions of web frameworks, or starting new projects using them. For us it means being stuck with Spring Boot 2.7, which currently isn't a problem, but will start being one next year.

It has just become a blocking issue for us.
We have to upgrade to SpringBoot 3.x sooner than expected and we are finding SmartGWT 13.0-p20230315 not being compatible.

We understand, this is a derivative of intellectual property battle, but it does not stop the march of 3rd party dependencies from needing an alternate build from Isomorphic.
We appreciate it is probably a big pain for Isomorphic having to support the "jakarta" flavours, but ultimately Isomorphic must adapt, or suffer consequences as people will eventually stop using the Isomorphic solutions, ourselves included.
I cannot reveal the name of the global organisation I am working for, but we have a portfolio of UI applications based on SmartGWT whose future development is now becoming more and more compromised.

[vvijayarajan]

Hi,

Was this issue addressed for Smartclient (not smartGWT)?
We have to upgrade to tomcat 10 - and v10 doesn't support javax servlet, and have to move to jakarta servlet. Can you please help? Thanks.

[Isomorphic]

Please see post #12 above:

https://forums.smartclient.com/forum...955#post269955

We can't go back and switch an existing release to Jakarta. Overall, there are still many popular third-party libraries out there that have not migrated, so it's not just our software involved (that would be easy), but our dependencies and integrations.

What we would recommend is:

1) postpone your Tomcat 10 migration for at least one major release of your software. Tomcat 9 to Tomcat 10 was almost entirely just switching namespaces - there were almost no new features. There is no reason in terms of application functionality, or in terms of security, reliability, or any other factor, to move immediately.

You may have some very specific, functional reason to move to Tomcat 10, but with most customers we've talked to, it turns out to just be a desire to be on the most recent version, with zero functional reasons for the move. It is definitely worth talking about internally.

2) engage with our consulting arm to figure out the best approach. There are binary transformers that may work, and your situation is likely unique with respect to dependencies that you may indirectly depend upon that don't use the jakarta namespace - we can help you sort all that out, but not just via forums