This is incredibly useful when you pair it with RPC and a shared domain model.
In Java, one creates a 55 lines getter-setter class with concurrency bugs and accidental mutation risks, and maybe plus a 55 lines Builder too.
Whilst in Scala I create a 5 lines case class, immutable and thread safe, all that's needed.
I don't want to bother with extra layers or be bound to JetBrains tooling.
Longterm, languages that own platforms are always a safer bet.
They only go away when the platform dies, while guest languages come and go.
And best of all, you don't need to wait for supporting platform features, having additional idiomatic wrappers, more IDE plugins, debugging support, build tools, etc.
Twitter still uses it heavily.
I recently watched a few Scala Days 2019 videos:
https://www.youtube.com/channel/UCOHg8YCiyMVRRxb3mJT_0Mg
It seems to have a healthy community. 3.0 comes out next year.
If you want a functional gateway drug, Scala appears to be the answer:
Java 8 took a lot of the wind out of Scala's sails not by being better, but by showing enough improvement that the benefits of learning Scala looked less attractive than before.
Generally the JPMS provide two benefits:
1. Since the JRE is restructured to use modules, it can be used piecemeal, which is great for embedded systems.
2. A module controls exposed packages -- only explicitly exported packages are accessible to dependent modules.
With this in mind it's difficult to justify the JPMS fallout: Why should #1 impact the much larger market of Java SE? #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA, which provide robust compile-time module systems. And the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that), so what is it providing exactly? Surely it doesn't fix the notorious "JAR hell" issue, you still need to shade jars or use OSGi.
This hardly sounds like a standardized feature.
> and the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that)
That is not true, access control is enforced both at compile time and at runtime.
> so what is it providing exactly?
Copied from the the Jigsaw requirements:
* Reliable configuration, to replace the brittle, error-prone class-path mechanism with a means for program components to declare explicit dependences upon one another;
* Strong encapsulation, to allow a component to declare which of its APIs are accessible by other components, and which are not;
* A scalable Java SE Platform, whose components can be assembled by developers into custom configurations that contain only the functionality actually required by an application;
* Greater platform integrity, to ensure that code that is internal to a platform implementation is not accessible from outside the implementation; and
* Improved performance, by applying whole-program optimization techniques to complete configurations of platform, library, and application components.
IDE module systems reflect the standard module system used by standard build tooling such as Maven and Gradle.
> That is not true, access control is enforced both at compile time and at runtime.
Right... As I stated: the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that). The compile-time module system already in place (maven/gradle) is already supported with IDEs.
> Jigsaw requirements
Reread my original comment.
