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.
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.
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.
As of Java 7 openjdk is the basis for the official Oracle release of Java, and constitutes the reference implementation of Java SE. So if you've used any recent JDK release then you've used openjdk.
London has a pretty bad homelessness issue. There are lots of charities and voluntary contributions that attempt to address the issue but its a hard problem to solve.
London also has quite fragmented social ghettos. In most cities you have richer areas and poorer areas, London broadly has this, but has pockets of wealth in the poorer areas and pockets of poverty in the rich areas. To a much greater extent than I've seen in any city I've been to.
The current situation isn't too great in terms of the standard libraries - but Jodatime is still a good alternative, and at least the situation is improving.
You'll also find that there will be a release of Jodatime after 310 is finalised that allows it to implement the top level interfaces defined by 310 - eg Temporal. This will allow the libraries to play nicely together and means you'll probably be able to write code like:
LocalDate date = LocalDate.from(someJodaTimeObject);
My previous blog post [0] covered the simple case of 'Local' dates. If you're able to simplify your application code to avoid the use of timezones then that's a good thing to do, but boycott et al. isn't going to work. It might be possible if you're, say, writing a service internal to your company and all your servers are on UTC - its just a case of choosing something applicable to your domain.