Dlaczego java.io.Bits nie jest publiczny?

Zrobiłem dużo z IO w Javie i po szukaniu kodu do konwersji prymitywów na tablice bajtowe iz powrotem znalazłem źródło dla java.io.Bits na jednej ze stron hostujących kod źródłowy Java. Po szybkim spojrzeniu zdałem sobie sprawę, że to dokładnie to, czego potrzebuję, z wyjątkiem tego, że jest to pakiet prywatny. Więc zrobiłem kopię, którą upubliczniłem, przechowywaną w pakiecie mojego projektu i używam (tylko w osobistych projektach, zapewniam cię). Uważam to za bardzo przydatne.Dlaczego java.io.Bits nie jest publiczny?

Moje pytanie brzmi: dlaczego ten pakiet jest prywatny? Widzę, że jest to naprawdę przydatne dla osób, które pracują z IO i nie widzę żadnej niedogodności od zmiany jego widoczności na publiczną (w rt.jar). Czy może istnieje odpowiednik (i proszę nie wspominać o innych bibliotekach)?

Oto link do losowo wybranej stronie, która ma źródło Java dla java.io.Bits: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/Bits.java

Źródło

2014-09-12 Nulano

Trzeba by zapytać jednego z deweloperów Java na pewno, ale co zapakować prywatne, API może być traktowany jako "wewnętrzny" - tzn. może się zmienić lub zniknąć w dowolnym momencie. Oznacza to, że interfejs API może zostać opracowany stosunkowo szybko i nie musi przechodzić przez ten sam stosunkowo dokładny proces testowania, przez który muszą przejść publiczne interfejsy API (ponieważ po ich wypuszczeniu na stałe utknęły w tym miejscu.)

Podsumowując, publiczne udostępnianie interfejsu API ma długoterminowe konsekwencje i wymaga znacznie więcej pracy niż tylko przełączenia.

Zaryzykowałbym przypuszczenie, że zaczęło to życie jako grupa "zhakowana ze sobą", przydatna dla kilku innych klas w pakiecie IO, i od tamtej pory została.

Źródło

2014-09-12 17:56:14 berry120

Czy uważasz, że wystarczy zrobić kopię osobistą i rozprowadzić ją za pomocą aplikacji? – Nulano

@Nulano - jestem prawie pewien, że tak nie jest. chociaż myślę, że to zależy od licencji twojej aplikacji. nowoczesny jdk jest zgodny z GPL, więc jeśli Twoja aplikacja jest na licencji GPL, może być w porządku. – jtahlborn

Patrząc na to, co znajduje się w kodzie, powiedziałbym, że jest to bardzo trywialny kod; Zapytany o takie metody, każdy kompetentny programista przedstawi bardzo bardzo podobne (jeśli nie identyczne) wdrożenie. Chociaż nie jest to właściwe uzasadnienie; Domyślam się, że kod nie jest wystarczająco oryginalny, aby uzasadnić roszczenia dotyczące naruszenia praw autorskich. – Durandal

Jest to pakiet prywatny, oczywiście, ale istnieją publiczne interfejsy API, które ujawniają takie samo zachowanie, np. ByteBuffer.wrap(array).getInt(index) i inne metody na ByteBuffer. Prawie na pewno lepiej wykorzystać ten właściwie zaprojektowany, dobrze udokumentowany publiczny interfejs API, niż próbować zawijać lub kopiować wewnętrzne szczegóły implementacji z Java.

Źródło

2014-09-12 18:16:51

Uważam, że jest to odpowiedź warta zaakceptowania, ale ponieważ mogę "zaakceptować "tylko jedna odpowiedź, dostajesz tylko +1. – Nulano

Nie byłem pewien co do wydajności ByteBuffer vs java.io.Bity przetestowały więc szybki test. Wyniki pokazują, że do przechowywania java.io.Bits jest najszybszy z absolutnym BB zaraz po, a dla odczytu absolutny BB jest najszybszy z relatywnie dużym endianem, a następnie małym endianem, Bity są najwolniejsze. Oto link do pastebin do szczegółowych wyników i kod src do mojego testu: http://pastebin.com/XStkmN8s – Nulano

Aktualizacja: Zaktualizowałem pastebin, aby dodać testy na moim komputerze Ubuntu. Są bardzo przychylni java.io.Bits, ale duży endian BajtBuffer absolutny jest tuż za nim. – Nulano

Dlaczego java.io.Bits nie jest publiczny?

Odpowiedz

Powiązane problemy