Discussions

News: JAXB 2.1 is Final

  1. JAXB 2.1 is Final (21 messages)

    JAXB 2.1, the Java Architecture for XML Binding, has been released. As Eduardo Pelegri-Lopart notes on the Aquarium, "This is a relatively small maintenance release but it includes some especially useful ones, like separate compilation." Separate compilation is a feature by which JAXB-generated artifacts can be used as is in the creation of extended bindings. However, there are installation notes for inclusion in Java SE 6, since JAXB 2.0 is standard in that release. From Kohsuke Kawaguchi's blog entry, "JAXB 2.1 released":
    If you'll be using JAXB 2.1 with JDK6, you'll have to use the endorsed directory mechanism to override JAXB 2.0 API in JDK with JAXB 2.1 API (this can be done by either a system property — normal — or putting the jar in a certain pre-defined directory — rare.)
    This highlights the need for an extension mechanism in Java - JAXB might be the most useful thing since sliced bread, but if Java SE 6 requires special installation measures, it - JAXB 2.1 - might as well not exist. The same might be said of any other standard API that is delivered with the JRE. What do you think?

    Threaded Messages (21)

  2. Re: JAXB 2.1 is Final[ Go to top ]

    What do I think ? I think that such an unstable API should not be part of rt.jar. The rule should be that an API needing 3 or 4 version changes during the lifespan of a JDK version should not be part of rt.jar. There was the same kind of problems with JAXP and its reference implementation when it was first bundled in rt.jar ; Sun should learn of its errors.
  3. Re: JAXB 2.1 is Final[ Go to top ]

    Well, it is needed for JAX-WS 2 and JAX-WS 2 is needed for out-of-box Web Services, which are actually needed today for Web-enabled rich client apps deployed with Java Web Start. Btw. it is rather simple to override bundled version with the new, so I do not see an issue. JRE size is also small when compared with the competition.
  4. Re: JAXB 2.1 is Final[ Go to top ]

    Btw. it is rather simple to override bundled version with the new, so I do not see an issue.
    No, it's not simple. Here are some complications: * You may well need administrator priviledges on unix machines to add the lib's to the endorsed directory * Your Java hosting company (one wonders why there are so few) may not want to change the endorsed libs * 2 applications running under the same VM can't use different versions of JAXB * You need special instructions for a particular JDK (i.e. 6.0). People often don't read the instructions because it's USUALLY a reasonable assumption that a packaged product doesn't require that you mess with the JVM (e.g. if you have a war file, you don't automatically think you need to put a bunch of jar files into your endorsed directory) * Since upgrading of VM's typically happens at the speed of tar by the time most people add Java 6.0 functionality, all of these libraries will have bug fix updates. That completely wipes out any advantage that packaging them in the VM had in the first place and means that if their app was running quite happily on Java 5.0 (if they're lucky enough to be there), it's now broken. And, honestly, what on earth is gained from stuffing all of these things into the JVM? It means people don't have to package them up with their product but can rely on them being in Java 6.0? Firstly, that list only includes people that only ever intend to deploy their products onto Java 6.0. Secondly, anyone who hasn't figured out how to add jars to their projects is going to have a hard time understanding endorsed jars. And the same goes for JAX-WS 2. Who gives a monkey's about "out-of-the-box" Web Services for Web-enabled rich client apps? Just add the jars to your rich client application. If it's any good, it's probably already based on either the Eclipse RCP or Netbeans, in which case you're up to your eyeballs in non "out-of-the-box" libraries.
  5. Re: JAXB 2.1 is Final[ Go to top ]

    +1. Hell, ++11. Keep non-core classes out of the rt. Everything else is an extension.
  6. Deja vu all over again[ Go to top ]

    +1. Hell, ++11. Keep non-core classes out of the rt. Everything else is an extension.
    I feel as if I've had this conversation before. http://www.theserverside.com/news/thread.tss?thread_id=43499
  7. Re: JAXB 2.1 is Final[ Go to top ]

    Who gives a monkey's about "out-of-the-box" Web Services for Web-enabled rich client apps? Just add the jars to your rich client application. If it's any good, it's probably already based on either the Eclipse RCP or Netbeans, in which case you're up to your eyeballs in non "out-of-the-box" libraries.
    \o_ Of course you can add the jars and make your client 5-10 Mb, but why would you do that if you have the option to keep it slim and snappy. Java WebStart is actually something pretty cool, biggest problem is often the slow startup times because n+1 dependency jars...
  8. Re: JAXB 2.1 is Final[ Go to top ]

    Java WebStart is actually something pretty cool, biggest problem is often the slow startup times because n+1 dependency jars...
    JWS is good and it that close to be perfect: - JNLP should allow specifying any external repository for dependencies, not necessary on the same domain as main application; - security should allow multiple signatures on jars; - Oh, and there should be a central repository of artifacts (jar files etc.) to use. Kind of Maven but trusted, meaning that every artifact should have traceable signature and belong to some ring of trust. That will significantly reduce size of downloads and eliminate repeated downloads of the same common libraries.
  9. Re: JAXB 2.1 is Final[ Go to top ]

    Who gives a monkey's about "out-of-the-box" Web Services for Web-enabled rich client apps? Just add the jars to your rich client application. If it's any good, it's probably already based on either the Eclipse RCP or Netbeans, in which case you're up to your eyeballs in non "out-of-the-box" libraries.

    \o_

    Of course you can add the jars and make your client 5-10 Mb, but why would you do that if you have the option to keep it slim and snappy.

    Java WebStart is actually something pretty cool, biggest problem is often the slow startup times because n+1 dependency jars...

    So, for those people that use Web Start, rely on people who have the Java 6.0 JRE installed (which is now a far bigger download) and make use of these particular jars (want to use xmlbean's instead of JAXB? sorry, no can do) the user experience is somewhat improved. Add to that, you can't even use JAXB 2.1 if that's your criteria because it's not bundled in the JVM. You have to admit, that sounds like a rather poor deal for everyone else, especially given the limited advantages you're getting.
  10. Re: JAXB 2.1 is Final[ Go to top ]

    So, for those people that use Web Start, rely on people who have the Java 6.0 JRE installed (which is now a far bigger download) and make use of these particular jars (want to use xmlbean's instead of JAXB? sorry, no can do) the user experience is somewhat improved. Add to that, you can't even use JAXB 2.1 if that's your criteria because it's not bundled in the JVM.

    You have to admit, that sounds like a rather poor deal for everyone else, especially given the limited advantages you're getting.
    No need to put words in my mouth and make false assumptions. Surely you can keep supporting Java 1.1 until the end of the world, but at some point its good to think how you could possibly benefit from the evolution of java. Atm I would use java 6 features only for closed enviroments which I know would support it. But at some point JSE6 will be mainstream and at some point it will be the minimum requirement... So all in all, we are moving to right direction but of course it takes time to get there.
  11. Re: JAXB 2.1 is Final[ Go to top ]

    So, for those people that use Web Start, rely on people who have the Java 6.0 JRE installed (which is now a far bigger download) and make use of these particular jars (want to use xmlbean's instead of JAXB? sorry, no can do) the user experience is somewhat improved. Add to that, you can't even use JAXB 2.1 if that's your criteria because it's not bundled in the JVM.

    You have to admit, that sounds like a rather poor deal for everyone else, especially given the limited advantages you're getting.

    No need to put words in my mouth and make false assumptions.

    Surely you can keep supporting Java 1.1 until the end of the world, but at some point its good to think how you could possibly benefit from the evolution of java.

    Atm I would use java 6 features only for closed enviroments which I know would support it. But at some point JSE6 will be mainstream and at some point it will be the minimum requirement... So all in all, we are moving to right direction but of course it takes time to get there.
    I still don't believe you've made a convincing argument for including JAXB in Java 6.0. You appear to suggest it would be convenient for you since you can use Java 6 features in a closed environment. That's fantastic for you. What is holding your users back from downloading JAXB as well as Java 6 in your closed environment? Will that stop you from using JAXB 2.1 because it's not bundled? Do you believe that this benefit is worth the pain it creates for a significant part of the Java community that don't have closed environments that match yours?
    Surely you can keep supporting Java 1.1 until the end of the world, but at some point its good to think how you could possibly benefit from the evolution of java.
    Haha. You can't complain about me making false assumptions and then do it yourself without appearing hypocritical, Tero.
    But at some point JSE6 will be mainstream and at some point it will be the minimum requirement
    Yes. And by the time it is, JAXB will far advanced of version 2.0 and nobody will want to use the version that's packaged with Java 6.0 nullifying any imagined benefits of putting it in now.
  12. Re: JAXB 2.1 is Final[ Go to top ]

    What do I think ? I think that such an unstable API should not be part of rt.jar.
    IMHO They didn't include it to rt.jar till they decided it is stable enough. Now it looks stable what are reasons not to bundle it?
  13. JAXB is on its own an excellent tool but if you want a fully supported XML binding API then C24 offers a very viable alternative with Integration Objects (IO). The obvious advantage is that IO goes way beyond XML binding allowing you to maintain the same message binding API for CSVs, databases and other non-XML formats. The ability to execute XSL and XQuery directly on the objects rather than the instance is also a major advantage for high performance scenarios. Finally being able to add rules and constraints to the model can reduce endless headaches with unclean or invalid messages that otherwise pass easily through Schema and therefore JAXB. If you're just doing pure and simple XML then JAXB is the perfect tool for the job. -John-
  14. ... The ability to execute XSL and XQuery directly on the objects rather than the instance is also a major advantage for high performance scenarios. Finally being able to add rules and constraints to the model can reduce endless headaches with unclean or invalid messages that otherwise pass easily through Schema and therefore JAXB.
    Performance is one of the most important criterions - especially in the banking areas. John, what's about some more details over the concrete Performance distinctions between this both Technologies (IO and JAXB) in the real practice ? Roland http://www.soa-competence-network.de
  15. Performance is one of the most important criterions - especially in the banking areas.

    John, what's about some more details over the concrete Performance distinctions between this both Technologies (IO and JAXB) in the real practice ?
    Roland
    Roland, We don't benchmark against other products as a matter of course but I'm sure we could try a practical example with FpML. I know a large bank recently benchmarked our stuff against a number of other commercial products, JAXB and JIBX for "real-world" examples and we came out top. The issue is that it's difficult to get like for like, we validate the full FpML rules for example, something that is impossible in JAXB, if we just stick to raw parsing, perhaps changing a value, serializing it and then reading the value out again on the other side we should be able to do the same with both products. Once again though we would normally use XPath to extract values and JAXB doesn't support that natively. I'll try to knock up a basic test scenario over Christmas. -John-


  16. Roland,
    We don't benchmark against other products as a matter of course but I'm sure we could try a practical example with FpML. I know a large bank recently benchmarked our stuff against a number of other commercial products, JAXB and JIBX for "real-world" examples and we came out top.

    The issue is that it's difficult to get like for like, we validate the full FpML rules for example, something that is impossible in JAXB, if we just stick to raw parsing, perhaps changing a value, serializing it and then reading the value out again on the other side we should be able to do the same with both products. Once again though we would normally use XPath to extract values and JAXB doesn't support that natively.

    I'll try to knock up a basic test scenario over Christmas.

    -John-
    John, I could make a simple performance-test within one of our current B. projects, which receives daily 60.000 XML-based Messages with sizes between 1KB and 900KB and using XSchema & JAXB for the parsing-process. So far I know, replacing JAXB by IO were only some single lines of code - but can us show the result of such simple performance-test the real differences and advances between JAXB and other associated solutions - how e.g. the mentioned IO ? Maybe the advances of such solutions are more destinated to the optimized handling of specialized protocols (e.g. FpML, ...) and their potentially resulting performance gainings by this parts. Roland --- Merry Christmas | Feliz Navidad | Frohe Weihnachten SOA Kompetenznetzwerk
  17. Roland, Please contact me (John dot Davies at C24 dot biz) and I'll see if we can help setting up a test with your current project. Generally speaking it is pretty simple replacing JAXB with IO but we never intended it to be a plugin replacement so there will probably be a few minor changes here and there. We have a lot of major banks that have migrated at some point and we've never seen any issues. Of course we'll post the results here for others to see. I look forward to hearing from you, -John-
  18. Roland,
    Please contact me (John dot Davies at C24 dot biz) and I'll see if we can help setting up a test with your current project. Generally speaking it is pretty simple replacing JAXB with IO but we never intended it to be a plugin replacement so there will probably be a few minor changes here and there. We have a lot of major banks that have migrated at some point and we've never seen any issues.

    Of course we'll post the results here for others to see.

    I look forward to hearing from you,

    -John-
    John, In the next weeks I will spend some time, to adapt an advanced existing integration-solution to JAX2 and furthermore to IO from C24 (Its time to investigate and to get to know IO more detailed...). I think for this adaption its sufficient to use the free available Open Edition of IO. The description of the different steps for each adaption and the result of the following performace-tests are published in detail by an associated technical article on our Information-Portal (sorry, by the moment only in german language) and of course in a compressed form here by this thread on TSS. I'd be glad to get in touch with you for eventually upcoming questions or some additional informations. Maybe at a later date its possible to publish an advanced article over IO with more details over the possibilities and the advanced handling for the specialized protocols, ... Roland SOA Kompetenznetzwerk Information & Collaboration-Portal
  19. What about re-distribution?[ Go to top ]

    Is it re-distributable with applications developed using it? I ran into an issue when I realized that JAXB was not redistributable in JWSDP. I had to migrate my code to Apache JaxME.
  20. JAXB RI is released under CDDL, which is an OSI-approved open source license. So you can redistribute it freely.
  21. Separate compilation rocks ![ Go to top ]

    The ability to factor enterprise messaging models into a set of modular reusable object binding packages is huge leap forward. Now the Java package structure matches the XSD import structure, and instance fragments have the same type, even when they occur in different enclosing document types (e.g. pass-through transformations become much easier). Does anyone know if XML Beans can do this ? Mik
  22. Re: JAXB 2.1 is Final[ Go to top ]

    I have used Jaxb on a few projects so far, and found it a fantastic java-XML binding tool. I am glad to see it comes with standard java distribution without worrying about further including other libraries.