Hacker News Reader

Comment by lmm | Hacker News Reader

> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in.) That theory has little explanatory power: why are all of these other companies voting against?

I think RedHat/IBM are opposing it because it isn't OSGi/JBoss (and whether that's for nefarious reasons or because they genuinely believe OSGi/JBoss are the Right Thing is beside the point), and most of the other opposition is following their lead.

I think OSGi/JBoss are failures in the market because they're hideously overengineered, and if Jigsaw is to succeed it should avoid solving most of the problems that OSGi/JBoss claim to. Rather it should solve the common case while being much simpler. The current proposal seemed like a pretty good effort to me.

View on HN

Anyone who believes OSGi is good is either (a) deluded or (b) ignorant.

Having just implemented a plugin solution using it I can safely say that in the past 20+ years of software development it is the most awful technology I've ever seen. The complexity and over engineering is simply breath taking. It is worse than EJB 1.0, worse than the crazy abuses I have seen with Spring and DI, worse than than dark days of J2EE.

I have lost a lot of respect for Red Hat and IBM after this.

I've been working on an OSGi platform for the last 6 years, and I can't agree with this more.

Let's hope the JDK doesn't adopt such wrongheaded approaches, and figures out a sensible way to implement modules. If they can't, then I'd be happy with the current state of third party opt-in approaches instead.

Damn straight. XML DI config files overwhelm end-users (and developers) with a metric crap container port of details and things to break in non-obvious, diffusely (un)documented ways. (See also: configuring Atlassian on-prem products)

Simplicity -> usability && maintainability && security && popularity

What has J2EE/Java EE been replaced with?

No single thing, rather it's been displaced by using specific targeted libraries instead of enormous frameworks.

Ah, thanks very much for your reply.

Worse that CORBA?

What is the common case Jigsaw solves? It doesn't deal with dependency versioning.

JVM size restrictability, higher-than-class-level modularity, module-level access restrictions, etc. Your question could be rephrased: "what are the common use cases that componentizing a runtime/stdlib solve?" Not everything is about the module ecosystem, package management, etc. Sometimes componentization has benefits itself without concern for additional features.

So, the final calculus is if the cost of having Jigsaw warrants the benefits that Jigsaw does provide. For me, the answer is clearly no.

"Modularity" is a word with a lot of meanings, and we're going to need to pin one down to discuss it meaningfully -- especially since competing module systems solve a different set of problems. To me, modularity is about isolation, and being able to run a lot of stuff together on a JVM that you previously couldn't; say because of incompatible versions of Guava or whatever. To you, it might mean "increased visibility restrictions". (I'm not arguing for one definition or another; just that we should probably agree on one.)

Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?

I don't think it breaks hardly anything except for those using many deprecated or internal items anyways. And if there are BC incompat concerns, they should be addressed specifically but they don't seem to be the primary reasons for "no". Sure we can agree that Jigsaw is not necessarily required for JVM modularization. But surely we could also agree that dogfooding a feature available to all is much better than an internal-only set of jmod files with their own internal-only way of being used. We all want the benefits of modularity especially wrt access restrictions across modules.

Reflection to sidestep visibility wasn't deprecated, and the bootclassloader's properties weren't internal AFAICT; both of those broke Clojure pretty heavily.

I'm not sure we can agree that the dogfooding is preferable. The penalty paid in the stdlib would have to be paid time and time again by users -- as it stands, Jigsaw is not something I can conveniently opt-in (or opt-out) -- it's very clear that the opt-out switches are temporary hacks, and even those don't make porting trivial. As someone who used to be very active in the Python community, I think the 2/3 comparison is very apt.

The problem with that is that nobody is backporting fancy compiler improvements to JDK8; I can't get my faster JDK without also buying into a module system I didn't want and also broke my code.

It is certainly not clear to me that stronger visibility restrictions are a priori desirable when they break dynamic hosted languages. Reflection as a side-stepping mechanism is already easy to detect and clearly opt-in by the reflector, and you've had the option of opting out for ages with Security Managers. All Jigsaw buys you is another level of granularity in that visibility (not just class, subclass, package) and breaking the workarounds for when you actually really mean it.

> Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?

I don't think we can unless there's an implementation proposal that takes that approach?

Certainly I think it would be impractical to make the JVM smaller without having visibility restrictions that apply even to reflective access. To be able to develop applications/library intended to run against a smaller JVM I need a way to restrict myself from using certain features even when developing on a full-sized JVM.

Reply on news.ycombinator.com