Not that complicated, really. I'm part of Picnic now for quite a while. That's the 'we'. Of course I've discussed the origin story as used in the post at length with my close colleagues who were there from the beginning. Also, I'm very much part of the current choice not to migrate to e.g. Kotlin based on such discussions. So yes, this is our story which we want to share widely. It comes up every now and then, so now we have something to point people to. Didn't expect this to get picked up by HN, though!
That would be a new device to buy, since I'm using the original Chromecast. But I see your point about the upside of this bundling strategy, it just wasn't enough to win me over.
Good question. Just got an offer to sign up for a free year, after buying and activating a new iPhone. Unlikely to take them up on it, since it won't work with my existing Chromecast attached to my not-so-smart TV. I'm not interested in buying another device just to be able to stream Apple TV+. Likely many people are in a similar situation.
Should work with an existing account according to this official response on Reddit [1]. However, they seem to be overwhelmed at the moment so everything is taking longer (up to hours).
As a Pluralsight author [1] this makes me really happy! They've been (understandably) focusing on enterprises since the IPO, but it's great to see this gesture towards individual learners.
At my current company we do a full Pull Request review of the take-home assignment. After the interview, the review comments are shared with the candidate. We're based in Europe, so that might make a difference in terms of expectations around litigation.
Picnic is Europe's fastest growing online grocery scale-up. We create the whole experience all the way from our shopping app to delivering the groceries at the door with our own electric vehicles. Picnic is currently active in The Netherlands and Germany, expanding at a fast pace.
In this role, you help building products that support crucial parts of the Picnic experience. This ranges from a custom warehouse management system, to sophisticated planning and routing challenges, to e-commerce building blocks facilitating continuous experimentation. You can also read our blog to get a better feel for what we do: https://blog.picnic.nl
Oracle Code One is the successor of JavaOne. Since Oracle acquired Sun, the JavaOne conference was co-hosted with the much larger Oracle OpenWorld conference. Recently, JavaOne was rebranded into Oracle Code One, morphing it into a cross-technology conference rather than a Java-focused one.
As of JDK 11, there is feature parity between OpenJDK and Oracle JDK, which is the JDK that most people used until now. In JDK 8, the Oracle version had several closed source additional features (such as Java Flight Recorder and the Z garbage collector). Also, implementations of things like graphics rendering used to be different in Oracle JDK 8 and earlier. That's no longer the case. Oracle JDK and OpenJDK should be drop-in replacements for each other as of JDK 11.
Nope. In fact the module containing JAXB (and 5 other EE technologies) have been deprecated and will be removed in Java 11. So indeed, you can use the `--add-modules java.xml.bind` workaround, but it will break with Java 11. The real solution is to add a JAXB implementation of your choice as dependency to the application.
(disclaimer: I'm author of the O'Reilly book Java 9 Modularity (see https://javamodularity.com) which discusses this and other migration issues in great detail)
You're right in that JDK 9 highly values backward compatibility with JDK 8. However, there are still some caveats because of modularization of the JDK, that can affect your code (or your libraries) even when running on the classpath without modules:
- some Java EE technologies that are tradionally part of Java SE as well, won't resolve by default when compiling/running on the classpath (JAXB will be the most noticeable)
- JDK 9 strongly encapsulation internal implementation classes (think of types in com.sun.* and sun.* packages). When running on the classpath, there's a lenient form of strong encapsulation: you will get a warning on the console when reflectively using these types. In time, this lenient mode will be switched to a more strict enforcement. Ergo: time to wean code off the dependencies on internal implementation classes
The first restriction you'll probably run into (if you for example have a Spring application). The second restriction is more an issue for library maintainers (though you should start complaining to said maintainers if your application starts printing warnings)
All in all, it's not a 100% drop-in replacement, but it's close enough for most scenarios. The trick is to make sure your application will keep running in the future as well, when a more strict strong encapsulation regime will be enforced for classpath-applications as well.
(full disclosure: I'm author of Java 9 Modularity, O'Reilly, which covers many migrations scenarios as well. See https://javamodularity.com)