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

71–80 of 86 posts

Re: Project Jigsaw: Complete

#71

Post by catnaroek »

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…

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

That's not an abstract type, it's an object type. An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. OTOH, objects with the same type may have different internal representations, determined by whoever constructs the object, just as in your example.

> It seems like you're defining "safe" to be precisely what the languages you like provide, no more and no less.

Safety is defined in terms of the language's semantics, not my personal preferences: are meaningless operations ruled out or not? (We can get technical and say that Java does, in fact, assing a meaning to invalid casts: to throw ClassCastException. But very few people would consider that a useful meaning: if you run into it, your program plainly has a bug.)

> Java is mostly type safe.

Then it isn't.

Re: Project Jigsaw: Complete

#72

Post by ksec »

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?

Re: Project Jigsaw: Complete

#73

Post by pron »

catnaroek wrote: post #71
pron wrote: post #66

Earlier quoted context omitted.

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

> By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`. That's not an abstract type, it's an object type. An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. OTOH, objects with the same type may have different internal representations, determined by whoever constructs the object, ju…

> An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program.

So, like:

     foo(A a, B b) { ... }
You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type.

> Then it isn't.

That it's not completely typesafe (Scala isn't, either, BTW) doesn't mean that it's not completely safe. The vague notion of safety is not defined by the arbitrary notion of type safety, which heavily depends on the type system. TCL is typesafe, but few would say it's safer than Java.

> But very few people would consider that a useful meaning: if you run into it, your program plainly has a bug.

There are many more plainly incorrect behaviors that aren't prevented even when the language is 100% type safe (depending on the type system, and the effort required to encode the correctness conditions) -- as Java prior to generics was, BTW. So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but similar) richness (i.e., they are both simple type systems with parametric polymorphism), and given that you don't actually run into `ClassCastExceptions` in Java unless you choose to do stuff that can get you into that sort of trouble (which would mean ignoring compiler warnings), I think the two languages offer a similar level of safety.

Re: Project Jigsaw: Complete

#74

Post by pulse7 »

thcsa wrote: post #50
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…

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

Please read on http://openjdk.java.net/jeps/297: "The contribution from Oracle provides full C1 and C2 support for ARM, putting it on par with other architectures."

So from now on the OpenJDK will be as fast as Oracle VM on ARM!

Re: Project Jigsaw: Complete

#75

Post by jcadam »

bad_user wrote: post #46
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 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…

OSGi is a bottomless pit of pain and despair. Never again will I work on any project built on OSGi modules (well, every man has his price, but you know what I mean).

Re: Project Jigsaw: Complete

#76

Post by catnaroek »

pron wrote: post #73
catnaroek wrote: post #71

Earlier quoted context omitted.

> By having two implementations of a common interface, like `ArrayList` and `LinkedList` both implementing `List`. That's not an abstract type, it's an object type. An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. OTOH, objects with the same type may have different internal representations, determined by whoever constructs the object, ju…

> An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. So, like: foo(A a, B b) { ... } You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type. > Then it isn't. That it's not completely typesafe (Scala isn't, either, BTW) doesn't mean that it's not completely safe. The vague notion of safety is not define…

> So, like (...) You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type.

Abstract types are existentially quantified, whereas generic type parameters are universally so.

> Scala isn't, either, BTW

Scala isn't type safe either, period.

> So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but similar) richness (i.e., they are both simple type systems with parametric polymorphism)

Actually, Java's type system is more complicated, since it has subtyping, as well as a limited form of first-class existentials (wildcards) that Standard ML doesn't have, yet somehow Java buys me less safety than Standard ML. This is what happens when engineers design programming languages.

> and given that you don't actually run into `ClassCastExceptions` in Java unless you choose to do stuff that can get you into that sort of trouble (which would mean ignoring compiler warnings), I think the two languages offer a similar level of safety.

There are no runtime type errors at all in Standard ML.

Re: Project Jigsaw: Complete

#77

Post by bad_user »

jcadam wrote: post #75
bad_user wrote: post #46

Earlier quoted context omitted.

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

OSGi is a bottomless pit of pain and despair. Never again will I work on any project built on OSGi modules (well, every man has his price, but you know what I mean).

I agree, OSGi sucks, but it's one of the few attempts at fixing the problem with compatibility breakage in dependencies.

Re: Project Jigsaw: Complete

#78

Post by didibus »

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…

I see, why would you split a library accross many Jars though? What's the advantages? Isn't it again IOT, so that if you only use part of a jar, you don't need to have the full thing loaded?

Re: Project Jigsaw: Complete

#79

Post by pron »

catnaroek wrote: post #76
pron wrote: post #73

Earlier quoted context omitted.

> An abstract type has a single representation, determined by the type's implementor, which is hidden from the rest of the program. So, like: foo(A a, B b) { ... } You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type. > Then it isn't. That it's not completely typesafe (Scala isn't, either, BTW) doesn't mean that it's not completely safe. The vague notion of safety is not define…

> So, like (...) You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type. Abstract types are existentially quantified, whereas generic type parameters are universally so. > Scala isn't, either, BTW Scala isn't type safe either, period. > So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but simila…

> 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. "Safety" and "type safety" are not the same. Type safety has its virtues, but I would argue that Java's type safety is good enough; I would take it along with its dynamic capabilities over SML for many projects -- it's just a tradeoff that buys you a lot of other stuff. There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List), and that's a price worth paying in many cases, considering that it's not high at all.

> This is what happens when engineers design programming languages.

I guess engineers prioritize things based on what they're actually worth to developers (or, at least, according to how much they believe they're worth to their developers) as opposed to using an arbitrary metric for some intrinsic quality, whose relationship with actual benefit isn't at all clear. Java sacrifices a tiny bit of type safety for interop and various dynamic capabilities. I wasn't aware that there's been some major discovery showing that this is the wrong tradeoff to make.

Re: Project Jigsaw: Complete

#80

Post by catnaroek »

pron wrote: post #79
catnaroek wrote: post #76

Earlier quoted context omitted.

> So, like (...) You don't know what `T` is, but you know that `a` and `b` are parameterized by the same type. Abstract types are existentially quantified, whereas generic type parameters are universally so. > Scala isn't, either, BTW Scala isn't type safe either, period. > So if you want to define "safe" as "typesafe", that's fine, but given than ML's and Java's type systems are of similar (not identical, but simila…

> 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 checker cares, that produces two different abstract types. Programming with abstract types in Java is a pain, which is why (understandably) Java programmers don't do it.

> There are no runtime type errors at all in TCL, either.

Yeah, but you don't get basic things such as integers, which is even worse.

> There's a price you pay for dynamic runtime capabilities and for deep cross-language interop (e.g. a Clojure list is a Java List)

Anyhow, the only thing I wouldn't want to do in Standard ML is manipulate arrays, mainly because runtime bounds-checking is unnecessary when you get your array algorithms right, but Standard ML requires it anyway. Interoperability between two memory-safe languages is completely useless to me.

> and that's a price worth paying in many cases, considering that it's not high at all.

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

Post reply on HN