Scala sometimes fails to load a jar

Have you ever found that it fails if you specify the full path, e.g.

  scala -cp /home/stevens/devel/sspace-lib.jar MyScalaProg.scala

(assuming that you only need stuff in the jar and not in the current directory, and assuming that I have that path correct)?

I have also noticed behavior that seems somewhat variable with jars, but providing that canonical path has always gotten around the problem (so I haven't investigated what, precisely, causes the issue).

  --Rex

On Thu, Feb 9, 2012 at 12:12 PM, fozziethebeat <fozziethebeat@gmail.com> wrote:

Hello all,

I've been using scala fairly heavily and often just write short one
object programs that tie together a number of classes defined in a
java package i've been working with, as if my scala code is the main
for the java tools.  I tend to run things without compiling with
simple commands like:

   scala -cp sspace-lib.jar MyScalaProg.scala args_here

And that works for the most part, except on certain occasions where
scala, for reasons unknown, fails to load the associated jar, sspace-
lib.jar.  Sometimes I can solve this by running scala from where the
jar is located, othertimes it's the exact opposite.  Here's some
sample runs to clarify:

$ scala -cp bin/sspace-lib.jar DTest.scala

   /home/stevens/devel/S-Space/DTest.scala:32: error: not found:
value log
       a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
(v._2+eps))).sum

Everything looks as expected, I forgot to import log but otherwise it
recognizes my java based imports

$ cd bin
$ scala -cp sspace-lib.jar ../DTest.scala

 /home/stevens/devel/S-Space/bin/../DTest.scala:1: error: not found:
object edu
 import edu.ucla.sspace.vector.CompactSparseVector
        ^
 /home/stevens/devel/S-Space/bin/../DTest.scala:2: error: not found:
object edu
 import edu.ucla.sspace.common.Similarity
        ^
 /home/stevens/devel/S-Space/bin/../DTest.scala:32: error: not found:
value log
         a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
(v._2+eps))).sum
                                                       ^
 three errors found

Everything is not fine, my two imports using the sspace-lib.jar are
not recognized when I try to run scala from the jar's local
directory.

If i try to compile, things seem to work as normal, and I can
similarly load the jar into the interpreter from any directory.  It
just seems to be that this particular use case *sometimes* doesn't
work.  It's very finicky.

I can't really imagine why or how scala would fail to load up a jar
based on the current running directory.  Has anyone else run into
similar problems?  I've had this occur on two separate Redhat linux
machines and a Ubuntu laptop.  All systems are running Java 6 with a
fairly recent sun jvm.  I'm also using Scala version 2.9.1.final.

