Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6746458

writing libraries in Java for non-Java languages requires support for exotic identifiers

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Duplicate
    • Icon: P3 P3
    • None
    • 7
    • specification
    • generic
    • generic

      Public discussion: http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm

      Each language has its own rules for forming identifiers of functions, variables, and types. The JVM allows almost total freedom, at the bytecode level, for forming names of methods, fields, and classes. So far so good. If a language (say, Lisp, Smalltalk, Ruby, or Scala) wants to encode its names directly in the JVM, it runs into two problems. The first is the small number of remaining restrictions on JVM bytecode names; this can easily be overcome by lightweight mangling as outlined in the above blog post.

      The second problem is the fact that the language runtime is probably written largely in Java, which means that the "exotic" names in the language cannot be directly implemented by Java classes, methods, and fields. In practice, this difficulty forces language implementors to mangle their names not for the JVM (which is permissive) but for Java (which is restrictive).

      The solution to the second problem is to provide an "escape" syntax (similar to that of Lisp and other languages) which allows an arbitrary string to pass through the language scanner as a simple identifier token instead of some other token (or an unscannable mess).

      We propose the syntax #"foo". See example implementation here:
        http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/quid.patch

      The javac frontend should accept any quoted string immediately following '#' (with no intervening space), interpreting normal string escape sequences, and taking the resulting string exactly as the spelling of a normal identifier. Keywords like 'int' should not be recognized. Strings which risk being illegal at the JVM level must be rejectedi immediately; this simply means rejecting the empty string and strings which contain any of the characters "/.;<>[".

      This design is neutral toward mangling schemes but supports the one described in the blog entry mentioned above.

            abuckley Alex Buckley
            jrose John Rose
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: