SanderMak

Good question! Though, SB2 is supported until Nov. '23 (see https://spring.io/blog/2022/05/24/preparing-for-spring-boot-...). We definitely plan to be upgraded by then.

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!

Thanks, I guess? FYI, I joined Picnic in 2019, long after this choice had been (independently) made.

Sounds like a very interesting setup! Is there a blog post or something similar with more details?

In general, the Learning Paths give a good high-level overview of what's available: https://www.pluralsight.com/product/paths

As a Pluralsight author [1], I'm delighted to see the course library widely available this month!

See also this HN thread [2] from last year for more discussion.

[1] https://app.pluralsight.com/profile/author/sander-mak

[2] https://news.ycombinator.com/item?id=22759628

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.

Note that this is not in JDK 15, but an upcoming direction for the language:

> The ability to reason clearly and conclusively about permitted subclasses will be realized in a future release that supports pattern matching.

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).

[1] https://www.reddit.com/r/programming/comments/ftlv6d/psa_all...

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.

[1] https://app.pluralsight.com/profile/author/sander-mak

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 Technologies | Software Engineer (Java) | Amsterdam, The Netherlands | ONSITE | Full-time | https://join.picnic.app/job/software-engineer-986403

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

Wondering about our application process? It's fully transparent and described here: https://hiring.picnic.app (if you have suggestions for this process, feel free to create a Pull Request: https://github.com/PicnicSupermarket/hiring-experience).

Our tech stack: Java 11 / Spring (Reactor/WebFlux) / PostgreSQL / MongoDB / Kubernetes / AWS / GitHub

For other development roles, see https://join.picnic.app/team/technology-and-engineering

You can apply through the links above, or shoot an email to sander.mak@teampicnic.com if there's anything you can't find in the supplied links.

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.

I'll be speaking there January next year and definitely looking forward to that! Heard great things about LJC.

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.

Nothing, the big thing here is the long-term support. Multi-platform and production-ready are practically a given for any OpenJDK distro.

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)

I've done that by putting Cloudflare in front, as discussed here: https://blog.cloudflare.com/secure-and-fast-github-pages-wit...

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)

Great questions.

- OSGi: offers run-time modularization (based on classloaders), with a more dynamic model (bundles can start/stop/load/unload). Often derided for its complexity, which Jigsaw has tried to reduce (in part by offering a less dynamic model)

- Forced modularization: fortunately, Java 9 has many migration features to allow incremental modularization. Most notable are automatic modules, which allow you to treat non-modularized JARs as modules, and interoperation between automatic modules and the classpath

Hope this helps.

Not really: using modules is completely optional. Small applications likely won't benefit from the structure and guarantees modules offer. Large-scale applications, however, will certainly benefit from strong encapsulation and explicit dependencies all enforced from compile-time through run-time (and adding an optional linking step for modules with jlink).

(full disclosure: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com)

I think 'serendipity' [1] is the most-used term in recommender systems to describe what you mean.

[1] https://books.google.nl/books?id=_AfABAAAQBAJ&pg=PA258&lpg=P...

Just want to point out that Jigsaw/Java 9 will not support multiple versions out-of-the-box. (disclosure: I'm currently authoring Java 9 Modularity for O'Reilly)

  If the Public Draft Specification Ballot fails, the Expert
  Group will have 30 days to update the draft in response to
  the concerns raised by the EC and to submit a revised version
  to the PMO. If a revised draft is not received within 30
  days, the original decision by the EC shall stand and the PMO 
  will declare the JSR closed. If a revision is received, the
  PMO shall forward it to the EC and initiate a Public Draft
  Specification Reconsideration Ballot.

From: https://jcp.org/en/procedures/jcp2#3.4.5

Be sure to read the comments on the votes though. Most votes offer an opening for reconsideration, since progress was already made since the version that was submitted for the Public Review Ballot.

Whoops, you're right!

Author here. Java 9 adds a new module system where module descriptors are introduced to explicitly demarcate the public API of a module, and to express its dependencies on other modules. Example of a module descriptor:

  module mymodule {
    exports mymodule.pkga;
    exports mymodule.pkgb;

    requires someothermodule;
  }

What happens is that every package except the ones exported are accessible to other modules. Non-exported packages are encapsulated, not even reflection can break through that barrier. The requires statements are used by the Java compiler and runtime to verify the current configuration of modules resolves correctly.

Obviously there's lots of more detail to go into. Of course I recommend you check out my upcoming book (early release available) for that: http://shop.oreilly.com/product/0636920049494.do

In short, Java makes a great step forward wrt. modularity. When regular JARs transition to modular JARs (adding a module descriptor), many more checks and balances are in place than are currently possible with the classpath.

Great observation, and exactly what I meant with the modular alternative in this article. When you can 'get away' with such an architecture, it makes a lot of things simpler.

Absolutely, also see my other reply along these same lines: https://news.ycombinator.com/item?id=13960837

I'm with you on the complexity of OSGi, though some of the complexity plainly arises because it truly forces you to modularise vs. just winging it. In that regard, the new Java 9 module system has less of the service dynamics and classloading tricks going on. Very curious to see how the community will pick up the new module system.