4 ms·

We can't tailor every feature to the widely disparate preferences of so many developers nor do we try to convince every last developer of the merit of our appro

by pron 2y ago

We can't tailor every feature to the widely disparate preferences of so many developers nor do we try to convince every last developer of the merit of our approach -- this is both impractical and a losing strategy. Rather, we rely on our experience designing a highly successful language and platform, and consult with companies -- each employing thousands of Java developers -- and authors of some of the most popular relevant Java libraries to ensure that we meet their requirements. Of course, we also look at what other languages have done and the tradeoffs they've accepted (some of which may not be appropriate for Java [1]), but there are always many possible designs and we don't adopt one from a less successful language just because it, too, has its fans. I would encourage those who think that we're consistently making suboptimal choices for Java compared to choices made by significantly less successful languages to consider whether it is possible that their preferences are not aligned with those of the software market at large. Java is and aims to continue being the world's most popular language for serious server software, and that requires tailoring designs to a very large audience. I always notice a certain lack of respect on forums such as HN for the world's most consistently successful and popular languages -- JS, Java, and Python. Different programmers have different preferences and I'm all for rooting for the underdog now and again, but you simply cannot consistently make wrong decisions over a very long period of time and yet consistently win. What we do may not be everyone's cup of tea (no language is), but it is clearly that of a whole lot of people. We work to offer value to them. [1]: E.g. the design of native interop has significantly impacted that of user-mode threads (or lack thereof: https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398) in both .NET and Go, and we weren't willing to make such tradeoffs in either performance or programming model.

pjmlp 2y ago
I can say that in my bubble we reach out for Java, because of Spring, AEM and Android. That is it, other use cases, have other programming stacks. As such our native libraries are written in consideration to be consumed at very least, across .NET (P/Invoke, C++/CLI, COM), Java (JNI), nodejs (C++ addons), Swift. So to move the existing development workflow from JNI to Panama, it must be an easy sell why we should budget rewrites to start with. Also in regards to "hate", if all decisions were that great there wouldn't be needed to create a new library support group to help Java ecosystem actually move forward and adopt new Java versions, as I learned from JFokus related content.
- pron 2y ago
  You shouldn't! We're not trying to "sell" any rewrite from JNI to FFM. Since FFM is both significantly easier to use and offers better performance, most people would choose to write new interop code with FFM; that is an easy sell. But that's not to say that these benefits justify a rewrite of existing code, and we have no plan to remove JNI. JNI and FFM can coexist in same program (and even in the same class). However, we are about to place the same protections on JNI as those we have on FFM to ensure that Java programs are free of undefined behaviour by default, and that modules that may introduce undefined behaviour are clearly acknowledged by the application so that the application owners may give them closer scrutiny if they wish [1]. To elaborate just a bit more on what I wrote in my previous comment, to get a straightforward interop with C you need to place certain restrictions on the runtime which limit your ability to implement certain abstractions such as moving GCs and user-mode threads. Because native interop requires special care anyway due to native memory management, which makes it significantly more complex than ordinary code and so less suitable for direct exposure to application developers -- so it's best done by experts in the area -- and on top of that native calls in Java aren't common, we decided not to sacrifice the runtime in favour of more direct interop. As a result, native interop is somewhat more elaborate to code, but as it requires some special expertise and so should be hidden away from application developers anyway, we decided it's better to place the extra burden on the experts doing the interop rather than trade off runtime capabilities and performance. We think this is the better tradeoff for Java. Consequently, we have both compacting collectors and no performance penalty for native calls on virtual threads. Other languages made whatever tradeoffs they thought were right for them, but they did very clearly sacrifice something. [1]: https://openjdk.org/jeps/472 https://openjdk.org/jeps/472
