To jest polecenie japicompat, które można uruchomić w darmowym dostawcy usług hostingowych OnWorks przy użyciu jednej z wielu naszych bezpłatnych stacji roboczych online, takich jak Ubuntu Online, Fedora Online, emulator online systemu Windows lub emulator online MAC OS
PROGRAM:
IMIĘ
japicompat — Testuj interfejsy API języka Java pod kątem wstecznej kompatybilności binarnej.
STRESZCZENIE
japikopat [-svqhtjw4] [-lub plik wyjściowy] [-ja ignoruj pliki]
OPIS
japikopat jest częścią japitools, zaprojektowaną do testowania zgodności między interfejsami API Java.
Zostały pierwotnie zaprojektowane do testowania darmowych implementacji samej Javy
zgodności z pakietem JDK firmy Sun, ale można ich również używać do testowania kompatybilności wstecznej
między wersjami dowolnego API.
Narzędziami są japize i japicompat. Japize to program Java, który emituje listę plików
API w formacie do odczytu maszynowego. Następnie Japicompat bierze dwie takie listy i porównuje
je pod kątem kompatybilności binarnej, zgodnie z definicją firmy Sun w Specyfikacji języka Java.
OPCJE
-s wyłącz dodatkowe kontrole zgodności binarnej (wykonuj tylko kontrole zdefiniowane przez JLS).
-v włączyć sprawdzanie drobnych problemów ze zgodnością.
Sprawdzanie SerialVersionUID: japicompat zgłasza drobny błąd, jeśli klasa Serializable
ma inny SerialVersionUID między dwoma wydaniami.
Sprawdzanie wycofania: japicompat zgłasza drobny błąd, jeśli klasa lub członek był
przestarzałe w oryginalnym interfejsie API, ale nie jest przestarzałe w sprawdzanym interfejsie API.
-q wyłącza raporty o postępach.
-h generuje dane wyjściowe w formacie HTML. Tworzone pliki HTML zależą od pliku japi.css
plik, aby uzyskać atrakcyjną prezentację.
-t generuje dane wyjściowe w formacie tekstowym. To jest ustawienie domyślne.
-j generuje dane wyjściowe w surowej formie czytelnej dla komputera. Wytworzony format to tzw
„japio” i zgodnie z konwencją powinny być zapisywane z rozszerzeniem „.japio”.
Do konwersji tego formatu można użyć samodzielnych narzędzi japiotext i japiohtml
na html lub tekst (właściwie japicompat wywołuje wewnętrznie japiotext lub japiohtml if
używane są flagi -h lub -t). Pliki Japio mogą być również używane z flagą -i do
wsparcie ignorowania błędów spowodowanych niezgodnościami między wersjami JDK.
-w wyłącz ostrzeżenia dotyczące uruchamiania starych, wadliwych plików japi. Domyślnie japicompat
wygeneruje ostrzeżenia, jeśli zostanie uruchomione na plikach japi oryginalnie wygenerowanych przez starsze wersje
wersje japitools, które miały znane błędy, których japifix nie może wyeliminować.
-4 użyj trybu zgodnego z wersją 1.4. Działa to tak długo, jak interfejsy API do porównania nie zawierają
1.5-tylko przedmioty.
-o
Wyślij dane wyjściowe do zamiast standardowego wyjścia. Format tego pliku zależy od
flagi -h, -t i -j.
-i
Załóżmy, że próbujesz zaimplementować interfejs Java API. masz (prawie)
zakończono obsługę wczesnych wersji JDK (1.0 i 1.1), ale nadal jest ich trochę
odległość, aby osiągnąć pełne pokrycie 1.4 (jest to dokładny opis wszystkich
implementacje oprogramowania Java w wolnym oprogramowaniu w momencie pisania). Używanie japicompat do
porównanie twojej implementacji z JDK 1.4 daje dokładne wyniki, ale możesz też
chcesz pokazać swoje relacje z wcześniejszych wersji.
Niestety Sun nie przestrzegał własnych zasad kompatybilności binarnej między JDK
wydaniach, nie mówiąc już o rozszerzonych regułach, dla których testuje japicompat. Więc kiedy uruchamiasz
porównanie między JDK 1.1 a twoją implementacją, otrzymasz fałszywy błąd
raporty, kiedy jesteś kompatybilny z 1.4, ale nie 1.1.
Oczywiście tak naprawdę chcesz zignorować takie błędy i japicompat
zapewnia sposób, aby to zrobić. Najpierw uruchom porównanie między 1.1 a 1.4, używając opcji -j
przełącznik. Następnie uruchom porównanie między 1.1 a twoją implementacją, przekazując
Opcja „-i” z wynikiem poprzedniego uruchomienia. Na przykład:
$ japicompat -jo ignoruj-11-14.japio jdk11.japi.gz jdk14.japi.gz
$ japicompat -ho jdk11-myimpl.html -i ignoruję-11-14.japio jdk11.japi.gz
myimpl.japi.gz
Możesz również uzyskać ten sam efekt, uruchamiając:
$ japicompat -ho jdk11-myimpl.html -i jdk14.japi.gz jdk11.japi.gz mojaimpl.japi.gz
Jest to oczywiście prostsze i szybsze do wpisania, ale wymaga porównania między
jdk11 i jdk14 do uruchamiania za każdym razem. Ręczne utworzenie pliku japio pozwala
aby został zapisany i użyty ponownie następnym razem, co pozwala japicompat biegać
dwa razy szybciej.
Pliki japi odpowiadające interfejsom API do porównania.
japicompat w szczególności sprawdza, czy drugi argument jest wstecznie kompatybilny
z pierwszym. Dlatego idealna implementacja JDK 1.1 nie przyniosłaby
błędy niezależnie od kolejności argumentów, ale doskonała implementacja
JDK1.1 plus części JDK1.2 należy przetestować w następujący sposób:
$ japicompat jdk11.japi.gz myimpl.japi.gz
$ japicompat myimpl.japi.gz jdk12.japi.gz
Prawdopodobnie niemożliwe jest stworzenie implementacji, która przejdzie oba te testy,
ponieważ własny JDK1.2 firmy Sun generuje liczne błędy podczas testowania z JDK1.1. Zobacz
omówienie powyższej opcji -i, aby dowiedzieć się, jak poradzić sobie z tą sytuacją.
Można przekazywać pliki skompresowane (.japi.gz) lub nieskompresowane (.japi).
japicompat: Rozszerzenie pliku służy do określenia, czy dane wejściowe mają być przesyłane potokiem
przez gzip czy nie.
Korzystaj z japicompat online, korzystając z usług onworks.net