4 ms·

> but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen That’s not true at all. Besides the package name change w

by kaba0 2y ago

> but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen That’s not true at all. Besides the package name change with jakarta, all it did is just expose a couple, popular libraries that were depending on runtime internals. Most of this could be fixed by bumping said libraries version. And the whole point of the module system is that it will never happen again, due to stricter encapsulation. > Project Loom How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. And yeah, java has always been “conservative on the language front, state-of-the-art on the runtime”

cesarb 2y ago
> How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. You often have no control over what kind of thread the caller of your code is using. Code written for the old threading model can and will end up being called by these newfangled virtual threads. If it does something the virtual threads don't like (which, as far as I have heard, includes things like some uses of synchronized blocks), you can have unexpected breakage.
- imtringued 2y ago
  You're confusing the thread pinning problem with "breakage". The problem with some synchronized blocks is that they lead to thread pinning for the duration of the lock. Why is thread pinning bad? Because it means that if one core is idle, but all the threads are pinned to a specific core, you won't get full CPU utilisation. This undermines the performance benefit of virtual threads, because they are supposed to be schedulable via work stealing.
- kaba0 2y ago
  That’s not backwards compatibility, but forwards compatibility, though. And you would really have to go out of your way to introduce such an issue. Certain extreme (e.g. native calls) cases are handled by simply pinning a virtual thread to a real thread. So it would only cause an issue if it was already causing an issue at much smaller thread numbers. And many of these extreme cases are getting “solved” to not pin the thread.
whartung 2y ago
JDK 9 was the impetus, but the real nail was, I think, 17 when a lot of the constraints imposed by the module system became required. Before that folks could pretty much continue as usual with little regard to the module system. After 17, legacy systems needed to start adding runtime options to work correctly. And, as I recall, this was mostly constrained to the dynamic, reflective, and introspective properties. Generic jars and code can still run without the module system. Unfortunately, a lot of the magic in modern Java is through those reflection aspects. So it made moving to 17+ an effort for many legacy code bases. And it should be clear, in general, all of the code was fine. It was all runtime options setting up package permissions that was the problem. Doesn’t make it less frustrating. (And I’m pretty sure 17 was the rubicon for this, but it may have been another version.)
thayne 2y ago
> That’s not true at all. Besides the package name change with jakarta, all it did is just expose a couple, popular libraries that were depending on runtime internals. Most of this could be fixed by bumping said libraries version. I don't remember the exact details, but I worked on a project that was stuck on java 8 for a long time because some critical dependencies broke in java 9, and it took a long time before they released versions that were compatible with java 9.

by kaba0 2y ago

cesarb 2y ago

> How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. You often have no control over what kind of thread the caller of your code is using. Code written for the old threading model can and will end up being called by these newfangled virtual threads. If it does something the virtual threads don't like (which, as far as I have heard, includes things like some uses of synchronized blocks), you can have unexpected breakage.

imtringued 2y ago
You're confusing the thread pinning problem with "breakage". The problem with some synchronized blocks is that they lead to thread pinning for the duration of the lock. Why is thread pinning bad? Because it means that if one core is idle, but all the threads are pinned to a specific core, you won't get full CPU utilisation. This undermines the performance benefit of virtual threads, because they are supposed to be schedulable via work stealing.
kaba0 2y ago
That’s not backwards compatibility, but forwards compatibility, though. And you would really have to go out of your way to introduce such an issue. Certain extreme (e.g. native calls) cases are handled by simply pinning a virtual thread to a real thread. So it would only cause an issue if it was already causing an issue at much smaller thread numbers. And many of these extreme cases are getting “solved” to not pin the thread.

whartung 2y ago

JDK 9 was the impetus, but the real nail was, I think, 17 when a lot of the constraints imposed by the module system became required. Before that folks could pretty much continue as usual with little regard to the module system. After 17, legacy systems needed to start adding runtime options to work correctly. And, as I recall, this was mostly constrained to the dynamic, reflective, and introspective properties. Generic jars and code can still run without the module system. Unfortunately, a lot of the magic in modern Java is through those reflection aspects. So it made moving to 17+ an effort for many legacy code bases. And it should be clear, in general, all of the code was fine. It was all runtime options setting up package permissions that was the problem. Doesn’t make it less frustrating. (And I’m pretty sure 17 was the rubicon for this, but it may have been another version.)

thayne 2y ago

> That’s not true at all. Besides the package name change with jakarta, all it did is just expose a couple, popular libraries that were depending on runtime internals. Most of this could be fixed by bumping said libraries version. I don't remember the exact details, but I worked on a project that was stuck on java 8 for a long time because some critical dependencies broke in java 9, and it took a long time before they released versions that were compatible with java 9.