I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
Related
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
All groovyconsole binary distros I have found don't support Java 14. The console complains if you try to specify a Jar file that has been compiled with Java 14, for example.
The obvious solution, I thought, was to build Groovy with Java 14. That seems non-trivial.
gradle.wrapper.properties files contain
distributionUrl=http://services.gradle.org/distributions/gradle-2.3-bin.zip
which is a broken URL. Change that to https and then it works, partially.
You then get
FAILURE: Build failed with an exception.
What went wrong:
Could not determine java version from '14.0.2'.
Reading the docs for gradle makes it clear that most (all?) versions of gradle do not support Java 14. Definitely version 2.3 does not. Why - I have no idea.
So... back to my original question. How can I get a groovy installation to support Java 14?
Thanks!
If the Jar cannot be loaded, it is most likely the asm lib, which is unable to read it. To read Java14 you need at least ASM 7.2 I think. ASM in Groovy is not provided as standalone library, because of possible conflicts with other jar dependencies it is shadowed (bytecode is transformed by renaming the packages and directly added to the Groovy jar). I see here 2 options:
compile Groovy yourself and change the dependencies to have at least ASM 7.2. It does not matter if you build Groovy with a lower version of the JDK, the JDK still allows to read "old" jars.
use at least Groovy 2.5.9, 3.0.0 or 2.4.19, as they include asm 7.2 or higher
Of course this does not mean it will change the Groovy Gradle is using easily. For that I would use Groovy 2.5 and read Bumping Groovy version in Gradle?
If this does not solve the problem or answer the question I would need more details.
I'm using Eclipse 4.5 with the Groovy-Eclipse 2.9.2/4.5 plugin which I thought was supposed to have the Groovy 2.5 compiler. However, it didn't have any picocli support so I added the groovy-cli-picocli-2.5.2-indy.jar to my classpath and was able to compile. However #2, when trying to run the script via Eclipse I get:
java.lang.ClassNotFoundException: picocli.CommandLine$ParameterException
It looks like groovy-cli-picocli-2.5.2-indy.jar does not have CommandLine class at all.
I would just throw jars at this from the fullblown picocli distribution but I'm under the impression they all have to somehow wrap nicely into Eclipse Groovy library via groovy.cli.picocli.CliBuilder.
Is my Groovy 2.5.2 missing this or am I somehow missing the boat on how it's supposed to work because picocli is not working for me in this configuration. Thanks!
You are correct: groovy-cli-picocli-2.5.2.jar (and groovy-cli-picocli-2.5.2-indy.jar) do not contain the picocli classes.
You need to add the picocli jar to the classpath.
If you use Maven, the groovy-all POM should include all dependencies.
(My original answer mentioned picocli classes that are shaded into the groovy-2.5.x.jar under the groovyjarjarpicocli package but these are intended for use internally by Groovy and not meant to be used by applications.)
I have used this tool: https://github.com/etiennestuder/gradle-jooq-plugin
from jOOQ's official website to generate code from my database.
Yet if I set
directory = 'src/main/java'
when I run "gradle build", I get all these compile errors like:
database/information_schema/InformationSchema.java:218: error: no suitable constructor found for SchemaImpl(String,<null>)
super("INFORMATION_SCHEMA", null);
^
constructor SchemaImpl.SchemaImpl(Name) is not applicable
(actual and formal argument lists differ in length)
constructor SchemaImpl.SchemaImpl(String) is not applicable
(actual and formal argument lists differ in length)
Any fix for this?
Note that I wanted to put the generated code into the src folder because I want to use them in my code. I've heard to put them in the target or build folder instead, but I'm not sure how do you access those classes from target or build folder?
Thanks!
I was on 3.7. Now I switch to 3.9, everything turns out to be fine...
I've written a short blog post about this. Starting with jOOQ 3.16 and #12601, there's an additional compilation error in case users use:
An older version of org.jooq:jooq (the runtime library)
A newer version of org.jooq:jooq-codegen (the code generation library)
In general, the runtime library version >= codegen library version. The new compilation error might look like this:
[ERROR] …/DefaultCatalog.java:[53,73] cannot find symbol
[ERROR] symbol: variable VERSION_3_17
[ERROR] location: class org.jooq.Constants
I am trying to generate Excel using Xssf API because its memory footprint is small.
It is working fine in my local machine which is having jdk1.7.
But when I try to run it on UNIX where java version is 1.6.0_75 it gives me the following error.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller
I have following jars in my classpath
poi-3.11-20141221.jar
poi-excelant-3.11-20141221.jar
poi-ooxml-3.11-20141221.jar
poi-ooxml-schemas-3.11-20141221.jar
xmlbeans-2.6.0.jar
xercesImpl.jar
I have verified that poi-3.11-20141221.jar has the ZipPackagePropertiesMarshaller class.
Seems that some jar is missing.
Am I missing something?
I have found a solution to my own problem.
I replaced poi-3.11-20141221.jar with poi-ooxml-3.9.jar. That worked.
Java version 1.6.0_75 does not exists, I suppose you make a typo. The last update of Java 6 is the update 45 (6u45).
The class ZipPackagePropertiesMarshaller is loaded at run-time for sure. The exception NoClassDefFoundError occurs during the initialization phase; if the exception had been ClassNotFoundException, it would have been different...
The class ZipPackagePropertiesMarshaller is unaltered between the versions 3.11 and 3.9, but the class PackagePropertiesMarshaller extended by ZipPackagePropertiesMarshaller is changed: the main change regards the use of StAX in the newer version.
The distribution of StAX coming with Java 6, but the version of Java 6 update 18 (http://www.oracle.com/technetwork/java/javase/6u18-142093.html) introduces the StAX 1.2 API version.
Consider to use Java 6u18 or newer. This should solve your problem.
In the official FAQ there are some indications about a similar problem: https://poi.apache.org/faq.html#faq-N1017E.
Moreover, the workaround you found is not the best one, see the last FAQ of POI.