Compilation in IntelliJ uses HUGE command line

jimka · April 24, 2019, 12:23pm

When I use the “Run” feature in IntelliJ, I suppose IntelliJ runs the scala compiler, and uses the following 3908 character command line for java. Is this normal? Do I need to be concerned? I looks like something is configured incorrectly.

/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/bin/java "-javaagent:/Applications/IntelliJ IDEA CE.app/Contents/lib/idea_rt.jar=52687:/Applications/IntelliJ IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Users/jnewton/Library/Application Support/IdeaIC2019.1/Scala/lib/runners.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/lib/tools.jar:/Users/jnewton/scalain_e/scalain-e-course-code/target/scala-2.12/test-classes:/Users/jnewton/scalain_e/scalain-e-course-code/target/scala-2.12/classes:/Users/jnewton/.ivy2/cache/junit/junit/jars/junit-4.10.jar:/Users/jnewton/.ivy2/cache/org.scalacheck/scalacheck_2.12/jars/scalacheck_2.12-1.14.0.jar:/Users/jnewton/.ivy2/cache/org.scala-sbt/test-interface/jars/test-interface-1.0.jar:/Users/jnewton/.ivy2/cache/org.hamcrest/hamcrest-core/jars/hamcrest-core-1.1.jar:/Users/jnewton/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.12.8.jar:/Users/jnewton/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.12.8.jar:/Users/jnewton/.ivy2/cache/org.scala-lang.modules/scala-xml_2.12/bundles/scala-xml_2.12-1.0.6.jar:/Users/jnewton/.ivy2/cache/org.scala-lang.plugins/scala-continuations-library_2.12/bundles/scala-continuations-library_2.12-1.0.3.jar:/Users/jnewton/.ivy2/cache/org.scalactic/scalactic_2.12/bundles/scalactic_2.12-3.0.5.jar:/Users/jnewton/.ivy2/cache/org.scalatest/scalatest_2.12/bundles/scalatest_2.12-3.0.5.jar" org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestRunner -s GraphTestSuite -C org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestReporter -showProgressMessages true

tarsa · April 24, 2019, 1:08pm

It’s normal. Most of the command line is occupied by explicit classpath, which obviously is going to be huge. Most of the remaining command line parts are related to integration with IntelliJ features. You won’t be doing that when running programs from command line. E.g. if you package your program into a single JAR then only java -jar program.jar would suffice. IntelliJ needs that long classpath list because it skips packaging, i.e. it uses JARs from source locations (Java installation dir, ivy2 folders) and unpackaged compiled code (.class files).

billy_chang · April 24, 2019, 4:38pm

this is what it looks like in all its uglious glory *ROTFLMAOTIPIMP*…

jducoeur · April 24, 2019, 6:27pm

There’s an important implication here, which may not be obvious if you’re not used to the JVM: JVM programs, by default, have a lot of this sort of thing. Unless you explicitly compile your program together into a single JAR (as @tarsa mentions), the program is instead assembled at runtime by loading in all of these classes from the classpath, and it’s not unusual for that classpath to get quite large for complex programs.

This is, obviously, a pain if you are trying to copy a program from one place to another, which is why JARring it up is a common and popular thing to do. But it doesn’t happen automatically…

jeffdyke · April 24, 2019, 10:42pm

While i’m pretty new b/c i don’t write scala every day, but we’ve installed fswatch and run our projects with sbt -> [projectname], then fswatchRun and the project directory:

lazy val fswatchRun = taskKey[Unit]("Run and watch files with fswatch")
fswatchRun := {
  new FswatchRun(
    state.value,
    _.runTask(compile in Compile, _),
    _.runInputTask(run in Compile, "", _),
    _.runTask(PlayInternalKeys.playStop, _),
    PlayKeys.playMonitoredFiles.value,
    watchSources.value,
    streams.value.log).start()
}

YMMV, but unless you’re sure that intellij is configured to compile not with the internal compiler but with the jdk that you specified, i like to roll this way. This is very good at incremental compiles, in my experience. I guess i’m a bit biased against IDEA b/c their incremental compiler can’t pick up advanced FP concepts and some other similar things.

Best,

Jeff