Qualche rischio usando un singolo simbolo di dollaro `$` come nome di una classe java?

Question

Originariamente stavo usando il trattino basso _ come nome di classe. Il nuovo compilatore Java8 si lamenta del fatto che "potrebbe non essere supportato dopo Java SE 8". L'ho modificato in $ e non c'è più alcun avviso. Tuttavia ricordo che $ viene utilizzato da Java per indicare una classe interna/incorporata nel codice byte. Mi chiedo se ci sia qualche rischio di usare il simbolo del dollaro $ come nome di classe

Qualche sfondo a questa domanda. Quello che voglio fare è superare il fatto che Java non supporta la pura funzione, e _ o $ è mettere uno spazio dei nomi per incapsulare un concetto molto generico (classi/metodi statici). e nemmeno io ho un buon nome per questo, né voglio che il tipo di utente lib faccia troppe cose per fare riferimento a quel namespace. Ecco il codice che mostra cosa sto facendo in questo modo: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java

Answer 1

È uno stile dannoso e potenzialmente rischioso per utilizzare $ in qualsiasi identificativo in Java. La ragione per cui è rischioso è che il carattere $ è riservato all'uso della toolchain Java e degli strumenti di lingua di terze parti.

• E 'utilizzato da compilatori Java in nomi di classe "interni" per le classi interne e nidificate.
• Viene utilizzato dai compilatori Java nei nomi degli attributi sintetici.
• Potrebbe essere utilizzato da generatori di codice di terze parti (ad es.processori di annotazione) per vari scopi.
• Potrebbe essere utilizzato da altre lingue che hanno come target la piattaforma JVM e che potrebbe dover coesistere con il codice.

Probabilmente non avrete problemi tecnici con un semplice nome di classe $ al momento (almeno rispetto alla toolchain Java standard). Ma c'è sempre la possibilità che questo cambierà in futuro:

• Hanno riservato il diritto di cambiare questo.
• Esiste un precedente per fare questo nell'esempio _.

---

Se davvero, davvero bisogno di un nome di classe di un carattere, sarebbe meglio andare sul sicuro e usare F o Z o qualcos'altro che non è riservata.

Ma per essere onesti, penso che staresti meglio cercando di implementare (o semplicemente usare) un vero linguaggio funzionale piuttosto che provare a suonare un "sistema" di programmazione funzionale in Java. O forse, passa a Java 8 in anticipo rispetto alla sua versione ufficiale. 'Per quanto mi riguarda, rifiuta di leggere/gestire una base di codice Java simile a jQuery.

---

non intendo creare un lib funzionale per Java, vogliono solo creare un lib per mantenere alcuni servizi comuni che ho usato. Ancora una volta, sono un sostenitore del minimalismo e sento di succhiare cose come Apache Commons. Le cose funzionali sono state aggiunte per aiutarmi a manipolare più facilmente le raccolte.

Se è il tuo codice, puoi fare quello che ti piace. Prendi le tue decisioni. Agisci sulle tue opinioni. Sii un "risk taker" ... :-). (Il nostro consiglio su $, eccetera ... è discutibile.)

Ma se si sta scrivendo il codice per un cliente o datore di lavoro, o con l'intenzione di creare una (valida) prodotto open source, quindi è necessario prendere conto dell'opinione di altre persone. Ad esempio, il tuo capo ha bisogno di avere un'opinione informata su quanto sarà mantenibile il tuo codice se trovi un lavoro meglio retribuito da qualche altra parte. In generale, il prossimo sarà in grado di capirlo, manterrà il tuo codice, fresco, ecc ... o sarà consegnato alla pattumiera?

Answer 2

Huh, hai ragione, utilizzando un nome di classe funziona con uno $. Eclipse si lamenta che è contro la convenzione, ma, se sei sicuro, puoi farlo.

Il problema (convenzionalmente) con l'utilizzo di un $ è che il $ viene utilizzato nella gerarchia delle classi per indicare le classi annidate .... per esempio, il file contenente A.java:

class A { 
    class SubA { 
    } 
} 

otterrebbe compilato per due file:

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

Ed è per questo, anche se $ funziona, è mal consigliato, perché l'analisi dei vasi può essere più difficile ... e si corre il rischio di collisione due classi e causando altri problemi

EDIT, ho appena fatto un test con i seguenti due file Java (nel pacchetto di default)

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

E il codice non viene compilato .....

due problemi, tipo a $ SubA è già definita, e ca non fa riferimento a una classe nidificata A $ SubA dal suo nome binario.

Answer 3

Sì, per essere pedante nel rispondere alla tua domanda c'è un rischio. Come hanno già detto altre persone, viola le convenzioni sui nomi java. Quindi il rischio è che con le versioni future del JDK ciò possa causare problemi. Ma oltre a questo, e alcuni problemi se si tenta di utilizzare classi nidificate si dovrebbe andare bene.

Answer 4

Si rischia di prendere a calci un culo se qualcun altro ha mai bisogno di leggere o mantenere il proprio codice.

Answer 5

penso che si sta cercando di evitare nomi brutti come Util.andThen. Prendi in considerazione l'utilizzo di static imports. Ciò ti consente di importare tutti i metodi nell'intestazione import static org.ogsl.Util.*, quindi puoi semplicemente utilizzare l'utente andThen senza alcun prefisso.