While using JDK internal Xerces implementation, I have the following issue:
At compile javac warns me that
XMLSchema.java:28: warning: XSConstants is internal proprietary API and may be removed in a future release
[javac] import com.sun.org.apache.xerces.internal.xs.XSConstants;
but fails to find com.sun.org.apache.xerces.internal.xs.datatypes package.
XMLSchema.java:35: error: package com.sun.org.apache.xerces.internal.xs.datatypes does not exist
[javac] import com.sun.org.apache.xerces.internal.xs.datatypes.ObjectList;
What could be the issue here?
I'm using JDK 1.8
The problem has been reported and answered before: Using internal sun classes with javac
When javac is compiling code it doesn't link against rt.jar by default. Instead it uses special symbol file lib/ct.sym with class stubs.
Surprisingly this file contains many but not all of internal sun classes. In my case one of those more-internal-than-usual classes was com.sun.org.apache.xerces.internal.xs.datatypes.ObjectList (adapted answer)
Related
Updated with more details :
My objective is to set source of below code .
source(sourceSets.map { it.javaDirectories }.flatten())
above code working fine with jdk 1.8 but when I changed to jdk 11 then
Task :quality-tools:compileKotlin FAILED
The kotlin-dsl plugin applied to project ':quality-tools' enables experimental Kotlin compiler features.
My import inside Kotlin file :
import jdk.nashorn.internal.objects.NativeRegExp.source
Console error : Symbol is declared in module 'jdk.scripting.nashorn' which does not export package 'jdk.nashorn.internal.objects'
My code inside same Kotlin file:
source(sourceSets.map { it.javaDirectories }.flatten())
Console error :Symbol is declared in module 'jdk.scripting.nashorn' which does not export package 'jdk.nashorn.internal.objects'
Build scan for your reference :
https://gradle.com/s/neicp3tzhs3yo
#TODO
If symbol is declared in module ‘jdk.scripting.nashorn' then how can I export package jdk.nashorn.internal.objects' in jdk 11 or any alternative to set source as I mentioned above ?
I found this link when I investigated further.
https://docs.oracle.com/javase/9/docs/api/jdk.scripting.nashorn-summary.html
Thanks
Jitendra
Because I did not kotlinx , But import jdk.nashorn.internal.runtime.GlobalConstants is in my code , So solved after deleting.
I am having an issue of Android module compilation.
I have created a module for some compression/decompression task and therefore I need to use Base64 Java class and hence adding the required package to import Base64.
import com.sun.org.apache.xml.internal.security.exceptions.Base64DecodingException;
import com.sun.org.apache.xml.internal.security.utils.Base64;
If I remove these classes and comment their codes, then module builds successfully, and if I use these classes to support Base64 encoding/decoding then module is failed to build.
Does anyone know here the reason or solution?
Here are some last log lines from build_android.log file:
"/Users/jalvin/Documents/Appcelerator_Studio_Workspace/gziplibrary/android/build/classes" "-target" "1.6" "-g" "-source" "1.6" "#/Users/jalvin/Documents/Appcelerator_Studio_Workspace/gziplibrary/android/java-sources.txt" "-processor" "org.appcelerator.kroll.annotations.generator.KrollJSONGenerator" "-s" "/Users/jalvin/Documents/Appcelerator_Studio_Workspace/gziplibrary/android/build/generated/json" "-Akroll.jsonFile=gziplibrary.json" "-Akroll.jsonPackage=org.appcelerator.titanium.bindings" "-Akroll.checkTiContext=true"
[ERROR] Failed to compile Java source files:
com.sun.* classes are not part of the Java API, and you shouldn't be relying on them. I would suggest using Apache Commons Codec to do Base64 encoding instead.
(source: Package com.sun.org.apache.xml.internal.security.utils.Base64 does not exist)
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.
I have installed grails and am trying to compile with the default version of cache:1.1.6 and I'm getting these errors within the plugin code.
Can any one help me with which dependency is broken in the repository - I havent even used the cache yet - just defined it in BuildConfig.groovy
I understand "By default, Grails will not only get the JARs and plugins that you declare, but it will also get their transitive dependencies" so why would I have to declare the dependencies?
Compilation error: startup failed:
Compile error during compilation with javac.
D:\Users\ve\.grails\2.4.0\projects\demo\plugins\cache-1.1.6\src\java\grails\plugin\cache\CustomCacheKeyGenerator.java:18: error: package org.springframework.aop.framework does not exist
import org.springframework.aop.framework.AopProxyUtils;
^
D:\Users\ve\.grails\2.4.0\projects\demo\plugins\cache-1.1.6\src\java\grails\plugin\cache\web\PageInfo.java:43: error: package org.springframework.aop does not exist
import org.springframework.aop.PointcutAdvisor;
^
D:\Users\ve\.grails\2.4.0\projects\demo\plugins\cache-1.1.6\src\java\grails\plugin\cache\web\PageInfo.java:44: error: package org.springframework.aop does not exist
import org.springframework.aop.TargetSource;
Odd this is with a new Grails application? It sounds like it could be a corrupt Maven cache issue. Try doing:
$ rm -rf ~/.m2/repository
Otherwise, to declare the dependency explicitly edit BuildConfig and add:
compile 'org.springframework:spring-aop:4.0.5.RELEASE'
To your dependencies block.
I know that a java.lang.NoSuchMethodError means that the version of a class used for compiling is different from the version used at runtime. Usually, when I see this issue, I start the app.server in java -verbose mode, which tells me the jar file from which a class is loaded. If that jar file is not the one I intended to use, I know I'm using an incorrect version of the jar file.
Another approach I use, is to use javap to look at the method signatures of the class in the jar file I am using at runtime, to confirm that the jar does indeed contain the class with a different method signature.
I am seeing this error now in Karaf, an OSGi container and none of the above approaches are helping. java -verbose shows me the jar, javap shows me the method signature and the method signature is the same as that in the error stacktrace. In other words, I can see that the class from the jar being used at runtime does have the same method signature that the jvm says it cannot find.
Here is the exact stack trace, if it helps:
java.lang.NoSuchMethodError: org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/axiom/soap/SOAPModelBuilder;
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659)
Are there any other approaches I can/should use? Thanks for your help.
The Karaf commands exports [ids], imports [ids] and classes [ids] can used in combination with grep (each command has a --help option).
From the bundle throwing the error (with id N), imports N | grep org.apache.axiom.om will tell you which bundle it is actually importing that package from.
And approaching from the other side, exports | grep org.apache.axiom.om will list the bundles that export that package.
I'd expect you'll see more than one line from the exports and the import command will show incorrect version is being used.
You could also use java -verbose:class to see where classes are loaded from, which might show that the problematic class is loaded from a different bundle that you expected.