[scala] recent changes in 2.8 nightly classpath management

[daniel mahler]

It seems that sometime in the last month the 2.8 nighly
has changed the way it manages classpath.
Was that intentional?

I have had various tools stop working because they cannnot find the
scala package.
I register the scala jar files with the framework I use and do not use
the provided scripts.
This used to work fine a month ago.

thanks
Daniel

[daniel mahler]

The error message I get is

scala.tools.nsc.MissingRequirementError: object scala not found.
        at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:456)
        at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackage(Definitions.scala:43)
        at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackageClass(Definitions.scala:44)
        at scala.tools.nsc.symtab.Definitions$definitions$.UnitClass(Definitions.scala:67)
        at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:728)
        at scala.tools.nsc.Global$Run.<init>(Global.scala:664)
        at scala.tools.nsc.Main$.process(Main.scala:109)
        at scala.tools.nsc.Main$.main(Main.scala:124)
        at scala.tools.nsc.Main.main(Main.scala)
error: fatal error: object scala not found.

Actually I may have misinterprted the problem, since it is running at
least ssome code
in the scala package, but why would it not be able to find scala then?

thanks
Daniel

On Fri, Nov 6, 2009 at 4:35 PM, Daniel Mahler <dmahler@...> wrote:

> It seems that sometime in the last month the 2.8 nighly
> has changed the way it manages classpath.
> Was that intentional?
>
> I have had various tools stop working because they cannnot find the
> scala package.
> I register the scala jar files with the framework I use and do not use
> the provided scripts.
> This used to work fine a month ago.
>
> thanks
> Daniel
>

[Eric Willigers]

I've been experiencing the same problem.

Here's an example that used to work:-




// Compile.scala

import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.reporters.ConsoleReporter

object Compile
{
     def main(args: Array[String]): Unit =
     {
         val settings = new Settings()

         settings.target.value = "jvm-1.5"
         settings.deprecation.value = true // enable detailed
deprecation warnings
         settings.unchecked.value = true // enable detailed unchecked
warnings
         settings.outdir.value = "."
         val reporter = new ConsoleReporter(settings)

         val compiler = new Global(settings, reporter)
         val run = (new compiler.Run)
         run.compile(List("Test.scala"))

         reporter.printSummary
         if (reporter.hasErrors || reporter.WARNING.count > 0)
         {
             error("Errors or warnings detecting during compile")
         }
     }
}



touch Test.scala

rm -f *.class
2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
java -cp
"2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;."
Compile
   (success)

rm -f *.class
2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
java -cp
"2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;."
Compile
   Exception in thread "main" scala.tools.nsc.MissingRequirementError:
   object scala not found.

[Lukas Rytz]

Hello Daniel, Eric

this behavior is expected, there was a change in the way the "classpath" setting is defined.

Before, the value of "-classpath" was defined by:
 1) the user-specified value ("-classpath x"), or else
 2) the value of the "CLASSPATH" environment variable, or else
 3) the value of the java property "java.class.path", which is the "-classpath x" given to the java command, or else
 4) the current directroy.


We decided to remove 3) as this can put unexpected things on scalac's classpath.

http://lampsvn.epfl.ch/trac/scala/changeset/19285/scala/trunk/src/compiler/scala/tools/nsc/Settings.scala


You can make the example below work by adding

       settings.classpath.value = System.getProperty("java.class.path")

 

Cheers: Lukas

On Mon, Nov 9, 2009 at 00:15, Eric Willigers <ewilligers@...> wrote:

I've been experiencing the same problem.

Here's an example that used to work:-




// Compile.scala

import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.reporters.ConsoleReporter

object Compile
{
   def main(args: Array[String]): Unit =
   {
       val settings = new Settings()

       settings.target.value = "jvm-1.5"
       settings.deprecation.value = true // enable detailed deprecation warnings
       settings.unchecked.value = true // enable detailed unchecked warnings
       settings.outdir.value = "."
       val reporter = new ConsoleReporter(settings)

       val compiler = new Global(settings, reporter)
       val run = (new compiler.Run)
       run.compile(List("Test.scala"))

       reporter.printSummary
       if (reporter.hasErrors || reporter.WARNING.count > 0)
       {
           error("Errors or warnings detecting during compile")
       }
   }
}



touch Test.scala

rm -f *.class
2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
java -cp "2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;." Compile
 (success)

rm -f *.class
2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
java -cp "2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;." Compile
 Exception in thread "main" scala.tools.nsc.MissingRequirementError:
 object scala not found.

[daniel mahler]

This messes up plugging scala jars into java environments
that manage things via $CLASSPATH and do not know or care
what language a jar file comes from.

What was the issue with the old way?
Having the worong things on your classpath
seems to be a case of GIGO.
Scala libraries can depend on Java libs & vice versa,
this just seems to make interoperability harder.

Is there a flag to enable the old behaviour?

cheers
Daniel

On 11/9/09, Lukas Rytz <lukas.rytz@...> wrote:

> Hello Daniel, Eric
>
> this behavior is expected, there was a change in the way the "classpath"
> setting is defined.
>
> Before, the value of "-classpath" was defined by:
>  1) the user-specified value ("-classpath x"), or else
>  2) the value of the "CLASSPATH" environment variable, or else
>  3) the value of the java property "java.class.path", which is the
> "-classpath x" given to the java command, or else
>  4) the current directroy.
>
>
> We decided to remove 3) as this can put unexpected things on scalac's
> classpath.
>
> http://lampsvn.epfl.ch/trac/scala/changeset/19285/scala/trunk/src/compiler/scala/tools/nsc/Settings.scala
>
>
> You can make the example below work by adding
>
>        settings.classpath.value = System.getProperty("java.class.path")
>
>
>
> Cheers: Lukas
>
>
>
> On Mon, Nov 9, 2009 at 00:15, Eric Willigers <ewilligers@...> wrote:
>
>> I've been experiencing the same problem.
>>
>> Here's an example that used to work:-
>>
>>
>>
>>
>> // Compile.scala
>>
>> import scala.tools.nsc.{Global, Settings}
>> import scala.tools.nsc.reporters.ConsoleReporter
>>
>> object Compile
>> {
>>    def main(args: Array[String]): Unit =
>>    {
>>        val settings = new Settings()
>>
>>        settings.target.value = "jvm-1.5"
>>        settings.deprecation.value = true // enable detailed deprecation
>> warnings
>>        settings.unchecked.value = true // enable detailed unchecked
>> warnings
>>        settings.outdir.value = "."
>>        val reporter = new ConsoleReporter(settings)
>>
>>        val compiler = new Global(settings, reporter)
>>        val run = (new compiler.Run)
>>        run.compile(List("Test.scala"))
>>
>>        reporter.printSummary
>>        if (reporter.hasErrors || reporter.WARNING.count > 0)
>>        {
>>            error("Errors or warnings detecting during compile")
>>        }
>>    }
>> }
>>
>>
>>
>> touch Test.scala
>>
>> rm -f *.class
>> 2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
>> java -cp
>> "2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;."
>> Compile
>>  (success)
>>
>> rm -f *.class
>> 2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
>> java -cp
>> "2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;."
>> Compile
>>  Exception in thread "main" scala.tools.nsc.MissingRequirementError:
>>  object scala not found.
>>
>>
>>
>

[Lukas Rytz]

On Fri, Nov 13, 2009 at 19:09, Daniel Mahler <dmahler@...> wrote:

This messes up plugging scala jars into java environments
that manage things via $CLASSPATH and do not know or care
what language a jar file comes from.

I don't understand, can you make an example?
 

What was the issue with the old way?

The problem is that there can be a scala-library / scala-compiler in scalac's
classpath which one wouldn't expect. This can be tedious when developing
the compiler / library.


 

Having the worong things on your classpath
seems to be a case of GIGO.

It's sometimes not that easy to find out.
 

Scala libraries can depend on Java libs & vice versa,
this just seems to make interoperability harder.

Well, we're talking about running the scala compiler from java,
not running a any other scala program. I think it's actually useful
to have control over what the compiler has in its classpath in
such cases.

In any case, here's some more documentation on the whole business:
http://lampsvn.epfl.ch/trac/scala/wiki/Classpath

 

Is there a flag to enable the old behaviour?

Not currently...
 

cheers
Daniel

On 11/9/09, Lukas Rytz <lukas.rytz@...> wrote:
> Hello Daniel, Eric
>
> this behavior is expected, there was a change in the way the "classpath"
> setting is defined.
>
> Before, the value of "-classpath" was defined by:
>  1) the user-specified value ("-classpath x"), or else
>  2) the value of the "CLASSPATH" environment variable, or else
>  3) the value of the java property "java.class.path", which is the
> "-classpath x" given to the java command, or else
>  4) the current directroy.
>
>
> We decided to remove 3) as this can put unexpected things on scalac's
> classpath.
>
> http://lampsvn.epfl.ch/trac/scala/changeset/19285/scala/trunk/src/compiler/scala/tools/nsc/Settings.scala
>
>
> You can make the example below work by adding
>
>        settings.classpath.value = System.getProperty("java.class.path")
>
>
>
> Cheers: Lukas
>
>
>
> On Mon, Nov 9, 2009 at 00:15, Eric Willigers <ewilligers@...> wrote:
>
>> I've been experiencing the same problem.
>>
>> Here's an example that used to work:-
>>
>>
>>
>>
>> // Compile.scala
>>
>> import scala.tools.nsc.{Global, Settings}
>> import scala.tools.nsc.reporters.ConsoleReporter
>>
>> object Compile
>> {
>>    def main(args: Array[String]): Unit =
>>    {
>>        val settings = new Settings()
>>
>>        settings.target.value = "jvm-1.5"
>>        settings.deprecation.value = true // enable detailed deprecation
>> warnings
>>        settings.unchecked.value = true // enable detailed unchecked
>> warnings
>>        settings.outdir.value = "."
>>        val reporter = new ConsoleReporter(settings)
>>
>>        val compiler = new Global(settings, reporter)
>>        val run = (new compiler.Run)
>>        run.compile(List("Test.scala"))
>>
>>        reporter.printSummary
>>        if (reporter.hasErrors || reporter.WARNING.count > 0)
>>        {
>>            error("Errors or warnings detecting during compile")
>>        }
>>    }
>> }
>>
>>
>>
>> touch Test.scala
>>
>> rm -f *.class
>> 2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
>> java -cp
>> "2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;."
>> Compile
>>  (success)
>>
>> rm -f *.class
>> 2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
>> java -cp
>> "2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;."
>> Compile
>>  Exception in thread "main" scala.tools.nsc.MissingRequirementError:
>>  object scala not found.
>>
>>
>>
>