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

61–70 of 86 posts

Re: Project Jigsaw: Complete

#61

Post by watwut »

clra wrote: post #7
chrisseaton wrote: post #5

Earlier quoted context omitted.

> I have a hard time being too impressed because more modern languages are doing this out of the gates and with far fewer hacks Well of course - it's easier to build something like this into a clean-slate language isn't it? It's harder to build it into an existing language and VM spec with an incomprehensibly large volume of existing code to be compatible with. It's backwards to say it's not impressive because someon…

> Well of course - it's easier to build something like this into a clean-slate language isn't it? It's harder to build it into an existing language and VM spec with an incomprehensibly large volume of existing code to be compatible with. It's bizarre to say it's not impressive because someone else with zero constraints to work with also managed it. I hope my original comment was relatively clear on this, but sure, it…

They are advancing Java itself. Those who work with Java on large projects (which is the Java use case) will find modules useful. There is huge community around Java and even more people who use it, but don't count itself members of any community.

Re: Project Jigsaw: Complete

#62

Post by alkonaut »

pjmlp wrote: post #51
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…

.NET does have the module level directive "InternalsVisibleTo" that declares another assembly as a friend assembly that can use internal API's from the first assembly. So if you have e.g MyLib.Core and then two impls on top say MyLib.Windows and MyLib.OSX, where everyone would only use one of the impl libs but always the core lib (which is why it was split - then you could make internal API in the core lib visible ONLY to the Windows/OSX libs by using InternalsVisibleTo, and users of the library could not see that internal API.

Re: Project Jigsaw: Complete

#63

Post by pron »

catnaroek wrote: post #59
pron wrote: post #52

Earlier quoted context omitted.

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

Oh, I simply meant any safe, typed language, and that was the first that came to mind.

Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types. I also strongly disagree with your description of Java's parametric polymorphism being "botched", and certainly not that its "entire point" is defeated. That it can be circumvented is what makes code and data sharing between different languages with different variance models possible (compare to how badly that's done in .NET). So it's simply a matter of what requirements are more important to you.

I can understand those that think that Java not being fully static or fully dynamic may defeat the whole purpose of what they like in their preferred approach. But I think that Java combines static and dynamic aspects in a rather unique and novel way, and the new module system is not different, combining in an interesting way both static and dynamic aspects.

Re: Project Jigsaw: Complete

#64

Post by catnaroek »

pron wrote: post #63
catnaroek wrote: post #59

Earlier quoted context omitted.

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.

Oh, I simply meant any safe, typed language, and that was the first that came to mind. Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types. I also strongly disagree with your description of Java's paramet…

> Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures).

The whole point to structures and signatures is abstract types. Mere value hiding can be achieved with let, which isn't exactly the pinnacle of typing: Scheme has it.

> I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types.

Please do tell how you would make two or more instances of an abstract type in Java, in such a way that:

(0) The client is aware that that the two instances have a common type.

(1) The client is not aware of the representation.

If it's not possible, then Java doesn't have abstract types, period.

> That it can be circumvented is what makes code and data sharing between different languages with different variance models possible

And unsafe. (No, memory safety alone isn't safety.) If it's going to be unsafe, then I better at least get my money's worth in terms of performance, which is why low-level languages like C and Rust are the only ones worth FFI'ing to.

> I can understand those that think that Java not being fully static or fully dynamic may defeat the whole purpose of what they like in their preferred approach.

Java is fully dynamic. “Type checking” in Java is basically a mandatory linter.

Re: Project Jigsaw: Complete

#65

Post by imtringued »

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?

Because not everyone cares about the startup time of an application on a platform that is 10 times slower than an intel CPU from 2012 when the application runs for more than a minute?

Also why are you even considering go as modern? The best compiled alternative to java is D and it's possible to disable the stop the world pause for specific threads by detaching them from the runtime which make it useful for realtime workloads while still being able to take advantage of the GC to boost your productivity when determinism is not important.

Re: Project Jigsaw: Complete

#66

Post by pron »

catnaroek wrote: post #64
pron wrote: post #63

Earlier quoted context omitted.

Oh, I simply meant any safe, typed language, and that was the first that came to mind. Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). I think interfaces (and the ability to override methods like `equals` are pretty close to abstract types. I also strongly disagree with your description of Java's paramet…

> Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). The whole point to structures and signatures is abstract types. Mere value hiding can be achieved with let, which isn't exactly the pinnacle of typing: Scheme has it. > I think interfaces (and the ability to override methods like `equals` are pretty close…

