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

51–60 of 86 posts

Re: Project Jigsaw: Complete

#51

Post by pjmlp »

didibus wrote: post #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 co…

Encapsulation is another one.

Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.

If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.

This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.

Re: Project Jigsaw: Complete

#52

Post by pron »

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 have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling

I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic (all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and general introspection of the runtime is pervasive). It's a blend of, say, ML, Smalltalk and Erlang. The module system is therefore more impressive than it may look at first glance. While not all the tooling is there yet, through the use of what it calls "layers", it makes it possible to dynamically load plugins or even upgrades to components in the system, each depending on different versions of the same library, while enforcing customizable levels of isolation between them. Whether or not there are any conflicts requiring a separation of "layers", can also be determined at runtime by introspection.

Re: Project Jigsaw: Complete

#53

Post by pron »

needusername wrote: post #10
morecoffee wrote: post #9

Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable. Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.

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

Plus the entire development was done in the open, in an open source project with an active mailing list and frequent prototypes.

Re: Project Jigsaw: Complete

#54

Post by pjmlp »

bitmapbrother wrote: post #35
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 have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling I'm curious, is there another language that allows you to streamline its runtime by choosing only what modules your app needs?

This was already used in Lisp and Smalltalk to trim down images for production delivery.

Other than that, the majority of compiled languages do remove unused library code when static linking.

Re: Project Jigsaw: Complete

#55

Post by pjmlp »

badsectoracula wrote: post #21

I remember this from... 11 or so years ago, i think. I was making some Java applet based game and the slow startup time and big JVM download was something that an issue among people making such games (which by the time i was into were dying - although they'd soon get a short lived shot in the arm thanks to Minecraft, but that was later). There were some posts in javagaming.org forums from some people who were talking…

That was the Kernel VM project.

http://www.oracle.com/technetwork/java/javase/kernel-135055....

http://openjdk.java.net/jeps/148

Re: Project Jigsaw: Complete

#56

Post by TeMPOraL »

patrec wrote: post #49
TeMPOraL wrote: post #45

Earlier quoted context omitted.

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)

Yes. What about it?

It's a useful feature to have, as it makes Lisp reader more flexible. See the summary of the discussion by the committee here: http://clhs.lisp.se/Issues/iss286_w.htm.

Re: Project Jigsaw: Complete

#57

Post by djhworld »

pebers wrote: post #18
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…

The improvement is good, of course, but isn't the whole thing a bit of a straw man? The previous version taking 55 seconds on a Pi 3 seems utterly unacceptable to me, it's actually a pretty capable processor, and even a 15 second startup is pretty slow. Why put up with that when there are modern options (Go and Rust spring to mind) which would do so much better?

It's a website that's for personal use (a dashboard), I don't update it that often.

Re: Project Jigsaw: Complete

#58

Post by catnaroek »

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…

The meaning of “module” is pretty concrete and specific. A module is:

(0) A unit of encapsulation: Modules can export abstract types whose representation is hidden from the rest of the program.

(1) A unit of type-checking: Modules can be type-checked without knowing anything other than the interface of their dependencies.

(2) A unit of translation: Modules can be translated to target machine code separately from each other. (That being said, whole-program compilation is fine if you want it. The semantics of the module system shouldn't make it mandatory, though.)

Most programming languages don't have module systems at all. And most programming languages that do have module systems, have module systems that suck. Including Rust.

Re: Project Jigsaw: Complete

#59

Post by catnaroek »

pron wrote: post #52
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 have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling I'm not so sure about that. Java (both the language and the VM) is relatively unique in its mix of static (mostly in the sense of being typed) and dynamic ( all linking is dynamic; code is often be loaded, unloaded and generated at runtime; reflection and gene…

Other than (its botched version of) parametric polymorphism (due to how easily it can be circumvented, defeating the entire point to it), what ML-influenced features does Java actually have? There is no global type reconstruction, there are no abstract types, and “computation as expression evaluation” is a royal pain in the rear hole in Java.

Re: Project Jigsaw: Complete

#60

Post by mschwaig »

sverhagen wrote: post #39
mschwaig wrote: post #27

Earlier quoted context omitted.

The biggest pain for me was that it felt like there was no good way to create a library with some internal structure in the form of packages without exposing parts of your internal implementation as public. When Jigsaw was delayed I was playing with the idea to create a project called shitty-jigsaw, which would just merge all of the packages in a module and change the access modifiers to be more restrictive according…

Would shading have done the job? Not to say that's a _good way_, but it _is_ a way.

Sure you can use shading to move everything you don't want in your public API into some other package, or you can use something like ProGuard to obfuscate everything but your intentional public API. However those things will still be public.

The only way to not have those things visible for the user of your library is to only use one package in your implementation.

Post reply on HN