rlmw

One of the things that I find most interesting is how fast Kubernetes has spread all over people's cloud infrastructure.

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.

Write once, run anywhere: Java.

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.

Hope that helps!

[0] http://en.wikipedia.org/wiki/ISO_8601

Most people use the Jodatime library. JSR-310 is an extension of Stephen Colebourne's work on that library.

Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.