6 ms·

I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes. Still props for the Java team for doing a good

I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes. Still props for the Java team for doing a good job.

pron 4y ago
Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", languages have, but rather to selectively pick the fewest features that would have the biggest impact. That's the aspiration, at least.
- taftster 4y ago
  And honestly, in my opinion, that approach is just really proving itself right now. I am so happy to see Java seemingly on the right path again, adopting solid capabilities, innovating, but letting other languages take some punches first. We have had some dark days (maybe a dark decade), but full steam ahead now. Thank you pron and team!
  - zelphirkalt 4y ago
    It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.
    - pron 4y ago
      Java innovates a lot in the runtime, where it's ahead of virtually all other languages in its combination of performance and observability. But the language very much tries to be conservative and not to innovate (compared to others, that is) for the simple reason that the vast majority of programmers prefer it that way, and Java is a mass-market language. The language itself is not supposed to excite or to challenge but to inspire confidence that you can build a 100KLOC-10MLOC piece of software in it and your investment would be safe 10, 15, 20 years from now. This strategy has worked really well for Java, and it's worked really well for those who choose Java. Those companies who 10, 15, 20 years ago picked more exciting languages like PHP and Ruby are generally not as happy with their choices now as those who picked Java. We fully understand that a minority of developers want more feature-rich, adventurous languages, and we're happy that the platform offers them such choices.
      - TheCycoONE 4y ago
        Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that must be frustrating as a language researcher with that goal.
        pron 4y ago
        Oracle's "license change" was to open source the entire JDK for the first time in Java's history (although many people tried to make sure this was misunderstood, which wasn't helped by Oracle's poor communication -- now that's frustrating), and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. Even Oracle only uses the java/javax namespaces for JCP APIs. They claimed it was too inefficient, but Java SE churns out two specification versions a year through the JCP, despite them being bigger and more complex than Jakarta EE.
        cesarb 4y ago
        > Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/ https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments. > and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer https://github.com/eclipse/transformer).
    - kaba0 4y ago
      Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost every problem thrown at me. I would much rather take a “boring” language with an absolutely huge ecosystem and just get my work done. Especially that after going high-level/managed, there is no feature that would give any significant productivity boost (as per Brooks).
      - sirsinsalot 4y ago
        It isn't often I see Java described as simple.
        kaba0 4y ago
        It has quite a few keywords, you have primitives and objects and you call methods on those. Compare it to C#, Swift or C++, and it is insanely tiny compared to those.
        zelphirkalt 4y ago
        https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k... lists 50 keywords for Java. https://en.cppreference.com/w/cpp/keyword https://en.cppreference.com/w/cpp/keyword lists 97 keywords for C++. https://realpython.com/python-keywords/ https://realpython.com/python-keywords/ lists 35 keywords for Python 3.8. https://en.wikipedia.org/wiki/Smalltalk#Syntax https://en.wikipedia.org/wiki/Smalltalk#Syntax lists 6 keywords for Smalltalk. Neither one of them I would consider small or simple, but you are correct, that Java has much fewer than C++ and I would definitely agree, that it is the simpler language.
        sirsinsalot 4y ago
        Simpler syntax != simpler semantics. Also syntactic sugar can simplify language comprehension but adds tokens. Keywords is a poor metric for complexity in any sense other than choice of keywords. That IMHO doesn't make a language complex in any meaningful way engineering wise.
- rileyphone 4y ago
  Do you have a link for the 1997 document? The history is surprisingly difficult to explore for being pretty recent.
  - pron 4y ago
    Here's a public 1997 document where much of that is said: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java...
    - rileyphone 4y ago
      Thanks!
- oblio 4y ago
  Yeah, you're mostly right, but then... generics.
  - MBCook 4y ago
    I think it’s being worked on and they have an idea/solution. But Java lives and dies by backwards compatibility so they have to be very careful about it.
- The_Colonel 4y ago
  Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).
  - deleted 4y ago
    [deleted]
  - kaba0 4y ago
    Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
    - lenkite 4y ago
      Pity that the Streams functions don't support checked exceptions.
      - Quekid5 4y ago
        It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrapped IOException via a simple "catch (IOException e) { ... }"... it instead has to catch whatever you wrapped that exception in... and manually look inside that Throwable's suppressedExceptions list. And so you end up with stuff like Guava's Throwables utility methods. Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... If they had a more powerful type system something usable might be possible, but as of Java right now, it just hopelessly broken. I'd suggest that a fix to the langauge would be to simply change all exceptions to unchecked, but unfortunately that might break a lot of code where the above workaround has already been implemented once consumed libraries switch away from wrapping. (Note that it's only Java-the-language which has checked exceptions. The JVM doesn't and Scala/Kotlin are much the better for it.) EDIT: The JVM is a marvel of engineering. Java... not so much.
- avgcorrection 4y ago
  Thanks for choosing only tried and proven tech like pervasive nullable pointers.

