Null-terminated Unicode strings in java.io on Windows
roman at kennke.org
Fri Jan 25 17:17:03 UTC 2008
> The specification is buggy
> in that it does not take into account the operating system interface
> and makes correct memory management inefficient
> for the benefit of sparing one byte per buffer
> where an OS call is not needed.
> The developers at Sun
> found the correct way to interpreting the specification;
> the other ones followed it blindfolded. It is now time to repent.
> Wrong! Requiring null termimation will make things more inefficient.
> This is because Strings within Java are not null-terminated.
Unless the VM stores all strings with 0-termination internally, which is
possible, but arguably more inefficient on another level.
> If I was updating the spec, I would change it so that if a copy is
> returned it is always null terminated. If it isn't a copy then it may
> or may not be. It's likely no VMs will need changing, as I suspect
> the ones that do not null-terminate are returning direct pointers
> (e.g. JamVM).
Maybe we should all go to the original old bug (gosh! from 2001!) and
make some noise?
More information about the core-libs-dev