Reimplement not using JAXB?

[manning]

Are you guys thinking of/open to changing the data loading to not use JAXB any more?

That dependency seems a bit of a nuisance now that various Java EE module including JAXB have been removed from Java SE….

[svendiedrichsen]

Sure. I have been toying with some different frameworks but I haven't thought it through though. The code currently heavily depends on the JAXB generated classes. It would probably need some abstraction layer.

[svendiedrichsen]

@manning Which framework would you suggest?

[svendiedrichsen]

@manning I'm thinking of going with JiBX. Do you have any thoughts on this? It does some weird things with bytecode manipulation though. But I think this is only done during build time.

[thackel]

I really don't see the point why the effort should be done moving away from JAXB. Its the standard and was part of the JDK. The last update(release) of JAXB was in in Summer 2017. JiXB's last update was in 2016 and does not seem to have active development. The main page even links to not existing codehaus pages. Its does not even work with Java 9 where all should focus on Java 11 now B-)

[svendiedrichsen]

@thackel Yes, JAXB is standard. But it will be thrown out of Java SE like all of the EE modules. If you are thinking about Jakarta EE and the Microprofile direction this is heading, you won't always want to have JAXB on the classpath. JAXB is surely the way to go when doing SOAP in all its glory or anything pretty advanced with XML/XSD but Jollyday just reads some XML files and populates simple Classes.

To have Jollyday be usable in the future you will have to add JAXB back in and I believe its a pretty big piece of library from which Jollyday is not using much.

Besides, in mobile JAXB is a nono.

What do you think about XStream? I'm considering using i.e. JiBX generator to create simple classes at build time and XStream to read XML into them at runtime. So XStream will then be the extra runtime dependency.

Besides, anyone is welcome to join this discussion.

[buchen]

@svendiedrichsen Any updates on the plan to move away from JAXB?

Let me share my experience using Jollyday in an OSGi-based RCP application: I want to be able to run my application on Java8 and Java11 (because I have no idea what Java version users have locally installed). In principle I have it running, but I had to create a OSGI system extension (for JAXB dependencies to sun.com.source.tree) and a fragment to jollyday (to allow loading of the com.sun.xml.bind.v2 context factory). Furthermore, the JAXB OSGi bundles work only starting with Java9 (which makes it impossible to have identical dependencies for Java8 and Java11). And I do not get the Maven Tycho plug-in to properly resolve the system extension before executing the tests (which means I can build only with Java8).

In short: it is a pain in the back. I would be interested in a non-JAXB version.

[svendiedrichsen]

@buchen Well, not really updates. I'm still convinced to do it but haven't had time. I will do it but am not quite sure which framework to go with. And I would like to keep the JAXB way for those who love it. So I will probably have to make multiple modules.

[wborn]

Although xstream still works with Java 11, it may not work with future Java versions. It depends on using reflection in deprecated ways that may be removed in future Java versions, see https://github.com/x-stream/xstream/issues/101.

[burberius]

What about using Jackson for the XML binding? I think it has the biggest distribution currently and is also used in Spring for example.

Another way to generate the Classes from the XSD is described here: https://blog.viadee.de/jaxb-und-soap-in-java-11

I think about doing the porting as we will need that change at work, to get our stuff working with newer Java versions!

[derTobsch]

Hey @svendiedrichsen, thanks for your work on JollyDay! What is the plan to release 0.6 versions in the future? Is that going to happen? :)

Ah k, I found https://github.com/svendiedrichsen/jollyday/tree/modularizing. Looks good!

[asbachb]

Not 100% related: But I wonder if this project still wants to support java 8. Since now we've the situation that there's a recent version shipping jaxb which might cause some problems when having a non standard classloader (like eclipse + tomcat).

I wonder if it would make sense to provide a jdk8 classified release with that dependency stripped.

[thomass4t]

Hello, I would kindly ask about the status of jakarta-EE-Support in version 0.6. Is there any timeline / update available?

Oracle is ending support for JDK 8 next month. I think investing time in keeping jdk8 compatibility in new versions can be dropped. If necessary, bugfixes can be done in the 0.5 version.

Thanks! Thomas

[derTobsch]

Hey there, I started to implement the modularizing branch in our own repo see https://github.com/focus-shift/jollyday. The baseline will be java 11 and there is some way to go until the first release. But if someone wants to help I am happy to see pull requests :)

First of all I fixed everything so that the code will compile and run. Next will be to add the test back. And than see what will fail :) Another part is the i18n.

[derTobsch]

Hey there. We released our first release of the focus-shift jollyday library. Happy to see something growing again. Take a look at https://github.com/focus-shift/jollyday/releases/tag/v0.6.0

[HoffmannTom]

@derTobsch Thanks for creating a new version of jollyday! Is there a plan to reunite this project and your fork in future or will they stay separate?

[derTobsch]

@derTobsch Thanks for creating a new version of jollyday! Is there a plan to reunite this project and your fork in future or will they stay separate?

I wrote some emails to Sven but got no response. So I think it will be a new library under Focus-Shift.