Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Jigsaw: Complete

mreinhold.org

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Project Jigsaw: Complete

#81

Post by needusername »

pron wrote: post #53
needusername wrote: post #10

Earlier quoted context omitted.

> Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. That was only a few weeks. If you check the official release schedule http://openjdk.java.net/projects/jdk9/ Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule. > It w…

> They claim "reliable configuration" as a goal but without versioning that's meaningless. Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools. > For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different.…

> Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.

If I need third-party tools to validate my dependency graph at compile time and at runtime to ensure "reliable configuration" then why do I need Jigsaw at all? That's the current state of affairs with Java already, Jigsaw provides no value.

> Plus the entire development was done in the open, in an open source project with an active mailing list

Ostensibly. There is a difference between having an open mailing list (where people could give feedback and get a superficial thank you before getting ignored) and a readonly repository and actual open development. Quite frankly I find it telling that in 2017 we have to stress that there was and open mailing list and readonly repository. The most important thing, the decision process, was completely intransparent and all Oracle/Sun internal.

> and frequent prototypes.

Which weren't useful because none of the frameworks, libraries and tools would support it.

Re: Project Jigsaw: Complete

#82

Post by needusername »

abiox wrote: post #48
needusername wrote: post #44

Earlier quoted context omitted.

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?

> i thought jigsaw was about compilation artifacts.

Nope, jigsaw doesn't affect compilation artifacts other than an additional module-info.class present in a .jar file.

There is an intentionally completely unspecified, Oracle/OpenJDK proprietary extension (yes) called jlink that generates different artifacts. The aritfacts are unspecified, only work with Oracle/OpenJDK, and the licensing restrictions for redistribution are unclear.

> are you saying there are is a (nontrivial) runtime component? what does it do?

1. module definitions have to be parsed into memory structures to build a runtime model of the module system

2. the runtime model built in 1. has to be validated

3. every access has to be checked if it is permitted by the module system based on the information from 1.. If it is not permitted a decision has to be taken what should be done, this can include figuring out whether it is the first such access which needs additional memory structures (this is the default). See [1] for more information.

Probably some additional things that I forgot about.

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/...

Re: Project Jigsaw: Complete

#83

Post by pron »

catnaroek wrote: post #80
pron wrote: post #79

Earlier quoted context omitted.

> Abstract types are existentially quantified Oh, you mean something like this? interface A { T x(); void y(T t); } void foo(List > as) { // every element may have a different instance of T for (A a : as) bar(a); } void bar(A a) { T t = a.x(); a.y(t); } > There are no runtime type errors at all in Standard ML. There are no runtime type errors at all in TCL, either. That doesn't mean that the language is safer. "Safet…

> Oh, you mean something like this? Kind of, but, with wildcards, you still don't get the ability to unpack the existential for arbitrary further use. You can only unpack the existential within a single method, which is unnecessarily restrictive. If you unpack the same existential package twice (say, because you need to do it in two different methods, neither of which calls the other), then, as far as the type checke…

> Programming with abstract types in Java is a pain, which is why (understandably) Java programmers don't do it.

OK, but I never said Java is ML. The example I provided is not uncommon.

> Interoperability between two memory-safe languages is completely useless to me.

Fair enough, but it's clearly not useless to many people.

> Any price is high when you get nothing in exchange for it.

I think that polyglotism and dynamic capabilities are a good deal, and I think that many others find it at least as useful as complete type safety, but, of course, that depends on your needs and personal preferences.

Re: Project Jigsaw: Complete

#84

Post by pron »

needusername wrote: post #81
pron wrote: post #53

Earlier quoted context omitted.

> They claim "reliable configuration" as a goal but without versioning that's meaningless. Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools. > For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different.…

> Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools. If I need third-party tools to validate my dependency graph at compile time and at runtime to ensure "reliable configuration" then why do I need Jigsaw at all? That's the current state of affairs with Java already, Jigsaw provides no value. > Plus the entire development was done i…

> Jigsaw provides no value.

I think you should read more about Jigsaw.

> I find it telling that in 2017 we have to stress that there was and open mailing list and readonly repository.

We don't need to stress it, just to correct an incorrect report.

> The most important thing, the decision process, was completely intransparent and all Oracle/Sun internal.

This is simply not true, as a quick look at the mailing-list archive would show, as well as from the fact that the project took 9 years.

> Which weren't useful because none of the frameworks, libraries and tools would support it.

They were welcome to support them. I'm not sure what it is that you want, exactly.

Re: Project Jigsaw: Complete

#85

Post by btym »

Koshkin wrote: post #12
djhworld wrote: 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…

> 15s Still sounds ridiculous. Assuming this is how much time it takes to initialize the VM, I wonder if it would be possible to have a pool of VM processes that are already running and ready to accept an application code.

>Assuming this is how much time it takes to initialize the VM

Why would you assume that?

Re: Project Jigsaw: Complete

#86

Post by riffraff »

ksec wrote: post #72
clra wrote: 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'd really love to see languages like Ruby tackle this next. It's sorely needed. Could you expand on that? Why Ruby?

not OP, but ruby's current "modules" are just namespaces.

What jigsaw and rust call modules are isolated components that you can plug and connect in various configurations, and that declare public interfaces both as dependencies and as exported symbols. Consider a module configuration like

  module java.sql {
    requires public java.logging;
    requires public java.xml;
    exports java.sql;
    exports javax.sql;
    exports javax.transaction.xa;
  }
So, they are actually slightly closer to rubygems + bundler, but ruby is always "promiscuous", i.e. code from one library can trivially mess up with code from other gems, while some isolation would be nice.

Also, by default ruby does not namespace things by package/module/gem so it's easy to have collisions, while in a more robust system this would/should be under the control of the calling code.

Post reply on HN