10

I've done a lot with IO in Java and after looking for code to convert primitives to byte arrays and back I found source for java.io.Bits on one of the Java source code hosting websites. After a quick glance I realized it's exactly what I need, except it's package-private. So I made a copy which I made public, stored in my project's package and used (only in personal projects, I assure you). I find it very useful.

My question is, why is this package-private? I can see it being really useful for people who work with IO and I see no disadvantage from changing it's visibility to public (in rt.jar). Or is there perhaps an equivalent (and please don't mention other libraries)?

Here's a link to a randomly chosen website that has Java source for java.io.Bits: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/Bits.java

Nulano
  • 1,148
  • 13
  • 27

2 Answers2

9

You'd have to ask one of the Java devs for sure, but by making it package private, the API can be treated as "internal" - i.e. it might change or disappear at any time. This means the API can be developed relatively quickly, and doesn't need to go through the same relatively thorough testing process that public APIs need to go through (since once they're released, they're stuck there for good.)

In short, making an API public has long term implications, and it requires much, much more work than just hitting a switch.

I would hazard a guess it started life as a "hacked together" group of functions useful for a few other classes in the IO package, and has just stayed there ever since.

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
  • Do you think it's ok to just make a personal copy and distribute it with an application? – Nulano Sep 12 '14 at 18:12
  • 4
    @Nulano - i'm pretty sure it's not. although i guess that depends on the license of your app. modern jdk is GPL i believe, so if your app is GPL, then it may be okay. – jtahlborn Sep 12 '14 at 18:17
  • Looking at whats in the code, I'd say its pretty trivial code; asked for such methods any competent programmer will come up with a very very similar (if not identical) implementation. While not a proper justification; I guess the code isn't original enough to warrant any copyright infringement claims. – Durandal Sep 12 '14 at 18:40
  • 1
    @Nulano: Why bother, if there's equivalent public APIs as discussed in my answer? – Louis Wasserman Sep 12 '14 at 18:50
  • @LouisWasserman After looking through the source code (on GrepCode - OpenJDK 7u40-b43) I feel like `ByteBuffer` generates lots of background calls and I think it's easier to just call `Bits.getXXX` instead of `new ByteBuffer(bytes).getXXX()` when I have no use for the other methods of ByteBuffer. – Nulano Sep 12 '14 at 18:56
  • @Nulano: `ByteBuffer` is complicated, but it's also very, very tightly optimized. It's intended _exactly_ for the sort of use case you're describing. And as described in my answer, it's not particularly long or complicated to use for what you're describing. – Louis Wasserman Sep 12 '14 at 18:57
  • @LouisWasserman I accidentaly posted the comment before being done. I'm sure it's well optimized, but I think it's nicer to use Bits.getXXX than wrapping an array in ByteBuffer to use it's getXXX. I will however use the ByteBuffer method more commonly if not exclusively since it's other features are pretty nice too. – Nulano Sep 12 '14 at 19:00
  • 1
    @LouisWasserman Actually, java.io.Bits is apparently faster than java.nio.ByteBuffer, altough it's probably a minor difference in most scenarios. http://www.evanjones.ca/software/java-bytebuffers.html and http://www.jroller.com/cpurdy/entry/raw_nio_performance – Nulano Sep 22 '14 at 14:44
4

It's package-private, sure, but there are public APIs that expose the same behavior, e.g. ByteBuffer.wrap(array).getInt(index) and the other methods on ByteBuffer. You're almost certainly better off using that properly designed, well-documented public API than trying to wrap or copy internal implementation details from Java.

Louis Wasserman
  • 191,574
  • 25
  • 345
  • 413
  • I do think this is an answer worth accepting, but since I can "accept" only a single answer, you only get +1. – Nulano Sep 12 '14 at 19:09
  • I was unsure about the performance of ByteBuffer vs java.io.Bits so ran a quick test. Results show that for storing java.io.Bits is the fastest with absolute BB right after, and for reading absolute BB is the fastest with relative big endian and then little endian following, Bits slowest. Here's a pastebin link to detailed results and src code for my test: http://pastebin.com/XStkmN8s – Nulano Sep 22 '14 at 20:28
  • Update: I updated the pastebin to add tests on my Ubuntu machine. They are much in the favor of java.io.Bits, but big endian absolute ByteBuffer is close behind. – Nulano Sep 26 '14 at 15:08