I would say that pointer colouring is a type of pointer tagging. AFAIK the colouring in ZGC represents different states. So the memory page mappings rely on the pointer having one colour (1 of the 4 bits set) whereas pointer tagging is the term for the general concept of encoding information in pointers.
I find most developers I've met don't notice the distinction between the two types of time - I'd be interested to know whether people on HN have thought about it much before?
This is a really useful improvement if you're running a JVM on Docker, and about time too. We've had problems with this before no end and it normally requires a load of sysadmin time to work around things.
Because he takes a reference to a char[] in the constructor without copying it. char[]s are mutable so this means that the internal state of his String can be mutated by something else without any synchronisation guarantees.
Hire a professional accountant. They'll give you better advice than discussion forums on the internet. Even though HN is pretty decent for tech/business discussion generally.
Except when you need to have a guarantee of consistent response times. Response rates where the 99th percentile is guaranteed to be under, say 50ms is important in many real world applications, trading systems, sensor networks, controls networks etc.
The Java GC, no matter which way you tune it, fails at this in my experience.
There has been a lot of discussion on this kind of thing. One of the proposals for value types is to have them be immutable.
As to what to do in the meantime - I would suggest that you use either findbugs' immutability detection or Graham Allen's Mutability Detector: https://github.com/MutabilityDetector/MutabilityDetector. Findbugs picks up an @Immutable annotation and checks whether this is the case, whilst Mutability Detector allows you to assert that classes are immutable as part of your unit tests.
I appreciate its not as good as language support, but it is better than relying on an unchecked convention.
The distribution of new Java versions is already decoupled from tzdata updates.
If you want to update your tzdata then you should use the tzupdater tool that is shipped with Java. This has been updated to support JSR-310. If you want to perform the updates then this is just a commandline tool and can be integrated into chef/puppet etc. as needed.
There was discussion during the development of JSR-310 about the inclusion of Java library methods to update a running JVM. There are a load of "not obvious to a developer" things that happen if you do this and it was decided the technical complexity and potential confusion outweighed the benefit of implementing it.
That's what I was referring to, though, as being operationally expensive. I need to ensure we're using up-to-date tzdata, but there could be multiple different runtimes running on hosts in locations I'm not aware of.
All I really wanted to say is that I want to be able to do a file drop of all of the binary data in a well-known location on all hosts and have all of the relevant languages / runtimes point to those files without running any additional tools, etc. Complexity starts multiplying once you add these external processes because of additional failure modes -- e.g., someone can run the tool manually and make things out of sync, no tools to monitor that things do stay in sync, handling backout of bad deployed data, installing a new not-yet-updated JRE version to a machine.
Hi - just to be clear up front I co-authored the article. Thanks for raising this very valid point of confusion.
Let's address the issues one at a time.
1) What's the point in Local?
The goal is to give people the option to ignore the complexity involved with time zone rules. People are intuitively familiar with what these things mean. If you have a calendar on your wall above your desk: that's a LocalDate. If you have a clock on the wall: that's LocalTime. With respect to how they work in the presence of DST, they will automatically change time. For many use cases LocalDate and LocalTime is entirely suitable and people shouldn't be forced to put up with the unbearable complexity of timezones when they don't need to.
2) Why are they called Local?
As I mentioned above they represent the perspective of a clock on your wall or a calendar on your desk. They are local in this sense. I appreciate that these things might be a bit weird when you first get used to them and there was some discussion about renaming the classes during development. It was concluded that there were no better class names at the time. Furthermore if you looks at ISO 8601 [0] which is the most relevant standard to this API the same concept is also referred to as Local, Jodatime also uses the term Local.
3) Birthdays, Holidays and relative points in time
If you want to handle something like a birthday then there is a "MonthDay" class in JSR-310 which is designed for this exact purpose. It is a composite class of a month and a day and has an API consistent with the other classes in 310. If you want to handle 'relative' points in time then you might want to consider using the Duration or Period classes.
"floating" is a weird term, and I hate making words up, but at least it doesn't get confused in conversation with a time-zone-decorated timestamp that just happens to be in the user's local timezone.
But as long as it's possible to do what we need, which is sounds like it is, then that's what matters.
Thanks for the writeup.
EDIT: Regarding "Birthdays, Holidays and relative points in time",
MonthDay is not sufficient to describe all of the types of "floating" times, the canonical example given in RFC 2445 is of a user who wishes to appear unavailable at lunch every day, regardless of what time zone they are in. That's a more granular resolution than a day, but it's the same concept: an arbitrary precision, time-zone-less date that has no equivalent UTC start time until it is "observed".
