
Scala on Track to Support Java 9 Module System - AheadOfTime295
https://github.com/scala/scala-dev/issues/529
======
joneholland
Not a lot of progress in the last year.

~~~
pjmlp
The hype is gone, now there are other languages on the spotlight.

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.

~~~
joneholland
We are a scala shop as well, but more and more things are being built in
Kotlin. I love scala but the lack of a future is downhearting.

~~~
threeseed
Not sure how anyone can say Scala has no future when Scala 3 is around the
corner:

[https://medium.com/@sinisalouc/whats-new-in-
scala-3-28d9c11e...](https://medium.com/@sinisalouc/whats-new-in-
scala-3-28d9c11eec30)

~~~
StreamBright
I am not that much interested in what versioning scheme a language used and
very curious about what is new in Scala that makes it a more attractive
platform tomorrow than it is today.

I just read that post and so far there is nothing really that interesting.
Maybe it is just me.

------
mckinney
The JPMS represents what is probably the largest single change in Java's
history. It significantly impacts the entire stack: language, libraries, and
runtime/VM. In my experience the host of incompatibilities resulting from
modules are not worth the trouble -- there's not much to gain from using them.

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.

~~~
kasperni
> #2 is nice, however we already have this feature with IDEs like IntelliJ
> IDEA

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.

~~~
mckinney
> This hardly sounds like a standardized feature.

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.

------
jxi
Besides Spark, is there still a niche that Scala fills? Why wouldn’t you just
use Kotlin or Java 11? I guess I should ask the inverse question too: why
wouldn’t you just use Scala for everything?

~~~
mruts
Scala is significantly more powerful than both Kotlin or Java 11. Why would
you want to use either instead of Scala?

~~~
mckinney
Quite a lot of shops choose not to use Scala _because_ of the power. For
instance, I can easily write Haskell-like code with Scala and build DSLs
galore, which for me is great. But what happens when you need to hire more
developers? That's the rub.

~~~
mruts
You probably are better off not hiring those developers, then.

