Both activities seem valuable and complementary to me -- there's no point in advancing the frontier if nobody will bother to make those advances practically useful.

Observer screenshot from a blank IEx session: https://puu.sh/xI3re/3701a0c64e.png

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

i thought jigsaw was about compilation artifacts. are you saying there are is a (nontrivial) runtime component? what does it do?

The difficulty is that I think the Rust process works better for changes that aren't as disruptive or fundamental to the language. The RFC process is not only open and fairly welcoming to people outside the core team, it's also a great educational resource. I've learned a lot about language design from reading the RFCs and the accompanying comments. So I don't think I'd trade the Rust model for a BDFL model. I just wish something more like Aaron's original proposal (the second original proposal, that is...the one that got turned into the most recent one) was being implemented, even though I disagreed with a good chunk of it.

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.

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.

I don't know if that's still the case, but it always bugged me that Spring would slow down the >99% case by so much just to accommodate the <1% case.

I believe that the last version of Spring (5) has a way to do the scanning at compile time now.

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.

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.

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

Oh, you mean something like this?

    interface A<T> {
        T x();
        void y(T t);
    }

    void foo(List<A<?>> as) { // every element may have a different instance of T
        for (A<?> a : as)
            bar(a);
    }

    <T> void bar(A<T> a) {
        T t = a.x();
        a.y(t);
    }

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.