Jedes Risiko mit einem Dollarzeichen `$` als Java-Klassenname?

Question

Ursprünglich verwendete ich den Unterstrich _ als Klassennamen. Der neue Java8-Compiler beklagt, dass "nach Java SE 8 möglicherweise nicht unterstützt wird". Ich änderte das zu $, und es gibt keine Warnung mehr. Ich erinnere mich jedoch, dass $ von Java verwendet wird, um eine innere/eingebettete Klasse im Bytecode anzugeben. Ich frage mich, ob es ein Risiko gibt, ein Dollarzeichen $ als Klassenname zu verwenden

Einige Hintergrundinformationen zu dieser Frage. Was ich tun möchte, ist die Tatsache zu überwinden, dass Java keine reine Funktion unterstützt, und das _ oder $ soll einen Namespace setzen, um ein sehr allgemeines Konzept (Klassen/statische Methoden) einzukapseln. und ich habe weder einen guten Namen dafür, noch möchte ich, dass der Lib-Benutzertyp zu viele Dinge enthält, um auf diesen Namespace zu verweisen. Hier ist der Code, der zeigt, was ich auf dem Weg mache: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java

Answer 1

Es ist schlechter Stil, und potenziell riskante $ in jedem Identifikator in Java zu verwenden. Der Grund, warum es riskant ist, ist, dass das Zeichen $ für die Verwendung der Java-Toolchain und Fremdsprachenwerkzeuge reserviert ist.

Es wird von Java-Compilern in "internen" Klassennamen für innere und verschachtelte Klassen verwendet.

Es wird von Java-Compilern in den Namen von synthetischen Attributen verwendet.

Es könnte von Drittanbieter-Code-Generatoren (z.Annotationsprozessoren) für verschiedene Zwecke.

Es könnte von anderen Sprachen verwendet werden, die auf die JVM-Plattform abzielen und die möglicherweise mit Ihrem Code koexistieren müssen.

Sie werden wahrscheinlich keine technischen Probleme mit einem Klassennamen $ haben (zumindest in Bezug auf die Standard-Java-Toolchain). Aber es gibt immer die Möglichkeit, dass dies in Zukunft ändern wird:

• Sie haben das Recht vorbehalten dies zu ändern.
• Es gibt einen Präzedenzfall dafür im _ Beispiel.

---

Wenn Sie wirklich, wirklich ein Zeichen Klassennamen benötigen, wäre es besser, es sicher zu spielen und nutzen F oder Z oder etwas anderes, das nicht reserviert ist.

Aber um ehrlich zu sein, denke ich, dass es besser wäre, eine echte funktionale Sprache zu implementieren (oder einfach zu verwenden), als ein funktionierendes Programmier- "System" in Java zu schuhen. Oder vielleicht, wechseln Sie einfach zu Java 8 vor seiner offiziellen Veröffentlichung. Denn ich würde verweigern, um eine Java-Codebase zu lesen/zu pflegen, die wie jQuery aussah.

---

meine ich nicht eine funktionelle lib für Java zu erstellen, wollen nur ein lib erstellen einige gemeinsame Dienstprogramme zu halten I verwendet. Wiederum bin ich ein Verfechter des Minimalismus und fühle mich mit Dingen wie Apache Commons angewidert. Das funktionale Zeug wird hinzugefügt, um mir zu helfen, Sammlung (en) leichter zu manipulieren.

Wenn es Ihr Code ist, können Sie tun, was Sie wollen. Treffen Sie Ihre eigenen Entscheidungen. Handeln Sie auf Ihre Meinung. Sei ein "Risk Taker" ... :-). (Unser Rat an $, usw. ... ist strittig.)

Aber wenn Sie diesen Code für einen Kunden oder einen Arbeitgeber schreiben, oder mit der Absicht, ein (lebensfähiges) Open-Source-Produkt zu erstellen, dann müssen Sie nehmen Berücksichtigung der Meinung anderer Leute. Zum Beispiel braucht Ihr Chef eine fundierte Meinung darüber, wie wartbar Ihr Code sein wird, wenn Sie irgendwo anderswo einen besser bezahlten Job finden. Ist der nächste Typ in der Lage, es herauszufinden, deinen Code zu behalten, frisch usw.? Oder wird er in den Mülleimer geschickt?

Answer 2

Huh, du hast recht, mit einem $ in einem Klassennamen funktioniert. Eclipse beklagt, dass es gegen Konvention ist, aber wenn Sie sicher sind, können Sie es tun.

Das Problem (konventionell) mit Verwendung eines $ ist, dass die $ in der Klassenhierarchie verwendet verschachtelte Klassen, um anzuzeigen, .... zum Beispiel die Datei A.java enthält:

class A { 
    class SubA { 
    } 
} 

bekommen würde kompiliert zwei Dateien:

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

Weswegen, obwohl $ Werke, es krank, weil geraten, die Gläser Parsen schwieriger sein kann ... und Sie laufen Gefahr, zwei Klassen von kollidiert und verursacht andere Probleme

EDIT, habe ich gerade getan einen Test mit den folgenden zwei Java-Dateien (im Standard-Paket)

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()); 
    } 
} 

Und der Code nicht kompilieren .....

zwei Probleme, Typ A $ SubA ist bereits definiert, und ca referenziere eine verschachtelte Klasse A $ SubA nicht nach ihrem binären Namen.

Answer 3

Ja, sein pedantisch über Ihre Frage zu beantworten ein Risiko besteht. Wie einige andere Leute erwähnt haben, verstößt es gegen Java-Namenskonventionen. Das Risiko besteht also darin, dass dies bei zukünftigen Versionen des JDK zu Problemen führen kann. Aber darüber hinaus und einige Probleme, wenn Sie versuchen, verschachtelte Klassen zu verwenden, sollten Sie in Ordnung sein.

Answer 4

Sie riskieren einen Arschschlag, wenn jemand Ihren Code lesen oder pflegen muss.

Answer 5

Ich denke, Sie versuchen, hässliche Namen wie Util.andThen zu vermeiden. Erwägen Sie die Verwendung von static imports. Damit können Sie alle Methoden in der Kopfzeile import static org.ogsl.Util.* importieren, so dass Sie einfach andThen ohne Präfix verwenden können.