I haven't tried giving a full path yet. I will try that the next time
the problem occurs (oddly it's not occuring right now).

Also, I've noticed that sometimes after running scala, and the program
finishes, there is sometimes an orphaned scala or java process still
running. If I kill that process the problem sometimes goes away.
I've also had instances where scala won't load up the freshest version
of the jar, as in I the scala program once with version an of the jar,
recompile the java jar to get version b, and then run the scala
program again with the new version (but still the same location on
disk) and scala doesn't pick up the changes.

It's *very* bizarre and I'm not quite sure how to diagnose/debug such
a thing.

On Feb 9, 10:02 am, Rex Kerr wrote:
> Have you ever found that it fails if you specify the full path, e.g.
>
>   scala -cp /home/stevens/devel/sspace-lib.jar MyScalaProg.scala
>
> (assuming that you only need stuff in the jar and not in the current
> directory, and assuming that I have that path correct)?
>
> I have also noticed behavior that seems somewhat variable with jars, but
> providing that canonical path has always gotten around the problem (so I
> haven't investigated what, precisely, causes the issue).
>
>   --Rex
>
> On Thu, Feb 9, 2012 at 12:12 PM, fozziethebeat wrote:
>
> > Hello all,
>
> > I've been using scala fairly heavily and often just write short one
> > object programs that tie together a number of classes defined in a
> > java package i've been working with, as if my scala code is the main
> > for the java tools.  I tend to run things without compiling with
> > simple commands like:
>
> >    scala -cp sspace-lib.jar MyScalaProg.scala args_here
>
> > And that works for the most part, except on certain occasions where
> > scala, for reasons unknown, fails to load the associated jar, sspace-
> > lib.jar.  Sometimes I can solve this by running scala from where the
> > jar is located, othertimes it's the exact opposite.  Here's some
> > sample runs to clarify:
>
> > $ scala -cp bin/sspace-lib.jar DTest.scala
>
> >    /home/stevens/devel/S-Space/DTest.scala:32: error: not found:
> > value log
> >        a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> > (v._2+eps))).sum
>
> > Everything looks as expected, I forgot to import log but otherwise it
> > recognizes my java based imports
>
> > $ cd bin
> > $ scala -cp sspace-lib.jar ../DTest.scala
>
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:1: error: not found:
> > object edu
> >  import edu.ucla.sspace.vector.CompactSparseVector
> >         ^
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:2: error: not found:
> > object edu
> >  import edu.ucla.sspace.common.Similarity
> >         ^
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:32: error: not found:
> > value log
> >          a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> > (v._2+eps))).sum
> >                                                        ^
> >  three errors found
>
> > Everything is not fine, my two imports using the sspace-lib.jar are
> > not recognized when I try to run scala from the jar's local
> > directory.
>
> > If i try to compile, things seem to work as normal, and I can
> > similarly load the jar into the interpreter from any directory.  It
> > just seems to be that this particular use case *sometimes* doesn't
> > work.  It's very finicky.
>
> > I can't really imagine why or how scala would fail to load up a jar
> > based on the current running directory.  Has anyone else run into
> > similar problems?  I've had this occur on two separate Redhat linux
> > machines and a Ubuntu laptop.  All systems are running Java 6 with a
> > fairly recent sun jvm.  I'm also using Scala version 2.9.1.final.
>
>

As you are all aware (right?), when Scala runs scripts it starts an
fsc daemon to compile the scripts, so that load time of each script is
decreased. That daemon, obviously, treats all relatives path as
relative to *its* current directory -- the directory where it was
first started. Naturally, that means that executing a script on a
different directory than the one fsc was started at (which you don't
quite know, since fsc will shutdown after a while) with a relative
path to a jar will result in error, as fsc will try to find that jar
from a directory other than the one you intended.

Of course, all this is well-known and, besides, obvious, so I presume
this isn't your problem. That being the case, I have no idea what else
could it be. :-)

On Thu, Feb 9, 2012 at 15:12, fozziethebeat wrote:
> Hello all,
>
> I've been using scala fairly heavily and often just write short one
> object programs that tie together a number of classes defined in a
> java package i've been working with, as if my scala code is the main
> for the java tools.  I tend to run things without compiling with
> simple commands like:
>
>    scala -cp sspace-lib.jar MyScalaProg.scala args_here
>
> And that works for the most part, except on certain occasions where
> scala, for reasons unknown, fails to load the associated jar, sspace-
> lib.jar.  Sometimes I can solve this by running scala from where the
> jar is located, othertimes it's the exact opposite.  Here's some
> sample runs to clarify:
>
> $ scala -cp bin/sspace-lib.jar DTest.scala
>
>    /home/stevens/devel/S-Space/DTest.scala:32: error: not found:
> value log
>        a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> (v._2+eps))).sum
>
> Everything looks as expected, I forgot to import log but otherwise it
> recognizes my java based imports
>
> $ cd bin
> $ scala -cp sspace-lib.jar ../DTest.scala
>
>  /home/stevens/devel/S-Space/bin/../DTest.scala:1: error: not found:
> object edu
>  import edu.ucla.sspace.vector.CompactSparseVector
>         ^
>  /home/stevens/devel/S-Space/bin/../DTest.scala:2: error: not found:
> object edu
>  import edu.ucla.sspace.common.Similarity
>         ^
>  /home/stevens/devel/S-Space/bin/../DTest.scala:32: error: not found:
> value log
>          a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> (v._2+eps))).sum
>                                                        ^
>  three errors found
>
> Everything is not fine, my two imports using the sspace-lib.jar are
> not recognized when I try to run scala from the jar's local
> directory.
>
> If i try to compile, things seem to work as normal, and I can
> similarly load the jar into the interpreter from any directory.  It
> just seems to be that this particular use case *sometimes* doesn't
> work.  It's very finicky.
>
> I can't really imagine why or how scala would fail to load up a jar
> based on the current running directory.  Has anyone else run into
> similar problems?  I've had this occur on two separate Redhat linux
> machines and a Ubuntu laptop.  All systems are running Java 6 with a
> fairly recent sun jvm.  I'm also using Scala version 2.9.1.final.

