While compiling my play Scala project I saw the next error message:
error: error while loading String, class file '/root/.sbt/1.0/java9-rt-ext-private_build_17_0_2/rt.jar(java/lang/String.class)' is broken
(class java.lang.NullPointerException/Cannot invoke "scala.tools.nsc.Global$Run.typerPhase()" because the return value of "scala.tools.nsc.Global.currentRun()" is null)
This happened while using openJdk17 and openJdk 11.
Any suggestions?
Thanks
Related
I have a local build of the scala compiler. I get the following exception when I use the three jars for the compiler (compiler/reflect/library) from my build in another Scala application (http://ikojo.in/):
[Thu Aug 25 11:24:22 EDT 2022, Utils] SEVERE: Problem
java.lang.NoSuchMethodError: 'boolean java.lang.StringBuilder.isEmpty()'
at scala.tools.nsc.ast.parser.Scanners$Scanner.checkNoTrailingSeparator(Scanners.scala:1264)
at scala.tools.nsc.ast.parser.Scanners$Scanner.getNumber(Scanners.scala:1302)
at scala.tools.nsc.ast.parser.Scanners$Scanner.fetchToken(Scanners.scala:632)
at scala.tools.nsc.ast.parser.Scanners$Scanner.nextToken(Scanners.scala:422)
...
at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:401)
at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1519)
at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1503)
at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.compile(IMain.scala:744)
at scala.tools.nsc.interpreter.IMain$Request.$anonfun$compile$7(IMain.scala:978)
at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.scala:17)
at scala.tools.nsc.interpreter.IMain$.withSuppressedSettings(IMain.scala:1407)
Please note that Java Runtime8 is a caller in this stack trace. The exception is very early in the compiler code itself: during the very first phase of the compiler, the syntax analyzer, out of 23 (or more) phases.
Also note that the code of my local build of the compiler is identical to the official scala release (from: https://github.com/scala/scala/releases/tag/v2.13.6).
I checked the answer to a related question java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z but that doesn't seem to have a good answer, or at least, it is not clear to me.
Does anybody have any hints or any leads on how to debug or resolve this?
In Java versions before 15, java.lang.StringBuilder doesn't have an isEmpty method; Java versions after Java 15 have an isEmpty method.
The Scala compiler's code has a StringBuilderOps implicit class which has an isEmpty method.
Thus, when compiling the Scala compiler with a Java version before 15, the compiler sees (at line 1264) that we're calling the isEmpty method on a StringBuilder. Since there's no isEmpty method on java.lang.StringBuilder, the compiler looks for a class which StringBuilder is implicitly convertible to which has an isEmpty method. If there's exactly one such class (in this case StringBuilderOps), then the compiler says "this isn't an error" and effectively replaces the cbuf.isEmpty call with something like either:
(new StringBufferOps(cbuf)).isEmpty, or
StringBufferOps$.isEmpty(cbuf)
(these are both effectively the same thing: the second one is devirtualized into a static call and might be generated because StringBufferOps extends AnyVal). Note that this does not result in a call to an isEmpty on a StringBufferOps.
If the Java version you're building the compiler with is Java 15 or later, then the compiler sees that there's an isEmpty method on StringBuilder and eventually when it comes time to emit the Java bytecode, it emits the usual code for calling the isEmpty method on a StringBuilder in the JVM.
Because java.lang and similar packages are provided by the Java runtime, they're not included in the jar files. So if you then run the resulting jar files on a pre-Java 15 JVM, there's a reference in the bytecode to a method that doesn't exist and the JVM throws the NoSuchMethodError.
At least for now, I don't believe the Scala compiler officially supports being built with versions of Java that aren't Java 8 or Java 11. If building with a later version, be careful to not use your built compiler with Java versions earlier than what you built with.
Java version which results in the error is the following:
ben#Bulents-MacBook-Pro ~ % java -version
java -version
java version "15.0.1" 2020-10-20
Java(TM) SE Runtime Environment (build 15.0.1+9-18)
Java HotSpot(TM) 64-Bit Server VM (build 15.0.1+9-18, mixed mode, sharing)
Instead, when I compile the scala compiler with the following, the error is resolved:
ben#Bulents-MacBook-Pro ~ % java -version
java -version
java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
I am not sure why or how this works, but it does. I have some guesses, but, they are not very educated. So, if anybody has a deeper insight, please share. Thank you.
I am importing a Scala project after building it using sbt, in sbt library dependencies are json4s-native & json4s-jackson...
After building the project using sbt eclipse while importing it in Eclipse it gives following error:
Error in Scala compiler
java.lang.StackOverflowError
This screen comes:
& then this:
Scala version: 2.11.7
Log:
!ENTRY org.scala-ide.sdt.core 4 0 2017-09-08 12:42:02.495 !MESSAGE Error in Scala compiler
!STACK 0
java.lang.StackOverflowError
at scala.tools.nsc.typechecker.Typers$Typer.checkDead(Typers.scala:111)
at scala.tools.nsc.typechecker.Typers$Typer.typedSelectOrSuperCall$1(Typers.scala:4812)
at scala.tools.nsc.typechecker.Typers$Typer.typedInAnyMode$1(Typers.scala:5344)
Adding following parameter to eclipse.ini worked:
-Xss100m
This seems to be a Scala compiler bug (not Eclipse related):
Update Scala since some StackOverflowError bugs of the Scala compiler have already been fixed since version 2.11.7
If updating Scala does not help, you have to find out which code causes the error and how to avoid it (see open Scala StackOverflowError bugs).
I am running:
java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
sbt 0.13.13.
on Windows 10.
When I follow the tutorial to do a println("hello"), I get the error:
[error] No valid parser available.
Do you guys have any idea why that might be and how to resolve?
Thank you very much in advance!
You entered into the sbt shell, which is used to give commands for a project build.
It sounds like you want a Scala console. You can start it by:
sbt console
I am running a web application with Scala version 2.9.0 and Scalatra version 2.1.0-SNAPSHOT. I build the application with Java 1.6. It runs fine when I run it with Java 1.7 but fails when ran with Java 1.8 with this error. What can be the issue?
It is important for me to run with java 1.8 is because I have some third party jars used in my application which are complied with java 1.8. I have other scala applications with I have built with java 1.6 and run fine with java 1.8 but I am only facing this issue with applications using scalatra.
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error that prevented it from fulfilling this request.
exception
org.fusesource.scalate.TemplateException
org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:834)
org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:691)
org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:411)
org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:405)
org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:475)
org.scalatra.scalate.ScalateSupport$class.renderScalateErrorPage(ScalateSupport.scala:140)
org.scalatra.scalate.ScalateSupport$class.handle(ScalateSupport.scala:131)
root cause
java.lang.NullPointerException
scala.tools.nsc.Global$Run.compileLate(Global.scala:1043)
scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:303)
scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:111)
scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:85)
scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:732)
The release notes for Scala 2.9 list it's dependencies: "It requires the Java runtime version 1.6 or 1.7." Scala 2.11.1 announced support for Java 8 but called that "experimental." The experimental adjective was dropped from the release notes in Scala 2.11.2, but I've had problems with Java 8 in projects using later versions of Scala (probably 2.11.7).
I get the following error when I try to run the SCALA REPL. Note that I have already looked into this post where it talks about downgrading java version.
sg#IN0D196716 C:\Users\sg
$ java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
sg#IN0D196716 C:\Users\sg
$ scala
Exception in thread "main" java.lang.NoSuchMethodError: scala.util.matching.Regex.unapplySeq(Ljava/lang/CharSequence;)Lscala/Option;
at scala.tools.nsc.settings.ScalaVersion$.apply(ScalaVersion.scala:104)
at scala.tools.nsc.settings.ScalaVersion$.apply(ScalaVersion.scala:114)
at scala.tools.nsc.settings.ScalaVersion$.<init>(ScalaVersion.scala:119)
at scala.tools.nsc.settings.ScalaVersion$.<clinit>(ScalaVersion.scala)
at scala.tools.nsc.settings.ScalaSettings$class.$init$(ScalaSettings.scala:138)
at scala.tools.nsc.settings.MutableSettings.<init>(MutableSettings.scala:20)
at scala.tools.nsc.Settings.<init>(Settings.scala:12)
at scala.tools.nsc.GenericRunnerSettings.<init>(GenericRunnerSettings.scala:11)
at scala.tools.nsc.GenericRunnerCommand.<init>(GenericRunnerCommand.scala:18)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:41)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
Sorry, dude, that's my fault.
A few years ago, someone said you should only be able to use a regex to extract from strings (char sequences).
That was such a reasonable request. "Tell me if I try to match a regex to something that isn't even a string!"
Unfortunately, because JVM and maven and ivy, you never know what backwards compatibility issues you'll discover.
As you have discovered.
Scala requires that you build and run with the same "major" version.
Here is a similar issue where "user experience" diverges:
https://issues.scala-lang.org/browse/SI-9380
Additional apologies if you don't prefer the gendered "dude", if it is gendered.