@bamdmux Thanks, very interesting.

@hates has left the channel

@orangy Reading the comments on the votes, seems that its going to be approved in the next round

when is the next round?

In 30 days it seems

the rules are here: https://jcp.org/en/procedures/jcp2#3.7.7 ->

When a failed JSR ballot results in the closing of a JSR, at least 30 days must pass before the JSR can be re-initiated.

so I guess 30 days as well

I don't see any reason why the vote in 30 days would look better

i know RHT is submitting formal requests for certain changes.

So it’s another year or something before Java 9?

I like SAP SE's closing remark:

Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!

that blog post was ... questionable ...

Which one, the one from RH?

Mark doesn’t seem open to listening to RH’s recommendations: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000695.html

@cedric mark's

why do they cry just before release of java 9 ?

they had time to cry before no ?

this sounds suspicious

not serious at all

sounds like they are too lazy to learn new stuff

Most of the API changes in Jigsaw use java.util.Optional for getter return values as a substitute for null-checking.

AHAHAHAH

Sorry. Just... yet another internally inconsistent perspective on how Optional should be used.

If I've learned one thing about how the JDK is grown over the last couple years, it's that advice is always ignored.

We understand that after inception the original goals of the EG were initially changed to try to focus it on a module system to be used solely to modularise the JVM and that caused some architecture and implementation approaches which made it difficult for it to be a module system to be used by SE and EE developers. Unfortunately during the lifetime of the EG the goal appeared to switch back to trying to make it a module system for Java developers but previous implementation decisions appear not to have been revisited or could not be changed and as a result the expectations around Jigsaw have not been met by the implementation.

That's the impression I continually get - that it doesn't know which problems it's trying to solve, and therefore doesn't solve them, or only does so poorly.

It's a quite interesting to see how hard it is to change such a big and 'grown' piece of software like the jvm

pitches it back to Guy Steele's 'Growing a Language'.

Growing a language is infinitely easier than growing a platform, which is what Jigsaw is about

Interestingly, Java doesn't follow most recommendations in "Growing a language" and yet manage to grow and evolve pretty well over two decades

Perhaps Java should not be in the business of managing its own platforms. 😉

I might say “yes” to each one of these, but it is clear that I must say “no” to all of them!

In this case, that is one of the suggestions that was made, and may be quite effective. Making this integral to and intertwined with Java the Language seems a losing proposition.