Null-terminated Unicode strings in on Windows

Roman Kennke roman at
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.
> Ridiculous.
> The developers at Sun
> found the correct way to interpreting the specification;
> the other ones followed it blindfolded.  It is now time to repent.
> </quote>
> 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 mailing list