Old grumpy software architect and engineer. I create, perform, and teach music. I´m married, have kids, dogs, dabble in fine arts, and talk psychology, culture, and politics.
Sure! I wrote all about it over on Medium: https://medium.com/@aev_software/java-jakarta-soap-wsdl-client-fails-to-read-soap-message-for-logging-38087a63ea6d
To summarize: custom logging handlers failed after upgrading to version 3, because the underlying implementation that exports a message as a SOAP message is broken.
Cool. Just what I need: yet another version of a JDK/JRE to test. I feel like I spend more time testing these for regressions than I spend developing functionality for my clients. Anyway. Good for Adoptium and those who found and solved this bug.
I started using Jakarta half a year ago, as it was promised to be the de-facto way to build a SOAP client that speaks to a WSDL server. Oh boy: growing pains. Did not expect that 2 decades of developer experience in Java EE would amount to nothing, for the people who implemented Jakarta. As impressive as the effort may be, the inexplicable regressions we faced when we got forced to upgrade to version 3 proved quite cumbersome.
One would switch to a free JVM when other JVMs change their licenses from free to paid. OpenJ9 was the first free JVM to which I got introduced. Knowing it was based on the work by IBM, known for high performance and low memory footprint, it was a simple choice.
Great article. Well written, with just the right amount of detail for me.
Right! I had used streams a couple of times but for most work had switched to Eclipse Collections. Some payloads just work better when streamed and I was left wondering why nothing happened!
All the good things Records bring are stifled by JPA and DAO conventions and requirements. I really hate JPA for that reason, and have avoided Hibernate in favor of my own DAO implementations.
Records will slash thousands of lines of code from my implementation and will make it infinitely easier to maintain, and trust down-stream.