bug 2034

On 4/14/11 8:40 AM, Nils Kilden-Pedersen wrote:
> Any chance of getting this fixed anytime soon?
>
> https://lampsvn.epfl.ch/trac/scala/ticket/2034
>
> It's making it impossible to work with certain Java libraries in the REPL.

I believe we need to change the name mangling scheme completely with a
more complete acknowledgement of the limitations imposed by java
reflection. If that sounds like it means it won't be fixed anytime
soon, that is most likely correct. I don't know if we can ever fix it.
What is at stake is reliable interoperability, not just with java but
with all the other jvm languages.

There is actually a pretty simple answer to a lot of our problems with
names and their interaction with reflection and with each other. We
stop acting like $ is the only metacharacter in the universe. Amend the
specification and carve out some obscure corner of UTF-8 like snowmen or
dice, and give ourselves at least a tiny vocabulary of distinct
organizers rather than limiting ourselves to monobit caveman grunts.

Relevant: http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm

Fun with So!

http://www.fileformat.info/info/unicode/category/So/list.htm

U+33FF SQUARE GAL ㏿ view
U+4DC0 HEXAGRAM FOR THE CREATIVE HEAVEN ䷀ view
U+4DC1 HEXAGRAM FOR THE RECEPTIVE EARTH ䷁ view
U+4DC2 HEXAGRAM FOR DIFFICULTY AT THE BEGINNING ䷂ view
U+4DC3 HEXAGRAM FOR YOUTHFUL FOLLY ䷃ view

On Thu, Apr 14, 2011 at 11:01 AM, Paul Phillips <paulp@improving.org> wrote:

On 4/14/11 8:40 AM, Nils Kilden-Pedersen wrote:

Any chance of getting this fixed anytime soon?

https://lampsvn.epfl.ch/trac/scala/ticket/2034

It's making it impossible to work with certain Java libraries in the REPL.

I believe we need to change the name mangling scheme completely with a more complete

The REPL appears to be lying to me, so I'm to fully understand what's going on. Looking at the JDK code, it doesn't appear to be a name mangling issue (but maybe I'm confused because the REPL lies?):

scala> class Foo
defined class Foo

scala> classOf[Foo].getName
res19: java.lang.String = Foo

scala> classOf[Foo].getName.length
res18: Int = 33

scala> classOf[Foo].getEnclosingClass.getName.length
res16: Int = 30

scala> classOf[Foo].getEnclosingClass.getName
res17: java.lang.String =

JDK:
    Class<?> enclosingClass = getEnclosingClass();
    if (enclosingClass == null) // top level class
        return null;
    // Otherwise, strip the enclosing class' name
    try {
        return getName().substring(enclosingClass.getName().length());
    } catch (IndexOutOfBoundsException ex) {
        throw new InternalError("Malformed class name");
    }
 

On 4/14/11 9:58 AM, Nils Kilden-Pedersen wrote:
> The REPL appears to be lying to me, so I'm to fully understand what's
> going on. Looking at the JDK code, it doesn't appear to be a name
> mangling issue (but maybe I'm confused because the REPL lies?):

No, you're confused because you're looking in the wrong place. The
relevant piece of JDK code is:

int length = simpleName.length();
if (length < 1 || simpleName.charAt(0) != '$')
throw new InternalError("Malformed class name");

There is a large comment preceding that code which should make clear
that name mangling is the issue. After stripping the enclosing class
name they insist on '$' being the first character. We are appending '$'
to an object name to name the module class, so the enclosing class takes
the '$' with it. Whatever accommodation is made here, something breaks.

// According to JLS3 "Binary Compatibility" (13.1) the binary
// name of non-package classes (not top level) is the binary
// name of the immediately enclosing class followed by a '$' followed by:
// (for nested and inner classes): the simple name.
// (for local classes): 1 or more digits followed by the simple name.
// (for anonymous classes): 1 or more digits.

// Since getSimpleBinaryName() will strip the binary name of
// the immediatly enclosing class, we are now looking at a
// string that matches the regular expression "\$[0-9]*"
// followed by a simple name (considering the simple of an
// anonymous class to be the empty string).

On Thu, Apr 14, 2011 at 12:22 PM, Paul Phillips <paulp@improving.org> wrote:

There is a large comment preceding that code which should make clear that name mangling is the issue.

Since there are workarounds for this outside of the REPL (i.e. don't declare classes inside objects), maybe we can get some REPL switch that could change name mangling? It already appears to do some name manipulation, hiding the outer name.

Just a thought.

On Thu, Apr 14, 2011 at 12:22 PM, Paul Phillips <paulp@improving.org> wrote:

No, you're confused because you're looking in the wrong place.

Yeah, I overlooked that the exception is thrown several places.

Well, maybe we can get Oracle to change the spec? (j/k)

Bummer, major suckage.

Maybe in the mythical Scala 3.0, where we break everything and start over?

Hi Nils,
>
> Any chance of getting this fixed anytime soon?
> Since there are workarounds for this outside of the REPL (i.e. don't
> declare classes inside objects), maybe we can get some REPL switch
> that could change name mangling? It already appears to do some name
> manipulation, hiding the outer name.
>
> Just a thought.
>
you're not alone :-)

I have related problems for quite some time already
(http://lampsvn.epfl.ch/trac/scala/ticket/4023) ... especially with
weirdnesses related to REPL-non-REPL usage, so I can feel with you.

While some things might get fixed with Scala reflection (if it will ever
arrive...), improving Scala's workarounds for some JVM limitations would
be nice indeed.

Bye,

Simon