I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes. Still props for the Java team for doing a good job.

pron 4y ago

Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", languages have, but rather to selectively pick the fewest features that would have the biggest impact. That's the aspiration, at least.

taftster 4y ago
And honestly, in my opinion, that approach is just really proving itself right now. I am so happy to see Java seemingly on the right path again, adopting solid capabilities, innovating, but letting other languages take some punches first. We have had some dark days (maybe a dark decade), but full steam ahead now. Thank you pron and team!
- zelphirkalt 4y ago
  It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.
  - pron 4y ago
    Java innovates a lot in the runtime, where it's ahead of virtually all other languages in its combination of performance and observability. But the language very much tries to be conservative and not to innovate (compared to others, that is) for the simple reason that the vast majority of programmers prefer it that way, and Java is a mass-market language. The language itself is not supposed to excite or to challenge but to inspire confidence that you can build a 100KLOC-10MLOC piece of software in it and your investment would be safe 10, 15, 20 years from now. This strategy has worked really well for Java, and it's worked really well for those who choose Java. Those companies who 10, 15, 20 years ago picked more exciting languages like PHP and Ruby are generally not as happy with their choices now as those who picked Java. We fully understand that a minority of developers want more feature-rich, adventurous languages, and we're happy that the platform offers them such choices.
    - TheCycoONE 4y ago
      Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that must be frustrating as a language researcher with that goal.
      - pron 4y ago
        Oracle's "license change" was to open source the entire JDK for the first time in Java's history (although many people tried to make sure this was misunderstood, which wasn't helped by Oracle's poor communication -- now that's frustrating), and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. Even Oracle only uses the java/javax namespaces for JCP APIs. They claimed it was too inefficient, but Java SE churns out two specification versions a year through the JCP, despite them being bigger and more complex than Jakarta EE.
        cesarb 4y ago
        > Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/ https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments. > and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer https://github.com/eclipse/transformer).
  - kaba0 4y ago
    Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost every problem thrown at me. I would much rather take a “boring” language with an absolutely huge ecosystem and just get my work done. Especially that after going high-level/managed, there is no feature that would give any significant productivity boost (as per Brooks).
    - sirsinsalot 4y ago
      It isn't often I see Java described as simple.
      - kaba0 4y ago
        It has quite a few keywords, you have primitives and objects and you call methods on those. Compare it to C#, Swift or C++, and it is insanely tiny compared to those.
        zelphirkalt 4y ago
        https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k... lists 50 keywords for Java. https://en.cppreference.com/w/cpp/keyword https://en.cppreference.com/w/cpp/keyword lists 97 keywords for C++. https://realpython.com/python-keywords/ https://realpython.com/python-keywords/ lists 35 keywords for Python 3.8. https://en.wikipedia.org/wiki/Smalltalk#Syntax https://en.wikipedia.org/wiki/Smalltalk#Syntax lists 6 keywords for Smalltalk. Neither one of them I would consider small or simple, but you are correct, that Java has much fewer than C++ and I would definitely agree, that it is the simpler language.
        sirsinsalot 4y ago
        Simpler syntax != simpler semantics. Also syntactic sugar can simplify language comprehension but adds tokens. Keywords is a poor metric for complexity in any sense other than choice of keywords. That IMHO doesn't make a language complex in any meaningful way engineering wise.
rileyphone 4y ago
Do you have a link for the 1997 document? The history is surprisingly difficult to explore for being pretty recent.
- pron 4y ago
  Here's a public 1997 document where much of that is said: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java...
  - rileyphone 4y ago
    Thanks!
oblio 4y ago
Yeah, you're mostly right, but then... generics.
- MBCook 4y ago
  I think it’s being worked on and they have an idea/solution. But Java lives and dies by backwards compatibility so they have to be very careful about it.
The_Colonel 4y ago
Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).
- deleted 4y ago
  [deleted]
- kaba0 4y ago
  Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
  - lenkite 4y ago
    Pity that the Streams functions don't support checked exceptions.
    - Quekid5 4y ago
      It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrapped IOException via a simple "catch (IOException e) { ... }"... it instead has to catch whatever you wrapped that exception in... and manually look inside that Throwable's suppressedExceptions list. And so you end up with stuff like Guava's Throwables utility methods. Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... If they had a more powerful type system something usable might be possible, but as of Java right now, it just hopelessly broken. I'd suggest that a fix to the langauge would be to simply change all exceptions to unchecked, but unfortunately that might break a lot of code where the above workaround has already been implemented once consumed libraries switch away from wrapping. (Note that it's only Java-the-language which has checked exceptions. The JVM doesn't and Scala/Kotlin are much the better for it.) EDIT: The JVM is a marvel of engineering. Java... not so much.
avgcorrection 4y ago
Thanks for choosing only tried and proven tech like pervasive nullable pointers.