[scala-ide-user] run as "scala application" is actually ran as a "java"

36 views
Skip to first unread message

Razie

unread,
May 6, 2010, 2:46:35 PM5/6/10
to Scala IDE User
There is an issue where the difference between scala and java
(commandlines) are apparent, see description here:

http://scala-programming-language.1934581.n4.nabble.com/nst-Interpreter-has-changed-Help-tp2131270p2132008.html

- basically scala doesn't assume you want to use the Java classpath,
this is applicable when using the parser/interpreter.

The eclipse plugin, when choosing "run as scala application"
apparently runs it as Java Launchers with only the scala classes added
to the classpath.

I don't know if this is a problem or not...I kept running all my scala
apps with java...I'm just bringing up for discussion...

Since scala apps are meant to run on the JVM and probably everybody
associates that with ">java MyClass" then it should probably remain
the same?

Regards,
Razvan

Miles Sabin

unread,
May 7, 2010, 9:49:44 AM5/7/10
to scala-i...@googlegroups.com
On Thu, May 6, 2010 at 7:46 PM, Razie <razv...@gmail.com> wrote:
> There is an issue where the difference between scala and java
> (commandlines) are apparent, see description here:
>
> http://scala-programming-language.1934581.n4.nabble.com/nst-Interpreter-has-changed-Help-tp2131270p2132008.html
>
> - basically scala doesn't assume you want to use the Java classpath,
> this is applicable when using the parser/interpreter.
>
> The eclipse plugin, when choosing "run as scala application"
> apparently runs it as Java Launchers with only the scala classes added
> to the classpath.

Not quite, it also adds the Scala classpath container to the
classpath, and as far as I know it does the Right Thing. Do you have
an example where it doesn't?

> I don't know if this is a problem or not...I kept running all my scala
> apps with java...I'm just bringing up for discussion...
>
> Since scala apps are meant to run on the JVM and probably everybody
> associates that with ">java MyClass" then it should probably remain
> the same?

I'm not quite following ... there is a difference between "Run As =>
Scala application" and "Run As => Java application" currently,
specifically to handle the necessary additions to the classpath for
Scala. Is there something you think should be being done differently?

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Razie

unread,
May 7, 2010, 10:45:51 AM5/7/10
to Scala IDE User
Sorry - did not clarify it :)

The example in the thread I pointed to is running the exact same
compiled .class with the Java or the scala command lines, same
classpath, producing two different results, see below.

The reason is given by PaulP in the same thread: the scala parser/
interpreter does not assume you want to use the Java classpath by
default anymore.


~/w/scripster\> java -classpath ./gugu/:/host/bin/scala/lib/scala-
library.jar:/host/bin/scala/lib/scala-compiler.jar JMain

produces this:

Exception in thread "Thread-0"
scala.tools.nsc.MissingRequirementError: object scala not found.
at scala.tools.nsc.symtab.Definitions$definitions
$.getModuleOrClass(Definitions.scala:518)
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:89)
at scala.tools.nsc.symtab.Definitions$definitions
$.init(Definitions.scala:788)
at scala.tools.nsc.Global$Run.<init>(Global.scala:593)
at scala.tools.nsc.Interpreter.scala$tools$nsc$Interpreter$
$_initialize(Interpreter.scala:112)
at scala.tools.nsc.Interpreter$$anonfun$initialize$1.apply$mcZ
$sp(Interpreter.scala:125)
at scala.tools.nsc.Interpreter$$anonfun$initialize
$2.apply(Interpreter.scala:125)
at scala.tools.nsc.Interpreter$$anonfun$initialize
$2.apply(Interpreter.scala:125)
at scala.concurrent.ThreadRunner$$anon$2$$anonfun$run
$2.apply(ThreadRunner.scala:46)
at scala.concurrent.ThreadRunner.scala$concurrent$ThreadRunner$
$tryCatch(ThreadRunner.scala:32)
at scala.concurrent.ThreadRunner$$anon
$2.run(ThreadRunner.scala:46)
at java.lang.Thread.run(Thread.java:619)


NOTE that the same ran with scala instead of java works:

~/w/scripster\> scala -classpath ./gugu/:/host/bin/scala/lib/scala-
library.jar:/host/bin/scala/lib/scala-compiler.jar JMain
res0: Int = 3
Success
~/w/scripster\>

For some reason, though, the eclipse scala plugin will behave just
like the "java" command line above, even though the program is ran as
a "Scala Application".

What gives?


On May 7, 9:49 am, Miles Sabin <mi...@milessabin.com> wrote:
> On Thu, May 6, 2010 at 7:46 PM, Razie <razvan...@gmail.com> wrote:
> > There is an issue where the difference between scala and java
> > (commandlines) are apparent, see description here:
>
> >http://scala-programming-language.1934581.n4.nabble.com/nst-Interpret...

Miles Sabin

unread,
May 7, 2010, 10:56:50 AM5/7/10
to scala-i...@googlegroups.com
On Fri, May 7, 2010 at 3:45 PM, Razie <razv...@gmail.com> wrote:
> Sorry - did not clarify it :)
>
> The example in the thread I pointed to is running the exact same
> compiled .class with the Java or the scala command lines, same
> classpath, producing two different results, see below.
>
> The reason is given by PaulP in the same thread: the scala parser/
> interpreter does not assume you want to use the Java classpath by
> default anymore.

Ahh ... right ... that's a bug. Could you create a ticket (on Assembla
:-) to the effect that Run as => Scala application should behave
identically to the scala command line tool and that the -usejavacp
option should be supported.

It'd be great if you could check the embedded console and see whether
or not (most likely not) it does the Right Thing ...

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com

Miles Sabin

unread,
May 7, 2010, 11:12:21 AM5/7/10
to scala-i...@googlegroups.com
Hi Razvan,

Thanks for adding the new FAQ entry :-)

I tweaked it a little to give it a bit more context ... would you mind
updating it with the relevant versions and dates?

Thanks again ...

Cheers,


Miles

On Fri, May 7, 2010 at 3:45 PM, Razie <razv...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages