Migrate from javax to jakarta

[yamass]

People are more and more migrating to the newer EE versions (Jakarta). Jetty 11 has been out for more than a year and depends on jakarta. Spring 6 (release data: Q4 2022) will depend on jakarta. https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

I suggest you introduce two versions of postmark-java: One depending on javax and one on jakarta, maybe on two different branches.

[lbenedetto]

+1 This would be greatly appreciated.
Though it seems Postmark may have abandoned this project, no commits in a long time...

[yamass]

@ibalosh I am quite unhappy about how this pull request got closed without any explanation. Or was it just a mistake?

[ibalosh]

Hi @yamass

thank you for contacting us back, it seems that it was an oversight from our side.
We will see to work on updating jackson soon. Regarding the migration to Jakarta that is something that we can't promise to be checking out soon. The library is backwards compatible to Java 8, and we are trying to keep it so, so that older codebases can use the library too. Move to jakarta would require deeper compatibility investigations.

Igor

[mdindoffer]

Hello @ibalosh ,

Jakarta EE 9.1 is fully compatible with Java 8. Only the Jakarta EE 10 spec is targetting JDK 11 as a baseline, and that one has not been even released yet afaik. See link for an overview. Your worries about Java 8 compatibility are unfounded. Not to mention that Java 8 is really outdated and the overlap of projects using an out of date (and EOL) Java together with latest 3rd party library is miniscule.

The only thing you are doing by not accepting this PR is blocking people on a modern Jakarta EE stack from using this library, ironically reducing your codebase reach and compatibility.

Thirdly, as the OP mentioned, you can always just produce two maven artifacts built from two branches if you want to temporarily keep even the niche audience happy.

Please reconsider your decision.

[mdindoffer]

@ibalosh Ping, please do something about the worrisome state of this library.

[ibalosh]

Hi @mdindoffer

we do understand your concerns, and we are going to consider working on this update, but we can't promise that we can work on it right away and we need to discuss it with the team. We are working on updates to the library to make sure it uses stable versions of dependencies and it uses the latest endpoints of our Postmark API.

This update however would require though bit more research.

For some reason I can't reopen this pull request, so I suggest to create a new issue or pull request. Feel free to create one and add upvotes, additional comments there.

[yamass]

Hi @ibalosh, seems to have something to do with the master branch being renamed to main. I'll re-create the pull request.

Note that we have been using our adaptation (PR) in production since April.

[yamass]

Hi @ibalosh, seems to have something to do with the master branch being renamed to main.

Or maybe just the many new commits on main...

Anyway, here is the new pull request: #47

[ibalosh]

thank you @yamass !

Oh good, to hear! You haven't seen any issues with the change, rest client and parser (jersey/jackson) work with no issues?

(We do use javax only on couple of places - client and multivalued map, so we might be able to remove it easily. I will see to check the codebase soon as I have some free time)

[mdindoffer]

@ibalosh FWIW We have been using a build of a fork with this PR and so far we have not observed any problems in production.

[yamass]

@ibalosh You have just lost a customer due to this not being done.

For my current project, my customer is not willing to have a custom build of this library. So mailgun it is.

Guys, wake up! This is a legacy library as long as it cannot be used for new projects without patching it!
The world is moving on, and if you do not do so too it will move on without you.

[ibalosh]

Hi @yamass

we completely understand your concerns and are sorry to hear that. Meanwhile we talked couple of times with the team about this issue and have caught up yesterday to see what we could do to support frameworks depending on newer versions of Java EE.

With that in mind we are looking to figure out the approach we should take for this update. Mainly we are considering whether we could keep the widest possible compatibility with single library (JDK8+, Java EE8, Jakarta EE9+) or we need to split it out to legacy one and new one and maintain both. Single library would be ideal and easier to maintain.

Some of the approaches we are looking at are:

• do something like jersey http client did and provide 1.x legacy version and 2.x version which would be based on Jakarta EE9
• do the same as above but with two versions postmark and postmark-jakarta one
• update current version to use jersey 3.0x which would add support to Jakarta EE9 and should be backward compatible
• do something like what @pheyken recommended here add second artifact with support for Jakarta EE through eclipse transformer #53 , would that help?
• allow changing http client used within library (aka Jersey currently) and use newer version or other one (seems tricky to setup)

These are some of the ideas we have in mind and we plan to work on this next week, and hopefully release it in week or two.

If you guys have any other additional suggestions how we should approach this feel free to comment. Feedback is very welcomed. We are a small team, so all inputs are greatly appreciated.

[ibalosh]

Hi

we plan to release tomorrow a new version of the library which should resolve this issue.

[ibalosh]

the issue should be resolved with release 1.10.0 we made today