2016-03-25 18 views
6

Wywołana przez ten raport o błędzie AVRO-1814 Zredukowuję problem do tego minimalnego przykładowego przypadku w Javie, który po prostu pokazuje rdzeń efektu.Kolizja nazw Java między zmienną i najwyższą nazwą pakietu

package nl.basjes.experiment; 

public class NamingClash { 
    String nl = "foo"; 

    public void test() { 
    nl.basjes.experiment.NamingClash.foo(); 
    } 

    private static void foo() { 
    // Do something 
    } 
} 

Próbując skompilować to daje

error: cannot find symbol 
    nl.basjes.experiment.NamingClash.foo(); 
    ^
    symbol: variable basjes 
    location: variable nl of type String 

W AVRO kod jest generowany i należy go unikać kolizji nazw pod ludzi przyjmowanych założeń czasami wybrać niespodziewanych nazwisk.

więc założyć, że w tym przykładzie

  1. W pełni kwalifikowana nazwa klasy w „test()” jest potrzebna metoda, aby uniknąć kolizji.
  2. Zmienna "nl" jest po prostu nazwą używaną w definicji schematu.
  3. Generowanie pola, takiego jak _nl__, i pobieranie i ustawianie byłoby zmianą, która przełamie kompatybilność wsteczną, ponieważ pole nl zawsze było publiczne.

Inne niż mówienie ludziom "Po prostu tego nie rób".

Czy istnieje sposób na uniknięcie tych konfliktów?


Uwaga: w przypadku błędu AVRO, który wywołał to pytanie, znalazłem obejście tego problemu. Tutaj szukam "ogólnej odpowiedzi".

+2

http://stackoverflow.com/questions/19406673/how-to-fully-qualify-a-class-whose-package-name-collides-with-a-local-member-nam –

Odpowiedz

1

Widzę dwa rozwiązania tego problemu:

1) wywołać metodę z użyciem nazwy metody kwalifikacje tylko przez tylko aktualną nazwą klasy, zamiast pełnej nazwy:

public void option1() { 
    NamingClash.foo(); 
} 

2) wywołaj metodę statyczną za pomocą wskaźnika bieżącego obiektu klasy this i wyłącz ostrzeżenie "dostęp statyczny".

@SuppressWarnings("static-access") 
public void option2() { 
    this.foo(); 
} 
Powiązane problemy