2014-09-12 19 views
10

Ich habe viel mit IO in Java getan und nach Code suchen Primitiven zu konvertieren Arrays Byte und Source-Websites für java.io.Bits auf einem der Java-Quellcode-Hosting Ich fand zurück. Nach einem kurzen Blick erkannte ich, dass es genau das ist, was ich brauche, außer dass es Paket-privat ist. Also habe ich eine Kopie gemacht, die ich öffentlich gemacht, in meinem Projektpaket gespeichert und benutzt habe (nur in persönlichen Projekten, versichere ich Ihnen). Ich finde es sehr nützlich.Warum ist java.io.Bits nicht öffentlich?

Meine Frage ist, warum ist dieses Paket-private? Ich kann sehen, dass es wirklich nützlich für Leute ist, die mit IO arbeiten, und ich sehe keinen Nachteil darin, seine Sichtbarkeit für die Öffentlichkeit zu ändern (in rt.jar). Oder gibt es vielleicht eine Entsprechung (und bitte erwähnen Sie keine anderen Bibliotheken)?

Hier ist ein Link zu einer zufällig ausgewählten Website, die Java-Quellcode für java.io.Bits hat: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/Bits.java

Antwort

8

Sie müßten sicher eine der Java-Entwickler fragen, aber es verpacken privat, kann die API behandelt, indem sie seine als "intern" - dh es kann sich jederzeit ändern oder verschwinden. Dies bedeutet, dass die API relativ schnell entwickelt werden kann, und muss nicht durch den gleichen relativ gründlichen Testprozess gehen, die Öffentlichen APIs durchlaufen müssen (da, sobald sie freigegeben sind, sind sie es für gut stecken.)

Kurz gesagt, eine API öffentlich zu machen, hat langfristige Auswirkungen, und es erfordert viel, viel mehr Arbeit als nur einen Schalter zu drücken.

ich ahne, wäre es begann das Leben als „gehackt zusammen“ Gruppe von Funktionen, die für ein paar andere Klassen in dem IO-Paket und hat dort gerade blieb seitdem.

+0

Denkst du, es ist in Ordnung, nur eine persönliche Kopie zu erstellen und sie mit einer Anwendung zu verteilen? – Nulano

+4

@Nulano - ich bin mir ziemlich sicher, dass es nicht ist. obwohl ich denke, das hängt von der lizenz ihrer app ab. moderne jdk ist GPL ich glaube, also wenn Ihre App GPL ist, dann kann es in Ordnung sein. – jtahlborn

+0

Mit Blick auf was im Code, würde ich seinen ziemlich trivialen Code sagen; Gefragt nach solchen Methoden wird jeder kompetente Programmierer mit einer sehr sehr ähnlichen (wenn nicht identischen) Implementierung aufwarten. Obwohl keine richtige Begründung; Ich denke, der Code ist nicht original genug, um Ansprüche wegen Urheberrechtsverletzungen zu rechtfertigen. – Durandal

3

Es ist Paket-privat, sicher, aber es gibt öffentliche APIs, die das gleiche Verhalten aussetzen, z.B. ByteBuffer.wrap(array).getInt(index) und die anderen Methoden auf ByteBuffer. Sie sind mit ziemlicher Sicherheit besser dran, wenn Sie diese ordnungsgemäß gestaltete, gut dokumentierte öffentliche API verwenden, anstatt zu versuchen, interne Implementierungsdetails aus Java zu übernehmen oder zu kopieren.

+0

Ich denke, das ist eine Antwort wert, zu akzeptieren, aber seit ich kann "akzeptieren "Nur eine einzige Antwort, du bekommst nur +1. – Nulano

+0

Ich war unsicher über die Leistung von ByteBuffer vs java.io.Bits haben also einen schnellen Test gemacht. Die Ergebnisse zeigen, dass das Speichern von java.io.Bits das schnellste mit absolutem BB gleich danach ist, und das Lesen von absolutem BB ist das schnellste mit relativ großem Endian und dann kleiner Endian-Folge, Bits am langsamsten. Hier ist ein Pastebin-Link zu detaillierten Ergebnissen und src-Code für meinen Test: http://pastebin.com/XStkmN8s – Nulano

+0

Update: Ich aktualisiert die Pastebin, um Tests auf meinem Ubuntu-Rechner hinzuzufügen. Sie sind viel in der Gunst von java.io.Bits, aber Big Endian absolute ByteBuffer ist dicht dahinter. – Nulano