We Keep Coding

Easy way to migrate from JAXB to Castor?

I have created a library which includes some 200 Java classes generated from an existing XSD with JAXB like this:
xjc -no-header -d schemas -b xsd/binding.xml xsd
Alas, JAXB is not supported on Android, and the general suggestion seems to be to use a different library. Castor seems to be a suitable alternative—especially as it offers conversion of .xsd into Java classes. However, doing so seems to be more complex than in Java, and I have no idea of how much the result differs from xjc output.
My use case is unmarshaling and reading the unmarshaled data (changing data or marshaling are not needed). That is, there is a vast amount of code which relies on the resulting Java class schema, therefore any difference between xjc-generated classes and their Castor counterparts would mean a lot of refactoring.
Is there a simple recipe on how to generate Java classes from .xsd in Castor and get a result that is as close as possible to what xjc produces?

The following approach is as close as I got, though some refactoring is still required:
Place a file named castorbuilder.properties on your classpath, with the following content:
org.exolab.castor.builder.javaclassmapping=type
org.exolab.castor.builder.javaVersion=5.0
# Replace the following lines with your schema(s)
org.exolab.castor.builder.nspackages=\
http://example.com/schema/foo=com.example.schema.foo,\
http://example.org/schema/bar=org.example.schema.bar
org.exolab.castor.builder.primitivetowrapper=true
Then run the following command line:
java -cp "*" org.exolab.castor.builder.SourceGeneratorMain -i schema.xsd -types j2
In the above, replace the classpath with the path to the Castor JAR files and castorbuilder.properties, and replace schema.xsd with the path to your XSD file.
Of course, you can invoke Castor via Ant or Maven—in this case, be sure to use the respective equivalent to the command line options above and make sure the properties file is picked up.
Differences which require refactoring:
Enum types are now in their own types sub-package
Where XML Enum literals are in camelCase, they now become CAMELCASE rather than CAMEL_CASE
Castor generates array properties where JAXB has Collection properties
Some class names get an underscore as a prefix; apparently JAXB drops those while Castor preserves them
Date fields are now Date instances
In one instance a property changed its name from value to content
However—there seems to be a bug in Castor, as some of the generated classes invoke a non-existent constructor. This has stopped me from successfully trying this out; I only got as far as refactoring my existing code to the point of being free from syntax and compiler errors.

How to plug custom distances with ELKI?

I've already read the tutorial at ELKI documentation ( http://elki.dbs.ifi.lmu.de/wiki/Tutorial/DistanceFunctions ).
Unfortunately, I'm not grasping how to plug the generated .class with MiniGUI (or bash script for the provided .jar). How it can be done?
Ps: I know it sounds absolutely noob, but when I try to "type" the class name, as suggested, I get the error "The following parameters could not be processed: HammingDistance", for example.

ELKI will load classes via the standard Java Classloader. Therefore, they must be on the class path or they cannot be loaded. An example call (assuming your classes are in the bin folder) is java -cp elki.jar:bin/ de.lmu.ifi.dbs.elki.application.ELKILauncher
Parameters are interpreted as follows:
If there is a class with this name (including the package name!) it is used.
Otherwise, ELKI tries prepending the package name of the expected interface. Which enables shortcut names.
Otherwise, known classes (from the service files) are checked for aliases. For example, the Euclidean distance has an alias name of l2, Manhattan has an alias l1.
The class must have a parameterless public constructor or a inner public static class Parameterizer.
Input assistance is built as follows:
.jar files on the classpath are checked for service files in META-INF/elki/<interface>
folders on the classpath put you in development mode, where a recursive list is performed and all .class files are inspected. This is much slower, but removes the need to edit the service files. Discovered classes show up below the ones listed in the service file.
Furthermore, the package de.lmu.ifi.dbs.elki.application.internal includes classes that will inspect everything on your classpath, and will report e.g. classes that do not have a parameterless public constructor, or a inner public static class Parameterizer.

Adding a proxy to a networking app without changing code possible?

I want to use a Java application, which is not written by me and also not maintained anymore, meaning I can't just go to the author and ask for a new feature. What options do I have to add proxy capabalities. Is it possible to add some shell arguments? Is it manageable work to add the binary code for the proxy directly into the .class file? Could I write my own class, import the stuff from the .class files and overwrite the network functionality?

This might work for you:
java -Dhttp.proxyHost=IP_address -Dhttp.proxyPort=8080 -jar App.jar

It is possible to replace a class with your own implementation by creating a class with the same name/package and placing it earlier in the classpath so it takes precedence. However you cannot break binary compatibility if this class is used by other parts of the code.
There are also instrumentation APIs available to modify classes as they are loaded. See the Instrumentation API.

If you are creating your own source file that references the compiled .class, then in your file try doing this:
java.util.Properties systemProperties = System.getProperties();
systemProperties.setProperty("http.proxyHost", PROXY_HOST);
systemProperties.setProperty("http.proxyPort", PROXY_PORT);
I think that should work.

Changing package for generated classes in CXF

The question is whether it is possible to assign different packages for different namespaces for cfx to generate.
I have a wsdl generated by .Net application. Now I need to use it in java app. By default it generates several packages. Like com.microsoft.schemas_2003._10.serialization, datacontract.schemas._2004._07 .... And the package with the name of the target namespace.
If I add -p parameter and set package, than all the classes are placed in thin one package.
Is it somehow possible to change only one package and leave others as they are? Exactly I don't want this package with targetNamespace name, want to change it.

As dma_k mentioned, the standard jaxb/jaxws binding files is the standard way to do it.
You can do it with the -p flag as well though. The -p flag allows a namespace -> package mapping:
-p <[wsdl-namespace =]package-name>*

Java: How to communicate between an annotation processor and another project?

I have an own annotation processor (let's call it MyProcessor) and a project (let's call it MyProject) which uses the processor by
passing -processor to javac.
Now I need MyProcessor to produce some output and make it available for MyProject.
I have following options (and problems):
Let MyProcessor write a file to the path, specified by the property user.dir.
Problem: from the point of view of MyProcessor, user.dir is always my home dir, not the path of MyProject.
Pass the current directory of MyProject to MyProcessor using javac's -A option.
Problem: It's an ugly hard-coded path: /some/path/to/MyProject/.
Let MyProcessor generate some source files, which then would be compiled by javac together with MyProject, so that MyProject can refer to this compiled class and retrieve data from it.
Problem: It's too complex for such an easy (?) task.
What other options are there?
Can someone please suggest, how to proceed?

Processor.init() method (which you've implemented) is invoked with ProcessingEnvironment as parameter which, in turn, has a getFiler() method returning a Filer instance.
You should be using the createResource() method of the Filer (assuming the output being generated is neither class nor source; otherwise use appropriate create method for that) and write your output to either class or source locations (former is probably preferable, but it depends on what you're doing). Both are overridable via command-line switches if need be, but are well-defined as they are to be used in a build process.