Any risk using a single dollar sign `$` as a java class name?

Question

Originally I was using the underscore _ as a class name. The new Java8 compiler complains that it "might not be supported after Java SE 8". I changed that to $, and there is no warning any more. However I remember that $ is used by Java to indicate an inner/embedded class in the byte code. I am wondering if there is any risk to use a dollar sign $ as a class name

Some background to this question. What I want to do is to overcome the fact that Java doesn't support pure function, and the _ or $ is to put an namespace to encapsulate some very generic concept (classes/static methods). and neither do I have a good name for this, nor do I want the lib user type too many things to reference that namespace. Here is the code showing what I am doing under the way: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java

Answer 1

It is bad style, and potentially risky to use $ in any identifier in Java. The reason it is risky is that the $ character is reserved for the use of the Java toolchain and third-party language tools.

• It is used by Java compilers in "internal" class names for inner and nested classes.
• It is used by Java compilers in the names of synthetic attributes.
• It could be used by third-party code generators (e.g. annotation processors) for various purposes.
• It could be used by other languages that target the JVM platform, and that might need to co-exist with your code.

You probably won't have technical issues with a plain $ classname at the moment (at least with respect to the standard Java toolchain). But there's always the possibility that this will change in the future:

• They have (effectively) reserved the right to change this¹.
• There is a precedent for doing this in the _ example.

---

If you really, really need a one-character classname, it would be better to play it safe and use F or Z or something else that isn't reserved.

But to be honest, I think you'd be better off trying to implement (or just use) a real functional language than trying to shoe-horn a functional programming "system" into Java. Or maybe, just switch to Java 8 ahead of its official release. 'Cos I for one would refuse to read / maintain a Java codebase that looked like jquery.

---

I don't mean to create a functional lib for Java, just want to create a lib to maintain some common utilities I used. Again, I am a advocate of minimalism and feel suck with things like apache commons. The functional stuff is added to help me easier to manipulate collection(s).

If it is your code, you can do what you like. Make your own decisions. Act on your opinions. Be a "risk taker" ... :-). (Our advice on $, etcetera ... is moot.)

But if you are writing this code for a client or employer, or with the intention of creating a (viable) open source product, then you need to take account of other people's opinion. For example, your boss needs to have an informed opinion on how maintainable your code will be if you find a better paying job somewhere else. In general, will the next guy be able to figure it out, keep your code, fresh, etc ... or will it be consigned to the dustbin?

---

^{1 - JLS §3.8 states "The $ character should be used only in mechanically generated source code". That is saying "use it at your peril". The assumption is that folks who build their own source code generators can change them if the standard toolchain uses a bare $ ... but it is harder to change lots of hand written code, and that would be an impediment to upgrading.}

Answer 2

Huh, you're right, using a $ in a classname works. Eclipse complains that it is against convention, but, if you are sure, you can do it.

The problem (conventionally) with using a $ is that the $ is used in the class hierarchy to indicate nested classes.... for example, the file A.java containing:

class A {
   class SubA {
   }
}

would get compiled to two files:

1. A.class
2. A$SubA.class

Which is why, even though $ works, it is ill advised because parsing the jars may be more difficult... and you run the risk of colliding two classes and causing other issues

EDIT, I have just done a test with the following two Java files (in the default package)

public class A {
    private static final class SubA {
        public String toString() {
            return "I am initializing Nested SUBA";
        }
    }

    private static final SubA sub = new SubA();
    public A() {
        System.out.println("What is " + sub.toString());
    }
}



public class A$SubA {
    @Override
    public String toString() {
        return "I am A$SubA";
    }
}


public class MyMain {
    public static void main(String[] args) {
        System.out.println(new A());
        System.out.println(new A$SubA());
    }
}

And the code will not compile.....

Two problems, type A$SubA is already defined, and can't reference a nested class A$SubA by it's binary name.

Answer 3

Yes, to be pedantic about answering your question there is a risk. As some other folks have mentioned, it violates java naming conventions. So the risk is that with future versions of the JDK this may cause problems. But beyond that, and some issues if you try to use nested classes you should be fine.

Answer 4

I think you're trying to avoid ugly names like Util.andThen. Consider using static imports. That lets you import all the methods in the header import static org.ogsl.Util.*, so then you can simply use you andThen without any prefix at all.

Answer 5

The Selenide project does it. Just look at the top of this documentation: https://selenide.org/documentation.html

Maybe it is a more acceptable thing to do only in test code.

API ref: https://selenide.org/javadoc/current/com/codeborne/selenide/Selenide.html