I am getting started with Gradle on a polyglot java/scala project. The java modules are legacy modules built using JDK 1.6 so I decided to have my build environment use the older JDK.
This has a very practical rationale. Code such as the following:
class X{
private int i;
<T extends X> void aMethod(T t){
int it = t.i;
}
}
will compile fine using JDK 1.6 but will break with JDK 1.7 with the following error:
error: i has private access in X
For this reason (although unhappily) I decided to stick to JDK 1.6 (we do have code that looks like that).
Now I created a brand new Gradle project (no dependency/build tool was used before) with two modules:
myApp
|---- common (java module)
|---- someService (depends on common)
| |---- service (scala module)
| |---- api (java client)
and set the java source and target compatibility to 1.6. If I build with gradle everything works fine, i.e., the build runs and the jars get build correctly (both java and scala), without any error.
Now I generated my IntelliJ project files using the 'idea' plugin. IntelliJ loads up the project correctly. Now when I try and build from IntelliJ (Ctrl + F9) I get the following:
Information: Modules "myApp", "someService", "common" were fully rebuilt due to project configuration/dependencies changes
Information: Compilation completed with 4 errors and 44 warnings in 2 sec
Information: 4 errors
Information: 44 warnings
Error: scala: warning: [options] bootstrap class path not set in conjunction with -source 1.6
Error: scala: 1 error
Error: scala: 43 warnings
Warning: scala: Some input files use unchecked or unsafe operations.
Warning: scala: Recompile with -Xlint:unchecked for details.
... (the warnings follow)
error: properties has private access in X
As you can see, I am now getting the JDK 1.7 error (although I'm compiling with 1.6) and the build fails. IntelliJ says there are 4 errors but I believe the root cause is just that one.
Now If I go and fix the code above as follows:
class X{
private int i;
<T extends X> void aMethod(T t){
// SDK 1.7: explicit downcast grants access to base private members
int it = ((X)t).i;
}
}
I get the following error:
scala: Error: org.jetbrains.jps.incremental.scala.remote.ServerException
java.lang.InternalError
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:838)
...
at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1305)
...
at sbt.classfile.Analyze$$anonfun$apply$8$$anonfun$sbt$classfile$Analyze$$anonfun$$processDependency$1$1.apply$mcV$sp(Analyze.scala:49)
...
at scala.collection.immutable.HashSet$HashSet1.foreach(HashSet.scala:153)
...
at sbt.compiler.AggressiveCompile.compile1(AggressiveCompile.scala:44)
at org.jetbrains.jps.incremental.scala.local.CompilerImpl.compile(CompilerImpl.scala:63)
...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
at java.lang.reflect.Method.invoke(Method.java:606)
at com.martiansoftware.nailgun.NGSession.run(Unknown Source)
Caused by: java.io.FileNotFoundException: /usr/lib/jvm/java-7-oracle/jre/lib/resources.jar
...
which I believe is caused by the fact that I uninstalled JDK 1.7 and installed JDK 1.6 and somewhere in the IntelliJ paths something is still pointing at the old JDK.
So I have two questions:
1. How to get rid of any reference to JDK 1.7 in IntelliJ?
2. How to get rid of the first error altogether without changing the code? I know this is possible because Gradle does it successfully.
Silly me! I had uninstalled JDK 7 without restarting IntelliJ so it was still pointing to some of the JDK 7 folders. This was a very odd experience!
Related
Hi so i tried to build my project by running mvn clean install. Ideally, it'd build successfully since all my other team members can do so fine. It, however, says i'm running into test failures. This is the exact error log given:
Tests run: 22, Failures: 0, Errors: 22, Skipped: 0, Time elapsed: 0.739 sec <<< FAILURE! - in com.pic.resources.xxx() Time elapsed: 0.216 sec <<< ERROR!
org.mockito.exceptions.base.MockitoException:
Failed to release mocks
This should not happen unless you are using a third-part mock maker
at com.pic.resources.xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException:
Mockito cannot mock this class: class com.pic.service.xxx.
If you're not sure why you're getting this error, please report to the mailing list.
Java : 1.8
JVM vendor name : AdoptOpenJDK
JVM vendor version : 25.242-b08
JVM name : OpenJDK 64-Bit Server VM
JVM version : 1.8.0_242-b08
JVM info : mixed mode
OS name : Mac OS X
OS version : 10.16
You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.
Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.IllegalStateException:
Byte Buddy could not instrument all classes within the mock's type hierarchy
This problem should never occur for javac-compiled classes. This problem has been observed for classes that are:
- Compiled by older versions of scalac
- Classes that are part of the Android distribution
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
at
I have tried ALL the possible solutions i can think of
updated my JDK to 11 and changed the jdk version on intellij and pointed mvn to be to JDK 11
downgraded my JDK to 8 and did same step as 1) and added the right byte-buddy with an older version
upgraded to latest maven
cleared cache
used latest mockito version (then tried old mockito version and nothing happened)
running this in both intellij and the terminal didn't change anything. Even tried importing the right intellij settings. That didn't work
added byte-buddy dependency and made it the latest version
The only other possible cause of the problem is that I upgraded my Mac OS to Big Sur the other day and it screwed up my java run time, but I don't know if tht's a cause or not.
The underlying issue seems to be this:
java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
It might be the case that you have a package-private type and sign your jars, this does not normally work as the type needs to be placed in the same package which breaks the signature.
Getting this error message whenever I am trying to compile a plugin filter. Not sure what is causing that.
ImageJ 1.53a; Java 1.8.0_172 [64-bit]; Mac OS X 10.15.7; 33MB of 3000MB (1%)
warning: [options] bootstrap class path not set in conjunction with -source 1.6
/private/var/folders/nm/nftqfvnn4_7c87p06n3qztl00000gn/T/AppTranslocation/071310B3-FF74-405F-B175-3C92927EC9DB/d/ImageJ.app/plugins/Filters/Filter_Plugin.java:9: error: error while writing Filter_Plugin: /private/var/folders/nm/nftqfvnn4_7c87p06n3qztl00000gn/T/AppTranslocation/071310B3-FF74-405F-B175-3C92927EC9DB/d/ImageJ.app/plugins/Filters/Filter_Plugin.class (Read-only file system)
public class Filter_Plugin implements PlugInFilter {
^
1 error
1 warning
This is likely caused by the Path Randomization feature in Mac OSX (maybe because you're running ImageJ from within a mounted dmg file?).
See also this topic on the Image.sc forum:
https://forum.image.sc/t/imagej-stopped-working-when-we-upgraded-to-macos-sierra-10-12/3005/7?u=imagejan
Quoting from there:
You can disable path randomization by moving ImageJ.app out of the ImageJ folder and then copying it back.
In general, issues with ImageJ (both usage and development) are best discussed on https://forum.image.sc/tag/imagej.
I need to deploy my GWT application to an OC4J server using Java 6.
I'm using GWT SDK 2.7.0 - according to the release notes while Java 7 is the default, this can be overridden using -sourceLevel 6 which in Eclipse I am adding as a compiler argument.
This has solved most of the problems the OC4J progress text gave me when deploying my war - but one seems to remain.
Operation failed with error: com/google/gwt/user/server/rpc/RemoteServiceServlet : unsupported classversion 51.0
Ignoring the specificity of OC4J, why is the RemoteServiceServlet a Java 7 class, when I have set the GWT compiler to use Java 6?
It sounds like you aren't using the right version of GWT - either that isn't 2.7.0, or you are using the wrong jar:
$ javap -cp /Users/colin/.m2/repository/com/google/gwt/gwt-servlet/2.7.0/gwt-servlet-2.7.0.jar -v com.google.gwt.user.server.rpc.RemoteServiceServlet
Classfile jar:file:/Users/colin/.m2/repository/com/google/gwt/gwt-servlet/2.7.0/gwt-servlet-2.7.0.jar!/com/google/gwt/user/server/rpc/RemoteServiceServlet.class
Last modified Nov 20, 2014; size 11978 bytes
MD5 checksum ef76115d101d7321764ed74a7d8c1d62
Compiled from "RemoteServiceServlet.java"
public class com.google.gwt.user.server.rpc.RemoteServiceServlet extends com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet implements com.google.gwt.user.server.rpc.SerializationPolicyProvider
minor version: 0
major version: 50
...
I just checked gwt-user also, and it too is 50.0, check that your gwt-servlet is actually the version you think you are using?
Just run a sample Scala SBT project after installing Java 9 on my pc and I took this exception.
I already tried some solutions that I found but nothing.
Is there any incompatibility between Java 9 and Scala?
Scala Version: 2.12.3
Java Version: java version "9"
IDE: IntelliJ
Thanks in advance.
info] Compiling 7 Scala sources and 1 Java source to /Users/ermis/Projects/begining-scala/target/scala-2.12/classes...
[info] p.a.h.EnabledFilters - Enabled Filters (see <https://www.playframework.com/documentation/latest/Filters>):
play.filters.csrf.CSRFFilter
play.filters.headers.SecurityHeadersFilter
play.filters.hosts.AllowedHostsFilter
[info] play.api.Play - Application started (Dev)
Uncaught error from thread [play-dev-mode-akka.actor.default-
dispatcher-2]: javax/xml/bind/DatatypeConverter, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for for ActorSystem[play-dev-mode]
java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at io.jsonwebtoken.impl.Base64Codec.decode(Base64Codec.java:26)
at io.jsonwebtoken.impl.DefaultJwtBuilder.signWith(DefaultJwtBuilder.java:106)
at play.api.mvc.JWTCookieDataCodec$JWTFormatter.format(Cookie.scala:710)
at play.api.mvc.JWTCookieDataCodec.encode(Cookie.scala:569)
at play.api.mvc.JWTCookieDataCodec.encode$(Cookie.scala:567)
at play.api.mvc.DefaultJWTCookieDataCodec.encode(Cookie.scala:760)
at play.api.mvc.FallbackCookieDataCodec.encode(Cookie.scala:734)
at play.api.mvc.FallbackCookieDataCodec.encode$(Cookie.scala:733)
at play.api.mvc.DefaultSessionCookieBaker.encode(Session.scala:95)
at play.api.mvc.CookieBaker.encodeAsCookie(Cookie.scala:414)
at play.api.mvc.CookieBaker.encodeAsCookie$(Cookie.scala:413)
at play.api.mvc.DefaultSessionCookieBaker.encodeAsCookie(Session.scala:95)
at play.api.mvc.Result.$anonfun$bakeCookies$2(Results.scala:281)
at scala.Option.map(Option.scala:146)
at play.api.mvc.Result.bakeCookies(Results.scala:280)
at play.core.server.common.ServerResultUtils.prepareCookies(ServerResultUtils.scala:227)
at play.core.server.AkkaHttpServer.$anonfun$executeAction$3(AkkaHttpServer.scala:302)
at akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)
at akka.http.scaladsl.util.FastFuture$.transformWith$extension1(FastFuture.scala:55)
at akka.http.scaladsl.util.FastFuture$.flatMap$extension(FastFuture.scala:26)
at play.core.server.AkkaHttpServer.executeAction(AkkaHttpServer.scala:301)
at play.core.server.AkkaHttpServer.executeHandler(AkkaHttpServer.scala:254)
I tried this but didn't work.
--add-modules java.xml.bind
or
--add-modules java.se.ee
Try adding a compiler option to temporarily fix this:
--add-modules java.se.ee
since the Module shared by Java EE would not be resolved by default in JDK9.
You can also keep track of the issue to Support JDK 9 at scala-dev repository for updates as well.
I just remove Java 9 until someone gives me some lights and the compile works as usual.
I want to use 2 libraries that have been built with different and incompatible versions of JiBX.
Lib #1 runs with JiBX Runtime 1.0.1
Lib #2 runs with JiBX Runtime 1.2.6
The current version number is coded in the interface : org.jibx.runtime.IBindingFactory#CURRENT_VERSION_NUMBER .
When calling org.jibx.runtime.BindingDirectory#getFactory(), there's a compatibility test.
If the generated class and the runtime are incompatible, we got an exception like this :
Caused by: org.jibx.runtime.JiBXException: Binding information for
class Xxxx must be
regenerated with current binding compiler at
org.jibx.runtime.BindingDirectory.getFactoryFromName(Unknown Source)
at org.jibx.runtime.BindingDirectory.getFactory(Unknown Source)
EDIT - 29/07/2015
Another possible exception :
Caused by: org.jibx.runtime.JiBXException: Binding information for
class
Yyyyy must
be recompiled with current binding compiler (compiled with jibx_1_0_1,
runtime is jibx_1_2_5_SNAPSHOT) at
org.jibx.runtime.BindingDirectory.getFactoryFromName(BindingDirectory.java:125)
at
org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:178)
at
org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:197)
Is it possible to make it work ?
I've looked at the doc about JiBX Runtime but didn't found anything.
JiBX Runtime on Maven Central Repo.