Live data from Hacker News

Project Jigsaw: Complete

mreinhold.org

41–50 of 86 posts

Re: Project Jigsaw: Complete

#41

In the organization I work for, we're contemplating a move from Oracle JDK to OpenJDK, when we move from 8 to 9. I'm still nervous about OpenJDK from some historical scary stories of things not working well in OpenJDK or at least different. I've not found much on the subject, or even on OpenJDK as a functioning open source project. (Or is it just a code drop of the Oracle JDK?) If anyone has good insights, or links t…

Note: Oracle is my employer, the following statements are my own — (insert Safe Harbor notification)

Good news regarding any trepidation on the differencesa between the runtimes — recently we announced that there will no longer be a difference between OpenJDK and OracleJDK [1]

To quote: “The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)”

[1] https://blogs.oracle.com/java-platform-group/faster-and-easi...

Re: Project Jigsaw: Complete

#42
post #17
post #4

I don't follow Java too closely and the world "module" is so hopelessly generic that I had a hard time understanding what the article was talking about. It links to this document [1] though, which is a long read, but does an excellent job of describing of describing all the ins and outs of the module system. (tl;dr Packages can now declare themselves as modules instead of simple namespaces, and they get to choose exa…

> ...because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust) Haha...I love Rust, but you must not have been following the recent saga over modules in the community. Two things became abundantly clear: 1) There are definite issues with the current way that Rust does modules and they create problems for newcomers that don't know all the intricac…

The problems the Rust module system has and the changes being made to it are purely syntactic. Rust has already solved, and isn't changing its solution to, the kinds of problems Java is solving with Jigsaw.

FWIW, I don't agree with the "design by committee" assessment on the new system, either. There was certainly a lot of committee-flavored input, but it was only used for brainstorming and gathering requirements. The actual RFC, especially at this point, is pretty coherent and put together by only one or two people.

Re: Project Jigsaw: Complete

#43
post #19

Earlier quoted context omitted.

I don't know if it's still a problem with Spring, but at a previous job about 8 years ago I was able to cut our application's start time from about 80 seconds to ~12 by writing a custom implementation of the logic that Spring used to find bridge methods to determine the proper annotations. We profiled the startup and found that over 80% of the time was being spent in reflection to resolve those bridge methods and tha…

Dave Syer looked at this topic recently[0]. Most of the time spent in loading isn't due to reflection or annotation processing: it's proportional to the number of classes loaded. That said, Spring is fairly enthusiastic about pulling stuff. As he says: > Since more beans mean more features, you are paying at startup for actual functionality, so in some ways it should be an acceptable cost. On the other hand, there mi…

> most of the cost is actually to do with loading and parsing classes

It boggles my mind that loading and parsing even a few thousand classes is something that a human can perceive as "dog slow" when carried out by a quad-core 1.2 GHz CPU.

Re: Project Jigsaw: Complete

#44

Will this resolve the slow start problem in serverless apps?

It's a step. Still 10x slower start I suspect compared to node, but much better "warm" performance.

Nope, it makes things (a little bit) worse because now you also have to start up a module system.

Re: Project Jigsaw: Complete

#45
post #34
post #17

Earlier quoted context omitted.

> ...because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust) Haha...I love Rust, but you must not have been following the recent saga over modules in the community. Two things became abundantly clear: 1) There are definite issues with the current way that Rust does modules and they create problems for newcomers that don't know all the intricac…

> it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect. I wish that the term "design by committee" didn't have the stopping power it has. Rust's current module system absolutely wasn't designed by committee, and if there's one complaint that I'd levy against it it'd be "overengineered", which is typic…

Yeah, design by committee isn't a bad thing. See e.g. Common Lisp which, being defined by an ANSI standard, shows how great things can be when you have a committee made of smart people who inform their work by carefully evaluating what other smart people before them tested in the field.

Re: Project Jigsaw: Complete

#46
post #4

I don't follow Java too closely and the world "module" is so hopelessly generic that I had a hard time understanding what the article was talking about. It links to this document [1] though, which is a long read, but does an excellent job of describing of describing all the ins and outs of the module system. (tl;dr Packages can now declare themselves as modules instead of simple namespaces, and they get to choose exa…

> I have a hard time being too impressed because more modern languages are doing this out of the gates

The problem with Java is that it's an already established and very popular platform and it's been so for the past decade at least. When starting from scratch, it's easy to just throw it all away and start fresh, it's easy to fix mistakes that were made in the past.

The irony though is that we still have a hard time learning from history. Just look at Go. Sometimes this industry feels like Groundhog Day, the movie.

Also, no platform or language that I know of has gotten "modules" right, with Java being one of the platforms that has gotten closest to fixing the problem actually (by means of OSGi). To see why modules are still a big problem and why we won't have a fix for the foreseeable future, I invite you to watch this keynote by Rich Hickey: https://www.youtube.com/watch?v=oyLBGkS5ICk

Re: Project Jigsaw: Complete

#47
I'm still not sure of the practical benefits? Seems to be purely for IOT and nothing else. Am I correct?

Edit: To add to my question, jar hell was solved by tooling which generates your classpath for you. So it hasn't been an issue for me in years. And they refused to add versioning, so you still need to use those tools. Strong encapsulation just means they disabled reflection access to non public members, which I consider a regression on functionality. Either way, not a particularly useful feature to me, in fact it breaks some of my code. So I'm left with being able to have small JVMs which don't bundle the full standard lib, which seems to be mostly of use for memory constrained environments like IOT. But I'm actually hopeful there's some bigger practical benefits I'm not thinking of, so I'd love to hear from people who know more about jigsaw.

Re: Project Jigsaw: Complete

#48

Earlier quoted context omitted.

It's a step. Still 10x slower start I suspect compared to node, but much better "warm" performance.

Nope, it makes things (a little bit) worse because now you also have to start up a module system.

> start up a module system

i thought jigsaw was about compilation artifacts. are you saying there are is a (nontrivial) runtime component? what does it do?

Re: Project Jigsaw: Complete

#49
post #34

Earlier quoted context omitted.

> it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect. I wish that the term "design by committee" didn't have the stopping power it has. Rust's current module system absolutely wasn't designed by committee, and if there's one complaint that I'd levy against it it'd be "overengineered", which is typic…

Yeah, design by committee isn't a bad thing. See e.g. Common Lisp which, being defined by an ANSI standard, shows how great things can be when you have a committee made of smart people who inform their work by carefully evaluating what other smart people before them tested in the field.

    (setf (readtable-case *readtable*) :invert)

Re: Project Jigsaw: Complete

#50
post #3

I think it's going to take me a while to learn about the module system in Java 9, I'm probably going to bank on watching other projects do it first to see if any best practises emerge as developers get used to the new way of working. One thing I will say though is Java 9 has had a definite improvement on Java applications that run on my Raspberry Pi 3, I think because this got included http://openjdk.java.net/jeps/29…

For ARM, always use Oracle VM. It's around 15x faster for my application.
Post reply on HN