when i compile a JAXB schema the generated classes are decorated with generic Javadoc comments.
is it somehow possible to suppress generating these comments?
Annotation to disable JavaDocs
Not if you're using Sun's JavaDocs tool.
They have a feature request for it, but it's been in low priority since 1997.
You can write a custom doclet to overcome this, or use a 3rd-party tool (DocFlex or such).
Related
I don't understand why PowerMock use javassist library and Mockito is not.
Most of the conversations about code generation libraries in Java circle around three libraries: cglib, javassist, and ByteBuddy. Mockito was formerly on cglib, but now uses ByteBuddy as its default code generator.
As ByteBuddy author Rafael Winterhalter notes here:
javassist offers an API for modifying classes and not only for subclassing them. These APIs allow also for byte code-level manipulation while cglib only allows for several hardcoded interceptions.
Though I am not a contributor on any of these mocking frameworks or libraries, it's worth noting that Powermock works in part by editing class implementations to intercept calls to private, static, and final methods and classes within compiled bytecode. This likely explains the requirement to use javassist from Powermock: cglib was not capable of editing existing classes. Mockito, in contrast, needs simpler code generation in order to generate a subclass of the given class; this is functionality that cglib and ByteBuddy were written to provide.
Note that open Powermock issue 727 tracks an incomplete migration of Powermock from Javassist to ByteBuddy.
Now, the reverse: Why doesn't Mockito switch to Javassist instead of ByteBuddy? Again, we don't have a direct answer, but the ByteBuddy tutorial expresses an opinion (under "General Information" for Javassist, emphasis mine):
This library comes with a compiler that takes strings containing Java source code which are translated into Java byte code during the runtime of an application. This is very ambitious and in principle a great idea since Java source code is obviously a great way for describing Java classes. However, the Javassist compiler does not compare to the javac compiler in its functionality and allows for easy mistakes when dynamically composing strings to implement more complex logic. Additionally, Javassist comes with a proxy library which is similar to the JCL's proxy utilities but allows extending classes and is not limited to interfaces. The scope of Javassist's proxy tools remain however equally limited in its API and functionality.
In short: There is anecdotal reason to doubt Javassist's safety/functionality/stability. Mockito did not require Javassist's features, so it could migrate straight from cglib to ByteBuddy. PowerMock did require Javassist's features, and the efforts to migrate PowerMock to ByteBuddy are stalled and ongoing.
Is it possible to create Prolog-specific bindings of XML schema files? If so, can anybody point me in the right direction?
I have a schema which I use in Java to create a JAXB binding to serialize and de-serialize XML files. These files are created by an SWI-Prolog application which is still evolving and is developed by a geographically distant team. I want to make sure that when XML format changes, they are tied to a schema file change and not just view a schema as a nice documentation tool which often lags their actual XML content.
Any suggestions are appreciated.
Sounds like the general consensus is to use Prolog's JPL package to wrap a JAXB binding in Java. This is the closest one seems to get to an actual binding implementation.
There is an SGML package which is used by many, but this is not a binding. As far as I understand, the best one can hope for is to be able to validate one's XML against the schema, but a quick look at the SGML documentation did not give me an impression that this functionality is actually fully implemented.
So, if one needs a schema binding-style XML management framework, the recommendation is to access JAXB binding of this schema via JPL. Some folks expressed stability concerns of JPL. They reported frequent crashes of JVM when using JPL, but I have not independently verified these claims and thus cannot confirm them. If anybody has more input on this topic, I would love to get it.
Thanks
The optaplanner uses XStream for reading the solver configuration from XML. For using JAXB instead, is it sufficient to have custom implementation of XMLSolverFactory and SolverConfig?
No, because the *Config classes aren't annotated with JAXB annotations in 6.0.0.
There's a open discussion if we want to migrate from XStream to JAXB, so we can offer an XSD of the solver config.
Also note, that these 2 things are completely distinct:
read a solver configuration from XML
read a solution dataset from XML (~ProblemIO)
For 2), you can very easily replace XStreamProblemIO with a JaxbProblemIO (which should be easy to write).
We are using Castor for marshalling/unmarhalling xsd:s. We are using attachments and refering to the with the "swaRef" element. According to this page Castor does not support this, http://docs.codehaus.org/display/CASTOR/Castor+JAXB:
Some of the functionality could require to be actually implemented in
backing Castor framework - for example handling the attachment
through MTOM/XOP and swaRef.
How can we overcome this limitation?
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB (JSR-222) expert group.
My recommendation would be to use a standard JAXB (JSR-222) implementation that supports everything you need (models generated from XML schema, swaref, etc) rather than implementing some workaround to use Castor. An implementation is included in the JDK/JRE as of Java SE 6, and other implementations (such as MOXy) are also available.
Note
Based on the link you provided it does not appear as though Castor has run the JAXB (JSR-222) compliance tests and in the "Functional testing" section on that page it appears as though Castor has not fully tested its support for the JAXB (JSR-222) annotations.
Functional testing
I think a little bit of time should be spend on
functional testing, and this might get quite tedious. Looking, for
example, at the #XmlAttribute annotation, there's a lot of variants to
test, requiring POJOs to be annotated slightly different for each test
case. That would require us to write a lot of POJOs and wire them up
accordingly in the test classes. Let's see whether we can agree on how
to go about this (layout, package structures, ...).
I'm writing my master thesis, which deals with AOP in .NET, among other things, and I mention the lack of support for replacing classes at load time as an important factor in the fact that there are currently no .NET AOP frameworks that perform true dynamic weaving -- not without imposing the requirement that woven classes must extend ContextBoundObject or MarshalByRefObject or expose all their semantics on an interface.
You can however do this with Java in the JVM thanks to ClassFileTransformer:
You extend ClassFileTransformer.
You subscribe to the class load event.
On class load, you rewrite the class and replace it.
All this is very well, but my project director has asked me, quite in the last minute, to give him a list of frameworks (and associated languages) that do / do not support class replacement. I really have no time to look for this now: I wouldn't feel comfortable just doing a superficial research and potentially putting erroneous information in my thesis.
So I ask you, oh almighty programming community, can you help out? Of course, I'm not asking you to research this yourselves. Simply, if you know for sure that a particular framework supports / doesn't support this, leave it as an answer. If you're not sure please don't forget to point it out.
Thanks so much!
EDIT: #ewernli
I'm asking about (2).
In C# you can indeed emit code at run-time and create new classes dynamically, but they are new classes, they do not replace an existing class. What I'd like to do is to transform the class at load-time, like you can do in Java with the ClassFileTransformer.
About modifying a method's signature: yes, you're right. I should have mentioned that in my case I don't want to modify the class' interface, but rather the content of its methods.
Your answer was really helpful. Thank you :)
Are you asking about (1) true class replacement at run-time, or (2) facilities to transform the class when it's loaded or (3) languages which support dynamic class loading ?
Java support dynamic class loading with ClassLoader, transformation with ClassFileTransformer, but no true class replacement.
I'm not sure for C#, but I think you can emit code at run-time and create new class dynamically, so you can achieve (3) and probably (2).
True class replacement is mostly supported only by dynamic language, e.g. Smalltalk, Ruby, I guess Python and a few others. This requires the transformation of the instances of the class to match the new shape. They usually initialize the new fields to nil if the class changes.
AFAIK, dynamic languages ported to the JVM make extensive hacking of ClassLoader to support class replacement at run-time. For JRuby, see A first taste of invoke dynamic to get more pointers how they do it now, what's problematic and how the upcoming invokedynamic might help.
This is not offered in statically typed languages because of the complication with the type system. If a method signature change in a class, other existing classes already loaded might not necessary comply with the new method signature which is not safe. In java you can however change a method as long as the signature is the same using the Java Platform Debugger Architecture.
There have been some attempt to add this feature to Java, and/or statically typed languages:
Runtime support for type-safe dynamic Java classes
Supporting Unanticipated Dynamic Adaptation of Application Behaviour
A Technique for Dynamic Updating of Java Software
This paper provide a general overview of related problems
Influence of type systems on dynamic software evolution
Not sure exactly if that address you initial question, but these pointers might be interesting for your thesis anyway.
The Java language doesn't support class file replacement. The JVM exposes the feature via the classes you mention. Therefore all languages which have been ported to the JVM can take advantage of it.
Erlang supports hot code swapping, and if you are looking also for theoretical frameworks that model dynamic class updates, you can take a look at the Creol language (interpreted).
Objective-C's runtime library supports dynamic construction and registration of classes, lazy method registration and "method swizzling" by which method implementations can be switched at runtime. Previous versions supported "Class swizzling" by which a class could be substituted for another at runtime, but now method swizzling is used instead. Here's the reference doc.