Hacker News Reader

Comment by Promarged | Hacker News Reader

Bytes being signed is the ultimate Java oddity. Can't say how many times I've been bitten by this.

I also don't like it.

Legend goes that Gosling went around Sun offices and almost everyone failed to get unsigned versus signed math right, so they went with signed only types.

http://www.gotw.ca/publications/c_family_interview.htm

> Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.

At least Java 8 introduced unsigned math helper methods.

> so they went with signed only types

Except chars

> At least Java 8 introduced unsigned math helper methods.

They still aren't enough IMO. They don't have way ways to take LE/BE bytes out of integers or vice versa (not worth creating ByteBuffer for). I always end up recreating these utilities in projects where it isn't worth depending on or shading an entire Guava, e.g. [0]

0 - https://github.com/cretz/javan-warty-pig/blob/master/fuzz/sr...

Yep, lack of unsigned primitive types belongs to my list of Java pet peeves.

I’m not sure he was right about that. Sometimes you want unsigned types. If you only have signed types, you have to use them, but you might forget they’re signed. That’s almost certainly what caused this bug to be introduced, which will now never be fixed due to backwards compatibility: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=7025832

Yea, I've seen that explanation before, but it smells a lot like "postdiction" where you make up an explanation after the fact. I find it very hard to believe that "almost no C developer" understands unsigned arithmetic. And I'd doubt you'd get any argument from someone who understands both signed and unsigned, that signed arithmetic is the harder to understand of the two. But, even if he were correct, it still doesn't make sense, as abstracting away the complexity of common operations is exactly what high level languages are for.

Signed bytes are really really annoying in practice, and I can't say I ever wanted them as opposed to unsigned bytes. I wrote up about them a number of years ago: https://www.nayuki.io/page/javas-signed-byte-type-is-a-mista...

Wow. That is weird. I didn’t realize that. But then again, the only time I’m dealing with bytes in Java is for file reading. With the latest use having it wrapped in a Guava ByteStream.

I have to ask, why would you be trying to, I presume, be directly manipulating bytes in Java?

Embedded development, image manipulation, network protocols, parsing binary files...

Java is my main language, but not for those things if I can help it. For network protocols for example, I’m a big fan of Netty.

Thanks for answering!

I’m sure you’re aware of all this and I don’t want to backseat drive/code. It’s just I was on a project once where microsecond latency mattered and it was written in Java, but with a custom String class and custom garbage collection (using a custom object pool instead of relying on JVM’s to avoid any GC halt, which would be intolerable). It was a really fun project tech wise, but at that point, C/C++ would have made wayyyyyy more sense and saved us a lot of headaches.

There are plenty of options available in that domain.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/cms/en/JamaicaVM

http://www.microej.com/

https://www-03.ibm.com/software/products/bg/real-time

Then there are the Java variants out of Mountain View, although Android's performance is not in the same league as those ones.

This are just the most well known ones, Java is not only the OpenJDK.

As for microsecond latency, I guess it matters a lot to the US military.

http://www.militaryaerospace.com/articles/2006/10/lockheed-m...

"PERC Ultra offered Lockheed Martin the responsiveness it needed to meet its most demanding timing requirements. In addition to real-time threading and deterministic garbage collection, PERC Ultra provided the instrumentation and VM management tools necessary to support the mission-critical real-time requirements of the Aegis Weapon System."

"The Lockheed Martin-developed Aegis Weapon System is the sea-based element of the U.S. Ballistic Missile Defense System. The Aegis Weapon System is a radar and missile system integrated with its own command and control system, capable of simultaneous operation defending against advanced air, surface, and subsurface threats."

Err... Maybe not microsecond latency ? Yes PERC is AOT, and real-time (if you call sched-fifo and preempt_rt on Linux real-time) but consistent microsecond (!) latency on something other than microcontroler/dsp/fpga hardware and with PERC, I'd like to see. My experience says more likely millisecond latency, which is good enough for most radar applications (you'll have dedicated fine-tuned nanosecond-capable hardware for high quality rx / tx anyway)...

Edited: but Yes, and they're not the only ones that did radar or embedded software with PERC. There was a time (5-10 years ago ?) it was all the rage...

Thanks for the clarification. My knowledge is related to papers and articles.

You say you're a big fan of Netty. It's developers probably had to work with bytes in Java.

Base64

Video / audio codecs.

Cryptographic algorithms. (encrypt / decrypt, hash functions)

Cryptographic random number generators.

Ordinary random number generators.

PKI (key generation, validation)

Packing / unpacking binary structures used in wire protocols or message formats. (Example: a certificate, public key, jpeg, protocol buffers)

Implementing things like Protocol Buffer. (Language neutral binary format)

Implementing BigInteger. JDBC drivers.

Java libraries that create, compile, decompile or otherwise manipulate Java Byte Code.

Java libraries that create or manipulate other types of binary executable code. (eg, an EXE file)

Implementing Class Loaders for java.

The reasons you might work with bytes in Java are as endless as why you would work with bytes in C or any other language.

Oh yah, that’s right, I forgot about those since I’ve never implementing those things by hand before. I have used almost all of the list at one point, but never had the need to dive down and write my own and always have been fortunate to benefit from a great library or two to help out.

Thank you for the reminder!

Reply on news.ycombinator.com