Gosh! That was totally on the tip of my tongue! It's only the most
obvious design choice for running any script or compiler. Who'd be
silly enough to have a daemon use relative paths from where the script
is currently being executed as opposed to a long forgotten directory?

Thanks Daniel, that does explain all the oddity that i've been seeing
and why absolute pathing works propperly. I guess i should stop being
lazy and either compile these beasts or use absolute pathing.

On Feb 9, 11:44 am, Daniel Sobral wrote:
> As you are all aware (right?), when Scala runs scripts it starts an
> fsc daemon to compile the scripts, so that load time of each script is
> decreased. That daemon, obviously, treats all relatives path as
> relative to *its* current directory -- the directory where it was
> first started. Naturally, that means that executing a script on a
> different directory than the one fsc was started at (which you don't
> quite know, since fsc will shutdown after a while) with a relative
> path to a jar will result in error, as fsc will try to find that jar
> from a directory other than the one you intended.
>
> Of course, all this is well-known and, besides, obvious, so I presume
> this isn't your problem. That being the case, I have no idea what else
> could it be. :-)
>
>
>
> On Thu, Feb 9, 2012 at 15:12, fozziethebeat wrote:
> > Hello all,
>
> > I've been using scala fairly heavily and often just write short one
> > object programs that tie together a number of classes defined in a
> > java package i've been working with, as if my scala code is the main
> > for the java tools.  I tend to run things without compiling with
> > simple commands like:
>
> >    scala -cp sspace-lib.jar MyScalaProg.scala args_here
>
> > And that works for the most part, except on certain occasions where
> > scala, for reasons unknown, fails to load the associated jar, sspace-
> > lib.jar.  Sometimes I can solve this by running scala from where the
> > jar is located, othertimes it's the exact opposite.  Here's some
> > sample runs to clarify:
>
> > $ scala -cp bin/sspace-lib.jar DTest.scala
>
> >    /home/stevens/devel/S-Space/DTest.scala:32: error: not found:
> > value log
> >        a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> > (v._2+eps))).sum
>
> > Everything looks as expected, I forgot to import log but otherwise it
> > recognizes my java based imports
>
> > $ cd bin
> > $ scala -cp sspace-lib.jar ../DTest.scala
>
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:1: error: not found:
> > object edu
> >  import edu.ucla.sspace.vector.CompactSparseVector
> >         ^
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:2: error: not found:
> > object edu
> >  import edu.ucla.sspace.common.Similarity
> >         ^
> >  /home/stevens/devel/S-Space/bin/../DTest.scala:32: error: not found:
> > value log
> >          a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
> > (v._2+eps))).sum
> >                                                        ^
> >  three errors found
>
> > Everything is not fine, my two imports using the sspace-lib.jar are
> > not recognized when I try to run scala from the jar's local
> > directory.
>
> > If i try to compile, things seem to work as normal, and I can
> > similarly load the jar into the interpreter from any directory.  It
> > just seems to be that this particular use case *sometimes* doesn't
> > work.  It's very finicky.
>
> > I can't really imagine why or how scala would fail to load up a jar
> > based on the current running directory.  Has anyone else run into
> > similar problems?  I've had this occur on two separate Redhat linux
> > machines and a Ubuntu laptop.  All systems are running Java 6 with a
> > fairly recent sun jvm.  I'm also using Scala version 2.9.1.final.
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

On Thu, Feb 9, 2012 at 20:38, fozziethebeat wrote:
> Gosh! That was totally on the tip of my tongue! It's only the most
> obvious design choice for running any script or compiler.  Who'd be
> silly enough to have a daemon use relative paths from where the script
> is currently being executed as opposed to a long forgotten directory?

