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.

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.

Seems pretty likely that Jigsaw will take > 1 year to complete.

I work for a company who sells a Garbage Collection log analyser if that counts!

http://www.jclarity.com/products/censum/

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.

[0] http://insightfullogic.com/blog/2012/dec/14/date-and-time-ja...

This was a study that used Master's students who had been developing Java for 4 years and Scala for 4 weeks. It's pretty weak methodologically.

Openjdk contains hotspot, and is now the reference implementation of the Java SE Platform. There are proprietary JVMs as well, but if you want to use an open source implementation you can and it is the reference, so compatible with the standard.

It's ok - someone has submitted a sigh to point this out:

http://devsigh.com/sigh/58

I don't really see what this has to do with the article itself. It's totally ridiculous to compare learning a new language, developer tools etc. with adding a single library to a project. Also, Scala is specifically designed to bring many benefits at the language and library level that Guava won't.

I really find this kind of Snark disappointing on HN, and one of the many examples of a decline in the quality of comments that PG has talked about.

Bear in mind the in-progress modularity JSR (http://jcp.org/en/jsr/detail?id=294) that might help this problem. Also, some people won't want everything that Guava provides.

I'm always wondering whether HN people think this kind of experimenting is a good idea or not.

Neither Java, nor c#, are simple. They're arguable less complex than things like f# and scala, but its quite a lot about the question of familiarity.

If you're coming from an imperative, oop, background then these languages will require more learning because you're not familiar with the concepts.

But a language like Java is huge by comparison with something like Javascript or python. In terms of the size of grammar, the number of semantic rules required for description, etc.

I've got to say that that is an epic pivot. I'm somewhat fascinated about:

a. When you knew it was time to pivot?

b. How much time you spent on your social network before moving on?

c. How much code/idea reuse there was between the two ideas?

d. How did you decide on what idea to pivot to?

Really can't help but think that their sales and conversion data is stronger evidence than your hunch.

http://www.neurosciencemarketing.com/blog/articles/apple-fan... is quite interesting in this regard. I know its focused on Apple users, but I wouldn't be surprised if you get similar results by putting evangelists for different platforms through the experiment.

I don't really see why people felt the need to downvote, it seemed like he was doing a shameless plug entirely appropriately.

He's also ignoring the existence of youtube, which is an incredibly popular platform for watching video on. In the UK we have several platforms for watching on demand TV, which are available in any web browser. The author clearly hasn't done the most basic research.