Exactly what the title says.
I have a class which declares certain native methods, but also has a couple of inner classes. The javah utility insists on generating separate headers for the inner classes even though they don't have any native method declarations. Is there a way to force javah to stop doing this (annotations, secret command-line switches, anything)?
I don't know any way to do that. (I use the Oracle JDK.)
I understand the annoyance but the problem is limited to unnecessary files and their unnecessary regeneration (outer class changes result in rewriting the useless header files for inner classes).
To solve the problem, I just delete all the empty header files. I use Ant, since it is available as a generic project builder step in Eclipse.
<?xml version="1.0" encoding="UTF-8"?>
<project name="javah">
<mkdir dir="javah" />
<javah classpath="bin" destdir="javah">
<!-- list classes here -->
<class name="com.example.Outer" />
<class name="com.example.OuterWithNatives" />
</javah>
<delete>
<fileset dir="javah">
<not>
<contains text="JNIEXPORT" />
</not>
</fileset>
</delete>
</project>
Related
I would like to apply the JPA 2.0 Criteria API to a Hibernate legacy application in order to get type-safe queries. Manual model creation is not an option; neither is the introduction of annotations (i.e. converting *.hbm.xml mappings into JPA annotations).
I tried to use Hibernate's "hibernate-jpamodelgen-4.3.6.Final.jar" generator without luck so far. The idea was to have a "dummy" entity to kick in Hibernate's annotation processor (JPAMetaModelEntityProcessor). Then, so my hopes, JPAMetaModelEntityProcessor would detect persistence.xml and would eventually be smart enough to also detect XML configured entities.
That's a real pity that three years after this question was asked, with Hibernate v. 5.2.12, it's still not easy to find how to generate metamodel without use of annotations. Anyway I am going to describe my solution here as this question (without any answer) pops up as the search result for the query "Generate metamodel without annotations". I struggled a bit with this task, but after all I got there with this ANT task:
<target name="jpa_metamodel">
<delete dir="..\\src_tmp"/>
<copy todir="..\\src_tmp">
<fileset dir="..\\src">
<include name="my/model/package/*.java"/>
<include name="META-INF/**/*.xml"/>
</fileset>
</copy>
<replace file="../src_tmp/my/model/package/AbstractEntity.java" token="class" value="#javax.persistence.Entity class"/>
<javac srcdir="..\\src_tmp"
destdir="..\\src_jpa_generated"
failonerror="true"
fork="false">
<compilerarg value="-proc:only"/>
<compilerarg line="-s ..\\src_jpa_generated"/>
<compilerarg line="-Adebug=true"/>
<classpath>
<fileset dir="..\\dependencies\\hibernate">
<include name="**\\*.jar"/>
</fileset>
<pathelement location="../src_tmp"/> <!-- to put META-INF in classpath -->
</classpath>
</javac>
</target>
Problems with Hibernate medamodel generator are:
/META-INF/persistence.xml and /META-INF/orm.xml are searched in classpath, and not in source folder. However it seems to be not enough, because after mapping XMLs are added to classpath they are correctly discovered and generator processes mentioned classes (log entries for every class are emitted), but still, for some reason, no output is produced. So to the next step...
It seems that it's not really possible to go further without actual annotation. Or maybe it is, but I still don't know how, but I can live with simple workaround. I simply automatically add #Entity annotation to temporarily copied sources. Actually I add the annotation in only one file, but in my case it happens to be a root of my entity hierarchy. This might have a meaning, and might not - I did not bother checking. However the need for this step indicates it might be difficult (impossible?) to generate metamodel for entity classes compiled without annotations.
You need to remember about -s compiler arg to store generated *.java files somewhere.
Hope this might be helpful for someone in the future.
I am running find bugs in ant and am trying to set everything (attributes, options, etc) in my ant build.xml to the most sensitive settings for finding bugs. From reading the documentation and looking at example here is what I concluded will be the most sensitive settings for if a bug is ran into. If it is not please let me know any attribute, options, etc that needed to be added or changed to find all the bugs that may be in my code.
<target name="findbugs" depends="jar">
<findbugs home="/home/me/Desktop/findbugs"
output="html"
outputFile="bc.html"
effort="max"
reportLevel="low"
workHard="true"
debug="true">
<auxClasspath path="../foo/bin"/>
<auxClasspath path="../bar/bin"/>
<sourcePath path="../foo2/src" />
<class location="bin/"/>
</findbugs>
</target>
No need for workHard="true" since you already have effort='max'. They're just synonyms of each other. Otherwise, it looks like you have it.
There are includeFilter and excludeFilter, but if you don't list either of those, you get all bugs.
I am using JUnit4 and want to put some extra information to be displayed in JUnit reports.
For this, I shall be dumping the extra information to the report xml and then modify the xslt to read that extra information to generate the HTML report.
Steps so far that are working are:
Copied all the code from XMLJUnitResultFormatter to MyFormatter.java and modified the endTest() method to add that extra information in the form of an extra attribute to testcase XML tag.
This is really bad :( but I could not simply override it as there usages of the private instance variables directly without getters/setters in endTest() method.
My junit ant task:
<junit fork="yes" printsummary="withOutAndErr">
<!--<formatter type="xml"/>-->
<formatter classname="com.some.junit.MyFormatter" extension=".xml"/>
<test name="com.some.source.MyTestClassTest" todir="${junit.output.dir}"/>
<classpath refid="JUnitProject.classpath"/>
</junit>
Modified the xslt to read the extra attribute of TESTCASE xml tag and display in report.
My modified ant task for report:
<target name="junitreport" depends="MyTestClassTest">
<junitreport todir="${junit.output.dir}">
<fileset dir="${junit.output.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report styledir="reportstyle" format="frames" todir="${junit.output.dir}"/>
</junitreport>
</target>
I came across using TestNG nor SureFire Maven plugins as solutions, but I can't use them in my project.
Is there any better way than this in JUnit4?
Maybe?
The interface org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter is what needs to be implemented for a custom output format. This could write to any output stream, which is all the extensiblity that was built into the framework. You are right, there isn't a good way to extend the capabilities of XMLJUnitResultFormatter to customize the output. A copy-paste-modify certainly isn't ideal, but certainly acceptable.
Another approach might be to have more than one formatter defined in your ant task. One could be the regular xml formatter, with another being your custom one for additional information. These two files could be combined and then turned into HTML using xsl transforms.
I leave it to you to decide if this a better method than you had devised.
I am hoping someone has experienced this issue and can maybe shed some light.
I have an xml schema and an ant build file. The output .java files differ when I run ant on Windows versus Mac, even if I am using the same jaxb-xjc.jar to do the xml-compiling. The Windows side is naming the "getter" methods for attributes as "getX". The Mac side wants to name them "isX". Anyone experience anything like this before and/or have a solution? This is consistent between Windows Vista & 7 doing this the one way and Mac OSX 10.6 & 10.7 (untested on Mac OSX 10.8) doing it the other.
----edit----
I'll attach some of the code from the ant build.xml file.
Telling it what the xjc is.
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="classpath"/>
</taskdef>
Here is the 'actual' compiling:
Compiling the automaton schema
<echo>Compiling old automaton schema</echo>
<xjc schema="${oldxml-schema}" destdir="${src.dir}" package="${oldxml.package}">
<produces dir="${oldxml-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the plugin schema</echo>
<mkdir dir="${plugin-gen.dir}" />
<xjc schema="${plugin-schema}" destdir="${src.dir}" package="${plugin.package}">
<produces dir="${plugin-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the pluginDesumaSide schema</echo>
<mkdir dir="${pluginDesumaSide-gen.dir}" />
<xjc schema="${pluginDesumaSide-schema}" destdir="${src.dir}" package="${pluginDesumaSide.package}">
<produces dir="${pluginDesumaSide-gen.dir}" includes="**/*.java"/>
</xjc>
</target>
All targets (by that I mean anything mentioned like ${}) are defined and every links and compiles right except for Mac naming the 'getter' methods as 'is' methods for variables. They are boolean attributes that do have defaults if non-specified.
From the responses I got I was able to google for a solution. Apparently this naming inconsistency and another (a getter returning a primitive but the setter only accepting objects) was apparent by chance for older xml-compilers due to some inconsistency in the specification.
This was fixed by going to http://jaxb.java.net/ and getting a new jaxb-impl.jar & jaxb-xjc.jar. I downloaded and ran the jaxb.jar file download and it created the needed jars.
I have the problem that an specific step in Ant can only be executed when we have Java 1.5 installed in the build computer. The task definition uses uses a jar file that was compiled using 1.5, so running with a 1.4 virtual machine will throw an IncompatibleClassVersion exception.
I have to find a solution meanwhile to have this task working for this specific project that requires 1.4, but a question came to me. How can I avoid defining this task and executing this optional step if I don't have a specific java version?
I could use the "if" or "unless" tags on the target tag, but those only check if a property is set or not. I also would like to have a solution that doesn't require extra libraries, but I don't know if the build-in functionality in standard is enough to perform such a task.
The Java version is exposed via the ant.java.version property. Use a condition to set a property and execute the task only if it is true.
<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="default">
<target name="default" depends="javaCheck" if="isJava6">
<echo message="Hello, World!" />
</target>
<target name="javaCheck">
<echo message="ant.java.version=${ant.java.version}" />
<condition property="isJava6">
<equals arg1="${ant.java.version}" arg2="1.6" />
</condition>
</target>
</project>
The property to check in the buildfile is ${ant.java.version}.
You could use the <condition> element to make a task conditional when a property equals a certain value:
<condition property="legal-java">
<matches pattern="1.[56].*" string="${ant.java.version}"/>
</condition>