> Please do tell how you would make two or more instances of an abstract type in Java, in such a way that...

By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`.

> And unsafe.

It seems like you're defining "safe" to be precisely what the languages you like provide, no more and no less. I can say that ML and Haskell are unsafe because they don't statically forbid erroneous behavior at runtime, like a sorting function that doesn't sort (or doesn't terminate). Java has no undefined behavior. In fact, it is completely unknown how much safer -- if at all -- is ML than Java in practice.

> If it's going to be unsafe, then I better at least get my money's worth in terms of performance, which is why low-level languages like C and Rust are the only ones worth FFI'ing to.

Of course it's a matter of specific requirements, but I think you get more than your money's worth in terms of performance in Java, and having decades of experience writing huge multi-MLOC programs in both Java and C++, I'm convinced that it takes significantly less effort to get a well-performing large Java app -- especially if it's concurrent -- than a C++ app, even though you could surpass Java's performance given considerable additional effort. In any event, I think that the success of the JVM shows that many people find supporting it to be worth it.

> Java is fully dynamic. “Type checking” in Java is basically a mandatory linter.

This is simply untrue. Java is mostly type safe. If you have a variable of type `Foo` in your program, it cannot reference an object of a type that is not `Foo` at runtime. You are right that this does not extend to generic types, but only if -- 1. you've intentionally tried to circumvent the type, or 2. you've fallen victim to an obscure bug that was found recently, and is very hard to reproduce accidentally.

Re: Project Jigsaw: Complete

#67

Post by jacques_chester »

semi-extrinsic wrote: post #43
jacques_chester wrote: post #31

Earlier quoted context omitted.

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.

My understanding is that it's I/O bound, that the JVM more or less fetches each class from the JAR file or disk individually.

I am not sure if that's an implementation decision or whether it's imposed by the JVM specification. At some point I want to tinker with OpenJ9 to find out.

Re: Project Jigsaw: Complete

#68

Post by pjmlp »

alkonaut wrote: post #62
pjmlp wrote: post #51

Earlier quoted context omitted.

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…

.NET does have the module level directive "InternalsVisibleTo" that declares another assembly as a friend assembly that can use internal API's from the first assembly. So if you have e.g MyLib.Core and then two impls on top say MyLib.Windows and MyLib.OSX, where everyone would only use one of the impl libs but always the core lib (which is why it was split - then you could make internal API in the core lib visible ON…

Yep, that is what I meant by mentioning .NET in "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

#69

Post by alkonaut »

pjmlp wrote: post #68
alkonaut wrote: post #62

Earlier quoted context omitted.

.NET does have the module level directive "InternalsVisibleTo" that declares another assembly as a friend assembly that can use internal API's from the first assembly. So if you have e.g MyLib.Core and then two impls on top say MyLib.Windows and MyLib.OSX, where everyone would only use one of the impl libs but always the core lib (which is why it was split - then you could make internal API in the core lib visible ON…

Yep, that is what I meant by mentioning .NET in "This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept."

Right. Thought you meant "the file/assembly is the module, no way around it" was the concept.

Re: Project Jigsaw: Complete

#70

Post by ratmice »

pron wrote: post #66
catnaroek wrote: post #64

Earlier quoted context omitted.

> Having said that, Java is a typed, safe OO language, and that alone, I contend, already makes it close in spirit to ML (in particular, its structures/signatures). The whole point to structures and signatures is abstract types. Mere value hiding can be achieved with let, which isn't exactly the pinnacle of typing: Scheme has it. > I think interfaces (and the ability to override methods like `equals` are pretty close…

> Please do tell how you would make two or more instances of an abstract type in Java, in such a way that... By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`. > And unsafe. It seems like you're defining "safe" to be precisely what the languages you like provide, no more and no less. I can say that ML and Haskell are unsafe because they don't statically fo…

>> Please do tell how you would make two or more instances of an abstract type in Java, in such a way that...

>By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`.

This is not i believe what he is talking about, here is a silly example in SML, it has 3 types which all share a type t... a list of t pairs, a vector of t's, and a function from pair of t's to t.

functor Foo (type t; val pairs : (t * t) list val f : t * t -> t) = struct val things : t vector = Vector.fromList (List.map f pairs); end

One thing to note is that t is never exported/returned. and thus, the thing returned exports t vector but not t.

we could export t in a few different ways:

type t = t; Export it, let its binding be known type t; Its a type, but what it is bound to is not known.

Post reply on HN