Re: Scala Meeting Reports

AbstractFileClassLoader does not support getPackage

Fix to fjbg, do I need to replace starr?

Classes that have names starting from dollars

...ask for troubles.

Say, we've got a class $line5.$read$$iw$$iw$ (generated by REPL) that
corresponds to the innermost $iw from:

package $line5

object $read {
  object $iw {
    object $iw {
      ...
    }
}

Enclosing class for this class is $line5.$read$$iw$ (which is
correct), so we'd expect getSimpleName to return $iw$. However, what
really gets returned is iw$, because Java strips all leading dollars
and numbers from the simple name.

A sad consequence of that is that stuff that relies on getSimpleName
will not work (currently, this affects reflection, but I'm going to
change that, so it's not that big of a deal).

Bottom line of this post is that getSimpleName will work incorrectly
if class/object name intentionally starts with $. Is this something
we're fine with?

Re: Fix to fjbg, do I need to replace starr?

On Wed, Feb 1, 2012 at 5:44 AM, Grzegorz Kossakowski
<grzegorz.kossakowski@...> wrote:
> I have a bug-fix that touches src/fjbg. I'm wondering what I should do once
> I implement my fix? Should I rebuild a whole new starr so those changes are
> propagated to lib/fjbg.jar file?
>
> I was thinking about just rebuilding fjbg.jar using 'libs.fjbgpack' target
> and copying it manually to lib directory. My change is binary compatible so
> I don't think it would cause any problems. Thoughts?

All you need to do is replace fjbg.jar with your updated one, and then
run ./push-binary-libs.sh (with arguments of username and password
which allow you to push to artifactory - jsuereth can give you those
if you don't have them.) After that you will notice the
fjbg.sha1.desired file has been updated, at which point you can check
that in, and once it is merged into trunk future people will pull the
new fjbg.jar.

Those future people will have to run pull-binary-libs.sh manually to
get the update (or maybe it works automatically if you use sbt, but
I'm still on ant, where it will notice a change to scala-compiler.jar
and pull new libs, but not to anything else because it is comically
challenging to write a conditional like if "a or b or c" in antese.)

Re: Classes that have names starting from dollars

Re: Classes that have names starting from dollars

On Wed, Feb 1, 2012 at 7:28 AM, Eugene Burmako <eugene.burmako@...> wrote:
> Bottom line of this post is that getSimpleName will work incorrectly
> if class/object name intentionally starts with $. Is this something
> we're fine with?

We're not fine with any of it.  We should not settle for anything
short of 100% compatibility with java reflection, by which I mean:
your program should not ever explode just because you called some
method on Class or Method.

But I don't think we can get there unless we reserve something beyond
$ for internal use.  I would dearly like to do this.  It will only get
more difficult from here.  You can't imagine how many semantic
collisions we are amassing *internally* due to the use of the '$' for
every form of name encoding under the sun.  That's before one adds the
constraint that we have to comply with java's hardcoded internal
implementation of getSimpleName, inner classes, anonymous classes, and
on and on.

See also:

  https://issues.scala-lang.org/browse/SI-2806
  "Name mangling has outstripped the abilities of lonesome '$$'"

  https://issues.scala-lang.org/browse/SI-4316
  "name mangling vs. java reflection"

Also take a moment to laugh/cry about "lonesome '$$'", not so lonesome
since the entire database was mangled.  Imagine it to be infinitely
more lonesome and you get the original description.

Re: Fix to fjbg, do I need to replace starr?

Re: Classes that have names starting from dollars

Re: Classes that have names starting from dollars