61

I'm aware that Java-the-compilable-programming-language is not one and the same as Java-the-bytecode-format-for-JVM-execution. There are examples of things that are valid in the .class format but not in the .java source code, such as constructor-less classes and synthetic methods.

  1. If we hand-craft a .class file with a reserved Java language keyword (e.g. int, while) as the class, method, or field name, will the Java virtual machine accept it for loading?

  2. If the class is loaded, does it imply that the only way to access this class or member is through Java reflection, because the name is syntactically illegal in the Java programming language?

Nayuki
  • 17,911
  • 6
  • 53
  • 80
  • For #2, yes, since you couldn't use a Java keyword in an illegal way. I don't see why #1 wouldn't be possible since keywords are a construct of the language only. – Dave Newton May 27 '15 at 19:12
  • 1
    A side note (also mentioned in one answer): Some obfuscators exploit the fact that this is possible. They replace method/class/variable names in .class files with keywords like `do`, `while` etc. to make it harder to decompile the code. (One can still decompile it, but the resulting code is basically useless) – Marco13 May 28 '15 at 10:15
  • 1
    @Marco13: but it’s only a measure to prevent naive attacks. It’s easy to fix by renaming the identifiers again, this time creating legal names, before decompiling. Ironically, the obfuscators itself may be used to do this as they provide a renaming operation which is usually configurable, thus can be told to generate legal names. – Holger May 28 '15 at 10:34

4 Answers4

37

Yes, you can use reserved words. The words are only for the compiler. They do not appear in the generated byte code.

An example of using reserved Java words is in the JVM-based Scala language. Scala has different constructs and syntax than Java, but compiles to Java byte code, for running on a JVM.

This is legal Scala:

class `class`

This defines a class named class with a no-arg constructor. Running javap (a disassembler) on the compiled class.class file shows

public class class {
    public class();
}

Scala can do the same with any other Java reserved word.

class int
class `while`
class goto

They can also be used for method or field names.

As you suspected, you would not be able to use these classes from Java, except for reflection. You could use these from a similarly "customized" class file, e.g. from a class file generated by the Scala compiler.

In summary, this is a limitation of javac (the compiler), not java (the VM/runtime environment).

Paul Draper
  • 78,542
  • 46
  • 206
  • 285
  • `javap` is not a compiler, – Tobias May 27 '15 at 19:16
  • 3
    Let's stick with disassembler ;) – Tobias May 27 '15 at 19:18
  • 2
    Very nice, I didn't know that Scala natively lets you abuse Java reserved keywords as names =) – Nayuki May 27 '15 at 19:22
  • I'd call javap a disassembler because it only outputs bytecode mnemonics. I've played with real decompilers (such as DJ) that take class files and generate Java source code. – Nayuki May 27 '15 at 19:27
  • 1
    @NayukiMinase, the difference between the two is whether it produces source code (decompiler), or just a readable representation (disassembler). javap produces only signatures -- as source code -- and omits implementation, unlike other decompilers (e.g. DJ) and disassemblers (e.g. IDA), so it's hard to say. It appears disassembly is the more common word choice, so I'll change it. – Paul Draper May 27 '15 at 19:35
  • 1
    Officially, it is a disassembler. If you use the `-c` flag, it will actually disassemble instead of just displaying the structure. – Tobias May 27 '15 at 19:36
  • 2
    Technically, it's a limitation of the Java language, not javac. Any compliant Java compiler will enforce the same restrictions. – Antimony May 28 '15 at 04:15
29

The only restrictions on class names at the bytecode level are that they can't contain the characters [, . or ; and that they're at most 65535 bytes long. Among other things, this means that you can freely use reserved words, whitespace, special characters, Unicode, or even weird stuff like newlines.

You can theoretically even use null characters in a class name, but since it's impossible to have a null character in the filename, you can't include such a classfile in a jar. You might be able to create and load one dynamically though.

Here's an example of some of the things that you can do (written in Krakatau assembly):

; Entry point for the jar
.class Main
.super java/lang/Object