int_19h 2y ago
A "certain lack of respect" comes from having to work with these languages for literally decades, and knowing their warts (and how those warts compare to some other similarly popular languages). In general, being successful and popular had little to do with how well a PL is designed. Visual Basic, PHP, and even C are some historical examples that I have plenty of personal experience with.
- pron 2y ago
  > In general, being successful and popular had little to do with how well a PL is designed. Perhaps, but it is fairly easy to design a product for a small, self-selecting group of fans who find the aesthetics appealing and so declare the design good for their taste. Unless a language becomes heavily used in codebases that are maintained for years by a large variety of programmers, it's hard to tell how well it is actually designed as a mass-appeal product. Two of the three languages you mentioned weren't able to attain nearly the same success as Java for as long a duration. I'd give C a similar success score because what it lacks in popularity it still makes up for in longevity, being almost twice as old. There are good reasons for why C is still as popular as it is. For example, in its domain -- which requires compilation to exotic architectures -- "good design" entails being able to easily implement efficient compilers.
  - int_19h 2y ago
    Of course, when you compare languages, you have to compare them to contemporary ones that also target the same niche. In case of C, that would be e.g. Modula-2. The consequences of the industry making an expedient but wrong choice then - 45 years ago! - are still with us: C++ only just got proper modules, and even then most C++ code written today is still mostly using #include... And to be clear, I'm not advocating for aesthetics here. It's not like C# is a model of purity, either; but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage.
    - kaba0 2y ago

by pron 2y ago

pjmlp 2y ago

I can say that in my bubble we reach out for Java, because of Spring, AEM and Android. That is it, other use cases, have other programming stacks. As such our native libraries are written in consideration to be consumed at very least, across .NET (P/Invoke, C++/CLI, COM), Java (JNI), nodejs (C++ addons), Swift. So to move the existing development workflow from JNI to Panama, it must be an easy sell why we should budget rewrites to start with. Also in regards to "hate", if all decisions were that great there wouldn't be needed to create a new library support group to help Java ecosystem actually move forward and adopt new Java versions, as I learned from JFokus related content.

pron 2y ago
You shouldn't! We're not trying to "sell" any rewrite from JNI to FFM. Since FFM is both significantly easier to use and offers better performance, most people would choose to write new interop code with FFM; that is an easy sell. But that's not to say that these benefits justify a rewrite of existing code, and we have no plan to remove JNI. JNI and FFM can coexist in same program (and even in the same class). However, we are about to place the same protections on JNI as those we have on FFM to ensure that Java programs are free of undefined behaviour by default, and that modules that may introduce undefined behaviour are clearly acknowledged by the application so that the application owners may give them closer scrutiny if they wish [1]. To elaborate just a bit more on what I wrote in my previous comment, to get a straightforward interop with C you need to place certain restrictions on the runtime which limit your ability to implement certain abstractions such as moving GCs and user-mode threads. Because native interop requires special care anyway due to native memory management, which makes it significantly more complex than ordinary code and so less suitable for direct exposure to application developers -- so it's best done by experts in the area -- and on top of that native calls in Java aren't common, we decided not to sacrifice the runtime in favour of more direct interop. As a result, native interop is somewhat more elaborate to code, but as it requires some special expertise and so should be hidden away from application developers anyway, we decided it's better to place the extra burden on the experts doing the interop rather than trade off runtime capabilities and performance. We think this is the better tradeoff for Java. Consequently, we have both compacting collectors and no performance penalty for native calls on virtual threads. Other languages made whatever tradeoffs they thought were right for them, but they did very clearly sacrifice something. [1]: https://openjdk.org/jeps/472 https://openjdk.org/jeps/472

int_19h 2y ago

A "certain lack of respect" comes from having to work with these languages for literally decades, and knowing their warts (and how those warts compare to some other similarly popular languages). In general, being successful and popular had little to do with how well a PL is designed. Visual Basic, PHP, and even C are some historical examples that I have plenty of personal experience with.

pron 2y ago
> In general, being successful and popular had little to do with how well a PL is designed. Perhaps, but it is fairly easy to design a product for a small, self-selecting group of fans who find the aesthetics appealing and so declare the design good for their taste. Unless a language becomes heavily used in codebases that are maintained for years by a large variety of programmers, it's hard to tell how well it is actually designed as a mass-appeal product. Two of the three languages you mentioned weren't able to attain nearly the same success as Java for as long a duration. I'd give C a similar success score because what it lacks in popularity it still makes up for in longevity, being almost twice as old. There are good reasons for why C is still as popular as it is. For example, in its domain -- which requires compilation to exotic architectures -- "good design" entails being able to easily implement efficient compilers.
- int_19h 2y ago
  Of course, when you compare languages, you have to compare them to contemporary ones that also target the same niche. In case of C, that would be e.g. Modula-2. The consequences of the industry making an expedient but wrong choice then - 45 years ago! - are still with us: C++ only just got proper modules, and even then most C++ code written today is still mostly using #include... And to be clear, I'm not advocating for aesthetics here. It's not like C# is a model of purity, either; but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage.
  - kaba0 2y ago