Develop Reference

JAXB unmarshalling failed on one machine but not others / Also worked in unit test

I have a piece of JAXB unmarshalling code that looks like this:
Foo foo = null;
try {
logger.debug(methodNamePrefix + "xmlString is \n" + xmlString);
JAXBContext jaxbContext = JAXBContext
.newInstance(Foo.class);
Unmarshaller u = jaxbContext.createUnmarshaller();
u.setEventHandler(new DefaultValidationEventHandler());
StreamSource streamsource = new StreamSource(new StringReader(xmlString));
foo = (Foo) u.unmarshal(streamsource);
sanityCheckDbpAfterUnmarshalling(xmlString, foo);
}catch(Exception e){
throw new AnalysisNotPossibleException();
}
if (foo==null){
throw new AnalysisNotPossibleException();
}
This code has been working for months, until recently, on one machine, it started failing. When it failed, it spit out a seemingly legit complaint -- except that the same piece of code, with same input xmlString, when run on another machine, or even on the very same machine but in unit test, would not complain:
javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"entry"). Expected elements are (none)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:642)
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254)
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:249)
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:101)
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:243)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:478)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:148)
I am quite sure that this is due to some local environment of that machine, but I could not figure out what that is. I have tried cleaning all my binary in my Eclipse.
I know this needs debugging, and I do not expect a full answer. But I would appreciate any ideas for some more things that I can check. Thanks!
Updated
The class Foo looks like this:
#XmlRootElement
public class Foo implements Serializable{
private static final long serialVersionUID = -4550266352252980254L;
#XmlElement
private HashMap<String, SomeProperty> mapAllPortletProperty =
new HashMap<String, SomeProperty>();
...
And the XML string looks like this
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<foo>
<mapAllPortletProperty>
<entry>
<key>Portlet 6262</key>
<value>
<apIdStrAtBirth>4536</apIdStrAtBirth>
...
2nd Update
Thanks for all the help so far. That has helped me to think about these
two aspects:
Resource leak? StreamSource and StringReader are holding onto
some resources after they are done with unmarshalling?
Thread safety? c.f. This SO post about "JAXB creating context
and marshallers cost"
For #1, I have checked that there does not appear to have resource leak.
I also have a stress-test program and it does a lot of unmarshalling. I did not observe the program has ever growing memory footprint.
For #2, I have rewritten my code so that for each class that needs
to be unmarshalling, my code instantiate an JAXBContext only once.
Unfortunately, with the above new insight, I still have not been able
to find the root cause of the problem. Any more insight are welcome!

After much debugging, I found the cause of the problem.
In one of my folders there were two JAXB related JAR files sitting there:
$ find . -name "jaxb*" -exec ls -l {} \;
-rwx------+ 1 leecy None 89967 Mar 19 2014 ./war/WEB-INF/lib/jaxb-api-2.1.jar
-rwx------+ 1 leecy None 876610 Mar 19 2014 ./war/WEB-INF/lib/jaxb-impl-2.1.13.jar
I think there is already an reference implementation of JAXB that comes with the JVM (I am using Oracle/Sun's JDK 1.7.0_51) and we do NOT need these extra JAR files, do we? And their presence actually could confuse my program and cause a different JAXBContextImpl to be loaded. For some reason such an implementation could not unmarshall the XML file.
Inspired by this blog post, I have my program print out the exact class name of the implementation after instantiation, and I got these results:
If I removed the extra JAR files, my program printed this line out, and the unmarshalling would work:
getJcMap(): Just instantiated an JAXBContext: class com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl
If I left them in, my program print this instead, and the unmarshalling would fail:
getJcMap(): Just instantiated an JAXBContext: class com.sun.xml.bind.v2.runtime.JAXBContextImpl
That explained why the problem happened only with that particular machine with that particular project folder, but not with other environment.
So I removed those extra JAR files and the problem was solved!
Thanks everyone! Happy Holidays!

Header modifications do not take effect in fresh build

I am trying to use BRIEF descriptor in OpenCV 3.1 for andoid. In order to achieve that OpenCV has to be built from source with _contrib. So I compiled it without errors and could also see BRIEF.cpp.o beeing built in the command window.
So when I try to use it, my android app crashes throwing
OpenCV Error: Bad argument (Specified descriptor extractor type is not supported.) in static cv::javaDescriptorExtractor* cv::javaDescriptorExtractor::create(int), file /home/maksim/workspace/android-pack/opencv/modules/features2d/misc/java/src/cpp/features2d_manual.hpp, line 374
So I checked features2d_manual.hpp. Line 374 is the default expression of a switch case block:
CV_WRAP static javaDescriptorExtractor* create( int extractorType )
{
//String name;
if (extractorType > OPPONENTEXTRACTOR)
{
//name = "Opponent";
extractorType -= OPPONENTEXTRACTOR;
}
Ptr<DescriptorExtractor> de;
switch(extractorType)
{
//case SIFT:
// name = name + "SIFT";
// break;
//case SURF:
// name = name + "SURF";
// break;
case ORB:
de = ORB::create();
break;
//case BRIEF:
// name = name + "BRIEF";
// break;
case BRISK:
de = BRISK::create();
break;
//case FREAK:
// name = name + "FREAK";
// break;
case AKAZE:
de = AKAZE::create();
break;
default: //**this is line 374**
CV_Error( Error::StsBadArg, "Specified descriptor extractor type is not supported." );
break;
}
return new javaDescriptorExtractor(de);
So the error clearly comes up, because case BRIEF is commented. So I modified it like that:
#include "opencv2/xfeatures2d.hpp"
.
.
.
case BRIEF:
de = xfeatures2d::BriefDescriptorExtractor::create();
break;
.
.
.
default:
CV_Error( Error::StsBadArg, "---TEST--- Specified descriptor extractor type is not supported." );
break;
}
After rebuiling in a fresh directory and using the new build, the exact same error is persistent. Not even "---TEST---" is included with the message.
So I am wondering why my changes do not have any effect.
I am also wondering why the file path is:
/home/maksim/workspace/android-pack/opencv/modules/features2d/misc/java/src/cpp/features2d_manual.hpp
This dirctory doesn't even exist on my system and googling it showed, that /home/maksim/ is part of a lot of different error messages on android.
The actual path before building is:
C:\Users\JJG-CD\Desktop\Build_Workspace\opencv-3.1.0\modules\features2d\misc\java\src\cpp\features2d_manual.hpp
I hope somebody can explain to me what the problem is and eventually give me a hint how to solve it.

The error you're seeing almost certainly comes from a library that you link to that uses the same header file. When you recompile your code having changed the header, that header change only takes effect for the code you're actually compiling, and not the code that is already compiled in the libraries that you're also linking.
Look at your compile line and consider all the -l options as possible suspects.
This also explains the non-existent directory reference: this directory existed and was used at the time the library(ies) themselves were compiled on whatever machine they were compiled on.
If you want your header change to take effect in library code, the library itself needs to be recompiled. Have a look at your project configuration files: you may very well already have make or cmake options to do this.

I gave up already but found the solution by chance. The reason my own built libraries have not been used was the fact that those libraries are usually provided by the opencv manager app. To get rid of OpenCV manager and use my own libraries I just needed to initialize OpenCV statically.
static {
if (!OpenCVLoader.initDebug()) {
// Handle initialization error}
}
Further details can be found here

Construct the stackmap of method while using bcel

I am trying bcel to modify a method by inserting invoke before specific instructions.
It seems that my instrumentation would result in a different stackmap table, which can not be auto-generated by the bcel package itself.
So, my instrumented class file contains the old stackmap table, which would cause error with jvm.
I haved tried with removeCodeAttributes, the method of MethodGen, that can remove all the code attributes. It can work in simple cases, a wrapped function, for example. And it can not work in my case now.
public class Insert{
public static void main(String[] args) throws ClassFormatException, IOException{
Insert isrt = new Insert();
String className = "StringBuilder.class";
JavaClass jclzz = new ClassParser(className).parse();
ClassGen cgen = new ClassGen(jclzz);
ConstantPoolGen cpgen = cgen.getConstantPool();
MethodGen mgen = new MethodGen(jclzz.getMethods()[1], className, cpgen);
InstructionFactory ifac = new InstructionFactory(cgen);
InstructionList ilist = mgen.getInstructionList();
for (InstructionHandle ihandle : ilist.getInstructionHandles()){
System.out.println(ihandle.toString());
}
InstructionFinder f = new InstructionFinder(ilist);
InstructionHandle[] insert_pos = (InstructionHandle[])(f.search("invokevirtual").next());
Instruction inserted_inst = ifac.createInvoke("java.lang.System", "currentTimeMillis", Type.LONG, Type.NO_ARGS, Constants.INVOKESTATIC);
System.out.println(inserted_inst.toString());
ilist.insert(insert_pos[0], inserted_inst);
mgen.setMaxStack();
mgen.setMaxLocals();
mgen.removeCodeAttributes();
cgen.replaceMethod(jclzz.getMethods()[1], mgen.getMethod());
ilist.dispose();
//output the file
FileOutputStream fos = new FileOutputStream(className);
cgen.getJavaClass().dump(fos);
fos.close();
}
}

Removing a StackMapTable is not a proper solution for fixing a wrong StackMapTable. The important cite is:
4.7.4. The StackMapTable Attribute
In a class file whose version number is 50.0 or above, if a method's Code attribute does not have a StackMapTable attribute, it has an implicit stack map attribute (§4.10.1). This implicit stack map attribute is equivalent to a StackMapTable attribute with number_of_entries equal to zero.
Since a StackMapTable must have explicit entries for every branch target, such an implicit StackMapTable will work with branch-free methods only. But in these cases, the method usually doesn’t have an explicit StackMapTable anyway, so you wouldn’t have that problem then (unless the method had branches which your instrumentation removed).
Another conclusion is that you can get away with removing the StackMapTable, if you patch the class file version number to a value below 50. Of course, this is only a solution if you don’t need any class file feature introduced in version 50 or newer…
There was a grace period in which JVMs supported a fall-back mode for class files with broken StackMapTables just for scenarios like yours, where the tool support is not up-to-date. (See -XX:+FailoverToOldVerifier or -XX:-UseSplitVerifier) But the grace period is over now and that support has been declined, i.e. Java 8 JVMs do not support the fall-back mode anymore.
If you want to keep up with the Java development and instrument newer class files which might use features of these new versions you have only two choices:
Calculate the correct StackMapTable manually
Use a tool which supports calculating the correct StackMapTable attributes, e.g. ASM, (see java-bytecode-asm) does support it

Warning: File for type '[Insert class here]' created in the last round will not be subject to annotation processing

I switched an existing code base to Java 7 and I keep getting this warning:
warning: File for type '[Insert class here]' created in the last round
will not be subject to annotation processing.
A quick search reveals that no one has hit this warning.
It's not documented in the javac compiler source either:
From OpenJDK\langtools\src\share\classes\com\sun\tools\javac\processing\JavacFiler.java
private JavaFileObject createSourceOrClassFile(boolean isSourceFile, String name) throws IOException {
checkNameAndExistence(name, isSourceFile);
Location loc = (isSourceFile ? SOURCE_OUTPUT : CLASS_OUTPUT);
JavaFileObject.Kind kind = (isSourceFile ?
JavaFileObject.Kind.SOURCE :
JavaFileObject.Kind.CLASS);
JavaFileObject fileObject =
fileManager.getJavaFileForOutput(loc, name, kind, null);
checkFileReopening(fileObject, true);
if (lastRound) // <-------------------------------TRIGGERS WARNING
log.warning("proc.file.create.last.round", name);
if (isSourceFile)
aggregateGeneratedSourceNames.add(name);
else
aggregateGeneratedClassNames.add(name);
openTypeNames.add(name);
return new FilerOutputJavaFileObject(name, fileObject);
}
What does this mean and what steps can I take to clear this warning?
Thanks.

The warning
warning: File for type '[Insert class here]' created in the last round
will not be subject to annotation processing
means that your were running an annotation processor creating a new class or source file using a javax.annotation.processing.Filer implementation (provided through the javax.annotation.processing.ProcessingEnvironment) although the processing tool already decided its "in the last round".
This may be problem (and thus the warning) because the generated file itself may contain annotations being ignored by the annotation processor (because it is not going to do a further round).
The above ought to answer the first part of your question
What does this mean and what steps can I take to clear this warning?
(you figured this out already by yourself, didn't you :-))
What possible steps to take? Check your annotation processors:
1) Do you really have to use filer.createClassFile / filer.createSourceFile on the very last round of the annotaion processor? Usually one uses the filer object inside of a code block like
for (TypeElement annotation : annotations) {
...
}
(in method process). This ensures that the annotation processor will not be in its last round (the last round always being the one having an empty set of annotations).
2) If you really can't avoid writing your generated files in the last round and these files are source files, trick the annotation processor and use the method "createResource" of the filer object (take "SOURCE_OUTPUT" as location).

In OpenJDK test case this warning produced because processor uses "processingOver()" to write new file exactly at last round.
public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv) {
if (renv.processingOver()) { // Write only at last round
Filer filer = processingEnv.getFiler();
Messager messager = processingEnv.getMessager();
try {
JavaFileObject fo = filer.createSourceFile("Gen");
Writer out = fo.openWriter();
out.write("class Gen { }");
out.close();
messager.printMessage(Diagnostic.Kind.NOTE, "File 'Gen' created");
} catch (IOException e) {
messager.printMessage(Diagnostic.Kind.ERROR, e.toString());
}
}
return false;
}
I modified original example code a bit. Added diagnostic note "File 'Gen' created", replaced "*" mask with "org.junit.runner.RunWith" and set return value to "true". Produced compiler log was:
Round 1:
input files: {ProcFileCreateLastRound}
annotations: [org.junit.runner.RunWith]
last round: false
Processor AnnoProc matches [org.junit.runner.RunWith] and returns true.
Round 2:
input files: {}
annotations: []
last round: true
Note: File 'Gen' created
Compilation completed successfully with 1 warning
0 errors
1 warning
Warning: File for type 'Gen' created in the last round will not be subject to annotation processing.
If we remove my custom note from log, it's hard to tell that file 'Gen' was actually created on 'Round 2' - last round. So, basic advice applies: if in doubt - add more logs.
Where is also a little bit of useful info on this page:
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html
Read section about "ANNOTATION PROCESSING" and try to get more info with compiler options:
-XprintProcessorInfo
Print information about which annotations a processor is asked to process.
-XprintRounds Print information about initial and subsequent annotation processing rounds.

I poked around the java 7 compiler options and I found this:
-implicit:{class,none}
Controls the generation of class files for implicitly loaded source files. To automatically generate class files, use -implicit:class. To suppress class file generation, use -implicit:none. If this option is not specified, the default is to automatically generate class files. In this case, the compiler will issue a warning if any such class files are generated when also doing annotation processing. The warning will not be issued if this option is set explicitly. See Searching For Types.
Source
Can you try and implicitly declare the class file.

Error while trying to validate XML in Java

I'm trying to validate one xml that I create with a local schema, but some freak error is throwing. My code:
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setValidating(true);
factory.setNamespaceAware(true);
SchemaFactory schemaFactory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
factory.setSchema(schemaFactory.newSchema(
new Source[] {new StreamSource("\\.\\schema\\xsd_me_ene_diaria.xsd")}));
And my stack trace is the follow.
java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"
at javax.xml.parsers.SAXParserFactory.setSchema(Unknown Source)
at SaxValidacao.validateSchema(SaxValidacao.java:36)
The error throws just after setSchema is called.
Some clue or another tip for XML validation in Java?

One thing that sometimes happens is mixing of different versions of the parser. If you use java 5 or higher, try removing references to any external xalan or xerces libraries. (All you need to process xml is included in the standard distribution of java 5)

I found a solution in a CodeWall article, add one line Java code to your codebase.
System.setProperty("javax.xml.parsers.SAXParserFactory","com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");
Please refer to get more detail: https://coderwall.com/p/kqsrrw/jdom2-this-parser-does-not-support-specification-null-version-null

Can you turn off validation and parse the stream? If yes, it's not likely to be a JAR conflict.
I'm thinking that your issue is access to the schema.

A possible issue is that your JAXP parser is very old and doesn't support setSchema method. Look at the javadoc for SAXParsesrFactory. For setSchema (and many other methods), it says:
Throws:
java.lang.UnsupportedOperationException
- For backward compatibility, when implementations for earlier versions
of JAXP is used, this exception will
be thrown.
Check the parser implementation that you are using and try updating to a newer version.