[dp4]

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

[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

[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.

[rle125]

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

[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]

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]

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

[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.

[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.

[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.

[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).

[EISENMANN]

Thanks for the status update, I understand this position and can bring it up with my management.

More and more of your customers with active support will be forced to update to newer technologies, because more and more of their/our customers expects us to react to CVEs in timely manner in our products. The usual approach is to update to latest versions of external dependencies, which are hopefully still under maintenance. Therefore I am quite sure, you will be forced to face this issue one day (or kill the product, because you will decide, that it is not economically feasible).

Would it be possible to post an update in this chat if the situation changed on your side?

Thank you in advance

[Isomorphic]

IDACall does not depend on Spring. You can remove isomorphic_spring.jar, as previously explained, and IDACall will continue to function.

This means (again as explained previously) that you will not be able to use the Spring-specific features of SmartClient, such as invoking Spring beans from a DMI. If you were using such features, the process of replacing that functionality is straightforward. For DMI in particular, you just use a different lookup approach (maybe CDI) and call your Spring logic from there.

This whole process is going extremely slowly for you, and we cannot continue to give the same advice over and over in this thread, so if you want to get this resolved quickly, we would suggest purchasing either Support or some consulting hours. Thanks.

[vivek.more@nuance.com]

We can't remove IDACall approach as it is the only way we are using to handle built-in datasource operations.
So is there any workaround to use IDACall servlet without isomorphic_spring.jar? Or any other approach to handle datasource operations.

[Isomorphic]

Further update on this: this is really a giant mess. The main problem is, for every single third-party library we integrate with (Hibernate/JPA, Spring, many others), there are a ton of method parameters being passed that may be either javax.* or jakarata.* namespace.

We cannot simply drop support for all the versions of Java libraries that still use javax namespaces. The vast majority of enterprises are not looking to jump to Wildfly and/or Spring 6.0, and they depend on a variety of libraries that still expect javax namespaces in their method arguments.

This gives us two options:

1. take every call to any third-party library and put it behind a Java Reflection-based API so we can translate from javax to jakarta objects (or vice-versa) for every such API call

.. or ..

2. use a preprocessor to switch the namespaces (and make a bunch of other required changes) and deliver two different sets of SmartClient server framework .jars, along with two sets of Maven archetypes, sample environments, tools, etc

Incredibly, #2 may be better.

However, this does not make sense to do now - other customers (who have support) are asking for actual features, rather than needless churn necessitated by Oracle's intellectual property issues (yes, that's what this really is).

Currently, one of you is looking to very aggressively upgrade to a platform that has taken an extreme stance (Wildfly) and the other doesn't appear to have an actual issue as we understand it. As we hear from more customers, we will figure out how to prioritize this.

In the meantime, if you really need a solution right away, consider our Feature Sponsorship program if you need this work accelerated.