-
Enhancement
-
Resolution: Duplicate
-
P3
-
None
-
7
-
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.
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.
- duplicates
-
JDK-6955343 specification of JSR 292 language changes
- Closed
- relates to
-
JDK-6863344 javac: Pretty.java should handle exotic identifiers
- Closed
-
JDK-6868490 exotic identifier syntax should not be enabled by default in -source 6 or earlier
- Closed
-
JDK-6868524 javadoc should handle exotic identifiers
- Closed
-
JDK-4266845 3.10.5: Explicitly mention that string literals can't contain \u0022 (") characters
- Closed
-
JDK-6754038 writing libraries in Java for non-Java languages requires support for invokedynamic sites
- Closed
(1 relates to)