[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

[rle125]

Checking to see if there have been any updates on this issue. We're also looking to upgrade to Tomcat 10 and would like to know if the recommendations above still apply.

[Isomorphic]

As far as the reason to ask this question, we assume that you are being required to move to more recent versions, not for valid functional or security reasons, but simply because it is "the latest".

If, instead, there is an actual functional or security concern, please do post it here (a separate thread is better) and we will resolve it, quickly.

As far as what we're going to do about this namespace shift (which again is due to Oracle losing a lawsuit, and has nothing to do with either functional or security concerns), the current plan is to do a namespace shift with the 14.0 release, which will be essentially the 13.1 release but with more features enabled and with this namespace shift.

Customers who do not want to do this meaningless, non-functional namespace shift will, it seems, end up having to ask us to port 14.0+ features back to the earlier versions, and end up absorbing that cost. We'd like to apologize in advance for this; we would like to offer a better option, but this seems to be the only thing we can do, given Oracle's losses in court.

Whether you want the "new" namespaces or not, if you want to be involved with this process, and get pre-releases of the changed software you can use to test your application, and so forth, please contact us about ways to be involved. If you are a paying customer with Support, we would be happy to keep you updated as to the latest progress in dealing with this issue, if you wish.

[rle125]

Is there a forecasted date of the SmartGWT 13.1 release with the namepsace shift?

[Isomorphic]

Not a public date, no. Also note that it will be 14.0 that does the namespace shift, but it's essentially the same codebase, other than the namespace swap.

If you want more visibility, and guarantees of more control over how the swap is done (for example, making sure that the specific Spring and Hibernate features you need are preserved, given that both frameworks have also randomly reorganized features in the meantime), you should use our Feature Sponsorship program to get involved.

[Blama]

Hi Isomorphic,

here is a blogpost by Tomitribe, they share your migration pain and discuss some approaches, none of which seem to be fun, some just less annoying than others:
https://www.tomitribe.dev/blog/movin...rta-namespace/

Perhaps it helps or is at least an interesting read.

Best regards
Blama

[dp4]

Isomorphic Could you let us know timeframe when 14.0 will be released for namespaces issue.