.method public static main : ([Ljava/lang/String;)V
    .limit stack 10
    .limit locals 10
    invokestatic int                                hello ()V
    invokestatic "-42"                              hello ()V
    invokestatic ""                                 hello ()V
    invokestatic "  some  whitespace and \t tabs"   hello ()V
    invokestatic "new\nline"                        hello ()V
    invokestatic 'name with "Quotes" in it'         hello ()V
    return
.end method
.end class


.class int
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from int"
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

.class "-42"
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from -42"
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

; Even the empty string can be a class name!
.class ""
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from "
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

.class "  some  whitespace and \t tabs"
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from   some  whitespace and \t tabs"
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

.class "new\nline"
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from new\nline"
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

.class 'name with "Quotes" in it'
.super java/lang/Object
.method public static hello : ()V
    .limit stack 2
    .limit locals 0
    getstatic java/lang/System out Ljava/io/PrintStream;
    ldc "Hello from name with \"Quotes\" in it"
    invokevirtual java/io/PrintStream println (Ljava/lang/Object;)V
    return
.end method
.end class

Execution output:

Hello from int
Hello from -42
Hello from
Hello from   some  whitespace and        tabs
Hello from new
line
Hello from name with "Quotes" in it

See Holger's answer for the exact quote of the rules from the JVM specification.

Community
  • 1
  • 1
Antimony
  • 37,781
  • 10
  • 100
  • 107
  • 3
    Interesting indeed! What syntax are you using for your code? Is it something that can be compiled into .class files with an existing tool? – Nayuki May 28 '15 at 04:39
  • Other than fact that the "JVM spec says so", why are there any restrictions on the characters in an identifier name? And why *those* 3 characters? The names don't play any role in interpretation or compilation of the code AFAIK. [Who says you can't have a null in a filename? I didn't think Unix or NTFS cared if you dive deep enough. Granted, hard to type from a keyboard.] – Ira Baxter May 28 '15 at 06:02
  • 1
    @Ira, you'll find that Unix does care about null. – Paul Draper May 28 '15 at 06:27
  • @PaulDraper: Ah. C string contamination. OK. – Ira Baxter May 28 '15 at 06:34
  • 1
    @Ira Baxter: the JVM spec doesn’t care about file systems. It always assumes that there can be alternative storage forms or name mangling schemes to solve the problem of unsupported characters. Keep in mind that when Java was invented, Unicode support in file systems wasn’t standard. Still, Unicode support in Java names was in there from the beginning. I [made an answer](http://stackoverflow.com/a/30502309/2711488) explaining why these characters aren’t allowed. – Holger May 28 '15 at 09:24
  • 1
    @Nayuki I was using the Krakatau assembly syntax. You can assemble it into classfiles using Krakatau (https://github.com/Storyyeller/Krakatau). It's based on the syntax of Jasmin but with more features. – Antimony May 28 '15 at 15:30
18

The restrictions about names are fixed in the JVM specification:

§4.2.1. Binary Class and Interface Names

Class and interface names that appear in class file structures are always represented in a fully qualified form known as binary names (JLS §13.1). Such names are always represented as CONSTANT_Utf8_info structures (§4.4.7) and thus may be drawn, where not further constrained, from the entire Unicode codespace…

For historical reasons, the syntax of binary names that appear in class file structures differs from the syntax of binary names documented in JLS §13.1. In this internal form, the ASCII periods (.) that normally separate the identifiers which make up the binary name are replaced by ASCII forward slashes (/). The identifiers themselves must be unqualified names (§4.2.2).  

§4.2.2. Unqualified Names

Names of methods, fields, local variables, and formal parameters are stored as unqualified names. An unqualified name must contain at least one Unicode code point and must not contain any of the ASCII characters . ; [ / (that is, period or semicolon or left square bracket or forward slash).

Method names are further constrained so that, with the exception of the special method names <init> and <clinit> (§2.9), they must not contain the ASCII characters < or > (that is, left angle bracket or right angle bracket).

So the answer is, there are only a few characters you can’t use on the binary level. First, / is the package separator. Then, ; and [ can’t be used because the have special meaning in field signatures and method signatures which may contain type names. In these signatures, [ starts an array type and ; marks the end of a reference type name.

There is no clear reason why . is forbidden. It isn’t used within the JVM and only has a meaning within generic signatures but if you are using generic signatures, the type names are further restricted by not being allowed to contain <, >, : as well as these characters have a special meaning within generic signatures too.

Consequently, violating the specification by using . within identifiers has no impact on the primary function of the JVM. There are obfuscators doing so. The resulting code works but you may encounter problems with Reflection when asking for Generic type signatures. Also, converting binary names to source name by replacing all /s with .s will become irreversible if the binary name contains .s.

It might be interesting that there was a proposal to support all possible identifiers within Java syntax (see point 3, “exotic identifiers”), but it didn’t make it into the final Java 7. And it seems, no-one is currently making a new attempt to bring it in.

There is the additional technical limitation that the names can’t have a Modified UTF-8 representation being longer than 65535 bytes because the number of bytes is stored as unsigned short value.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • This is a fantastic answer supported by technical evidence. I especially like how you addressed why each reserved character is special, and what happens with the period being in limbo. Thank you. – Nayuki May 28 '15 at 16:12
10
  1. Keywords are known only to the compiler. The compiler translates them into adequate bytecode. So they don't exist during runtime of compiled bytecode and, consequently, are not verified by the JVM.
  2. Surely, you can't access the class members that are not known at compile time. But you can use reflection for that purpose if you are sure that such class member will exist in the compiled code (you will "hand-craft" them there), because access by reflection is not verified by the compiler.
Forketyfork
  • 7,416
  • 1
  • 26
  • 33