As a java dev, I'm not sure Jigsaw helps in any way. Tooling has pretty much solved the classpath management issue. What would've been awesome is if modules were version aware, and code was allowed to depend on different versions of the same module, but that's not the case.
Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.
The main problem with deprecating internals is the slow cycle of Java. They first released every year, then every two years, and now every three years, and the pace seems to be slowing down further. If they still made a new release every year, they could mark something deprecated in one release and then refactor it the next. But given that they spend years between releases they don't have that luxury. This is the age-old problem of going long between releases because it's hard to release, because you go long between releases, because...
I say this in all seriousness: java should emulate PHP. The current development model of PHP produces a stable product that optimizes for the needs of the user community, ships a major release once a year and welcomes outside contribution.
Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools. I'm getting sick of the multiple version dependency problem being brought up over and over again. That's one of the reason why OSGI is not widely adopted. You should watch some of the talks delivered by the jigsaw team.
> Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools.
Then why do we need Jigsaw at all? If the assumption is that you run Maven or Gradle anyway then what is left for Jigsaw to do? The dependency management and check will happen by those tools.
> the versioning problems should be solved by those tools
I'm not a Java developer; could you explain a bit about how Maven/Gradle solve this problem? My understanding is that what people want is something like what Node gives you—the ability to have both libfoo-1.0 and libfoo-1.1 loaded into the same VM at the same time without clashing. Do the build tools use e.g. name-mangling to achieve this?
A lot of the problems in the API land can be attributed to what I call the sandbox skills, or rather lack thereof. Those are skills that we were supposed to learn when we were kids and played in sandboxes. Things like how to share stuff, how much to share, how not to be too selfish and not sharing enough, etc. You get the idea :)
In Java, private/protected functions/fields are mostly only a compile time check. Your code will not compile with if they shouldn't be able to see the function/field. But java also has a runtime inspection framework that allows you to view and call these scope hidden functions/fields in contexts that should not be allowed. You do have to ask nicely though with an extra call to request access. This is heavily used in things like Json/XML parsers and ORM tools. Really anyplace you need to blindly reconstruct an object programmatically.
> In Java, private/protected functions/fields are mostly only a compile time check.
Indeed, with reflection you can mutate member properties... I taught myself [this trick](https://stackoverflow.com/questions/10638826/java-reflection...) right away. You can also disable reflection via security policy, which would forbid that access with an exception.
Spring, Jackson, and other libraries that perform various "magical" feats around DI and serialization make heavy use of reflection to inspect private fields. Generally though they don't require write access to those fields (Spring possibly being the exception), but do generally require at least read access. Would be nice if there was a system to flag certain classes or jars as OK to violate access restrictions while still preventing others.
If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line).
If the classes are enclosed inside a module, it's simpler, either you declare the package as open or the whole module as open.
(when you declare a package open you also can specify the module for which it will be 'open', by example, open com.foo.mylib to org.jackson.core)
> If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line).
AFAIK "classpath-mode" is not affected by Jigsaw. All of classpath is one big module so "anything goes". As long as all of your code is on the classpath or a custom class loader created from the classpath anything should continue to work with 9 and even in 10. Things only start to break if you:
- reflect on JDK internals
- you put your code or frameworks or libraries in the modulepath
Having not really looked into the Java 9 features much yet can you expand on that last point? It sounds like that's more or less what I'm looking for though. Is it possible to declare a package to be open to multiple modules? I.E. could I do something like:
open com.foo.mylib to com.fasterxml.jackson.core
open com.foo.mylib to org.springframework.core
All voted YES, only one abstained. Now remember suspictions:
"Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI?"...
I think that's obvious, but I caught a hint of an implication that "commercial interests" are bad.
Both companies contribute to the OSS community in a refreshing way: they grow the Java economy by healthy competition, rather than using it to shut out competitors.
Not "bad" per-se, but perhaps in the interest of progress not accepting a path forward could be considered a hindrance to open-source ideologies.
It's not quite a fair judgement, because as you say, Red Hat has done more as a collective for FOSS than many of us will do in our lifetimes. It's not very black and white.
If that were the case, it could be that the attention from suspicious people made them think better of voting against this time. (I don't think it is, but I don't think this vote proves as much as you think)
"On 2017-06-23 Red Hat voted Abstain with the following comment:
Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30 day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK.
We would also like to take the opportunity to thank the EG, the Oracle Specification Lead and others who assisted in the numerous meetings which have taken place in the last 30 days. This increased collaboration and positive approaches to discussing and resolving issues has been welcomed by ourselves and the wider Java community."
This is a major step forward (recall that the May 8 vote was not approved). Though there is another vote (Final Approval Ballot), it appears that JDK 9 is on track for September 2017 release.
Redhat abstained instead of saying No. Few weeks back they dumped their home grown Ceylon language on to Eclipse foundation. Seems like they are going to stick with Java even if unwillingly.
A few years ago, all the hip kids were making JVM languages that were "Better" and "More Productive". Ceylon was just a few Redhat employees attempt at chasing market trends.
Kotlin was designed from the ground up to work seamlessly with IDE IntelliJ (and hence Android Studio), whereas Ceylon joining the Eclipse Foundation was just an afterthought and its Eclipse IDE integration isn't guaranteed to be great.
Well, I don't know about better, Ceylon is just a different approach. There are some things Ceylon does that I like better than Kotlin, and vice versa. Both are certainly better than Java though.
Ceylon has two things that Kotlin should have IMO, a better type system, where are my union types and intersection types ? :) and a real specification.
I notice the name of Ceylon has changed to Eclipse Ceylon [1], in the same way Groovy became Apache Groovy when it joined the Apache foundation 2 years ago.
"The specification of the module system’s resolution algorithm, in the java.lang.module package, was rewritten in order to clarify the definition of readability and the means by which dependences are resolved at compile time."
The problem was not Jigsaw breaking Maven, it was more Jigsaw breaking Maven Central by allowing anyone to name a downloaded module/jar to whatever he wants (like npm before version 3)
JVM developer her (Java and more recently Kotlin). In an era where microservices are becoming increasingly popular I think this change is unnecessary. This was needed back when Java 6/7 was king and people were still investing heavily in monolithic architectures.
I am really not convinced this does anything besides make Java development more painful for those of us who are building small self-contained services with limited scope and library dependencies.
On the positive side this looks like a road forward for minimizing the size of a JRE in a world with AOT compilation. It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable. I've only been loosely following but it looks like the jlink and jaotc tools shipping with JDK9 may make that possible.
Just the opposite, faster startup time and lower memory footprint for the JVM via modules would be great. Both via process start, storage read, container image transfer. It'd also be a boon to JVM based dynamic languages by extension.
Albeit if you're layering images the cost could balance out over time in deployment. The runtime density would be increased overall with modules though.
> It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable.
This is where go wins over JVM hosted languages, it'd be nice to bring JVM into new domains.
> Just the opposite, faster startup time and lower memory footprint for the JVM via modules would be great.
Why would modules lead to faster startup time and lower memory footprint? Java class loading has always been lazy, if you do not need a class it will not be loaded. If anything modules should increase startup time because additional runtime checks needs to be performed and increase memory footprint since additional metadata needs to be referenced. Modules do not affect memory layout of Java objects.
With AOT compilation, you are not minimizing the size of the JRE. The Java bytecode is more compact than any assembly code because it is more high level.
So with jlink, you are reducing the size of the JDK by creating your own JDK and with jaotc, you are augmenting the size of the JDK but have a faster startup (not sure) or at least less jitter (no JIT) (sorry for the pun).
I think you're in agreement with meddlepal. The idea is that if you want to do AOT, it would be nice to be able to minimize how much of the JRE you need to link in (via help from the module system).
It's been a while, so I'm not up on the latest Jigsaw details. A while back I was working on building traditional Java (Spring MVC/Spring/Hibernate) web applications using OSGi. At the time, I hit some non-trivial challenges with any library that used a class discovery mechanisms that assumed a flat classpath. Jigsaw is purported to be simpler, so hopefully it's not a big issue, but when our team starts using Java 9, that'll be one of the big risks I'll be looking for.
At the same time, I am excited that many issues with transitive dependency resolution will be easier, and it will be easier to enforce code architecture principles (i.e., not just calling whatever code from whatever place just because it's on the classpath already).
Java dev here. Modules are great, they provide encapsulation on a higher level: can encapsulate classes, interfaces, etc. behind a well defined module interface. They help reducing object-oriented spaghetti code.
Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.