Ain't that so? :-)

>
> Thanks Daniel, that does explain all the oddity that i've been seeing
> and why absolute pathing works propperly.  I guess i should stop being
> lazy and either compile these beasts or use absolute pathing.

Actually, there's a flag that prevents the use of fsc, which also
takes care of it. I don't think the added load time is worth the
trouble, though.

>
> On Feb 9, 11:44 am, Daniel Sobral wrote:
>> As you are all aware (right?), when Scala runs scripts it starts an
>> fsc daemon to compile the scripts, so that load time of each script is
>> decreased. That daemon, obviously, treats all relatives path as
>> relative to *its* current directory -- the directory where it was
>> first started. Naturally, that means that executing a script on a
>> different directory than the one fsc was started at (which you don't
>> quite know, since fsc will shutdown after a while) with a relative
>> path to a jar will result in error, as fsc will try to find that jar
>> from a directory other than the one you intended.
>>
>> Of course, all this is well-known and, besides, obvious, so I presume
>> this isn't your problem. That being the case, I have no idea what else
>> could it be. :-)
>>
>>
>>
>> On Thu, Feb 9, 2012 at 15:12, fozziethebeat wrote:
>> > Hello all,
>>
>> > I've been using scala fairly heavily and often just write short one
>> > object programs that tie together a number of classes defined in a
>> > java package i've been working with, as if my scala code is the main
>> > for the java tools.  I tend to run things without compiling with
>> > simple commands like:
>>
>> >    scala -cp sspace-lib.jar MyScalaProg.scala args_here
>>
>> > And that works for the most part, except on certain occasions where
>> > scala, for reasons unknown, fails to load the associated jar, sspace-
>> > lib.jar.  Sometimes I can solve this by running scala from where the
>> > jar is located, othertimes it's the exact opposite.  Here's some
>> > sample runs to clarify:
>>
>> > $ scala -cp bin/sspace-lib.jar DTest.scala
>>
>> >    /home/stevens/devel/S-Space/DTest.scala:32: error: not found:
>> > value log
>> >        a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
>> > (v._2+eps))).sum
>>
>> > Everything looks as expected, I forgot to import log but otherwise it
>> > recognizes my java based imports
>>
>> > $ cd bin
>> > $ scala -cp sspace-lib.jar ../DTest.scala
>>
>> >  /home/stevens/devel/S-Space/bin/../DTest.scala:1: error: not found:
>> > object edu
>> >  import edu.ucla.sspace.vector.CompactSparseVector
>> >         ^
>> >  /home/stevens/devel/S-Space/bin/../DTest.scala:2: error: not found:
>> > object edu
>> >  import edu.ucla.sspace.common.Similarity
>> >         ^
>> >  /home/stevens/devel/S-Space/bin/../DTest.scala:32: error: not found:
>> > value log
>> >          a.zip(b).map(v=>if (v._1 == 0d) 0.0 else v._1 * log(v._1/
>> > (v._2+eps))).sum
>> >                                                        ^
>> >  three errors found
>>
>> > Everything is not fine, my two imports using the sspace-lib.jar are
>> > not recognized when I try to run scala from the jar's local
>> > directory.
>>
>> > If i try to compile, things seem to work as normal, and I can
>> > similarly load the jar into the interpreter from any directory.  It
>> > just seems to be that this particular use case *sometimes* doesn't
>> > work.  It's very finicky.
>>
>> > I can't really imagine why or how scala would fail to load up a jar
>> > based on the current running directory.  Has anyone else run into
>> > similar problems?  I've had this occur on two separate Redhat linux
>> > machines and a Ubuntu laptop.  All systems are running Java 6 with a
>> > fairly recent sun jvm.  I'm also using Scala version 2.9.1.final.
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.

On Fri, Feb 10, 2012 at 5:37 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, there's a flag that prevents the use of fsc, which also takes care of it. I don't think the added load time is worth the
trouble, though.

scala -nocompdaemon
-jason