13 ms·

Still quite far behind what is provided by C# and Scala, among others. At least it's a step in the right direction. These are the first major language changes t

Still quite far behind what is provided by C# and Scala, among others. At least it's a step in the right direction. These are the first major language changes to Java in nearly a decade, say what you like about Oracle, but at least they have the funds to develop Java whereas Sun was running on empty.

SwellJoe 13y ago
And, yet, one of the languages you've mentioned (Scala), and many other languages that have moved faster than Java (most of the ones in common usage today, in fact) have far smaller budgets than even Sun was able to throw at Java. Does it really take such a large budget to improve Java? Why does it take so much larger a budget than, say, Go or Haskell or Python or Scala?
- RyanZAG 13y ago
  Java is very heavily set on backwards compatibility - no new feature is allowed to affect existing code and any new features must fit into the existing features. This is different to Python for example where they had backwards incompatible changes in v3. Another issue is the depth of the process on each change: there are a number of discussions on each feature with multiple proposals to determine the best way to implement any feature and how it will fit in, etc. The number of companies and people involved in the feature design and implementation in each change is generally an order of magnitude greater than those other languages. Comes down to heavy bureaucracy and design by committee creating a very long process - but the end result is generally extremely well thought through and tested, so I'm personally not complaining since I'm not footing the bill.
  - frowaway001 13y ago
    > but the end result is generally extremely well thought through and tested Have you looked at the API of function types? If we needed a definition of incoherent, overcomplicated, painfully stupid non-sense, this would be it. I'd say the issue with Oracle's style of development is that it is primarily time-driven which just doesn't work for evolving languages. Features are not developed and shipped when they are ready. Instead, they decide that they want to ship X in the upcoming version Y and sacrifice the quality to reach the dead-line. Of course, stuff is ugly and inconsistent if it has been rushed all the time. That the persons involved in designing those features are completely under-qualified doesn't help either.
    - RyanZAG 13y ago
      Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true.
      - frowaway001 13y ago
        > Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/package-summary.html http://download.java.net/jdk8/docs/api/java/util/function/pa... The amount of times they managed to back themselves into a corner is just horrifying. > Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true. And to Java 9. Any actual improvement would assume that a considerable amount of people would have kept working on those things in the meantime. First delaying the feature and then reallocating the people to extinguish fires somewhere else (security, applets, ...) doesn't help. Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway. Let's at least hope that they documented the experience they gained, so that they don't repeat all the mistakes again.
        pron 13y ago
        > I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/pa.. http://download.java.net/jdk8/docs/api/java/util/function/pa.... I'm not sure you understand what you're looking at. Defining a "function type" in Java 8 looks like this: interface MyFunctionType { double f(String x, Runnable y, int z); } That package merely defines some common types. They are all interchangeable, by the way, so if your method takes a parameter of type "YourFunctionType", defined so: interface MyFunctionType { double foo(String a, Runnable b, int c); } Then the same lambda expression could represent both MyFunctionType and YourFunctionType. You don't need to use the types defined in that package, you don't need to remember what they're called etc. > Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway. I'm not sure how much is "lost", but most Java users specifically said, in this case and in others, that they prefer postponing a feature until its been done "right" after die consideration. And when a language is used by millions of developers and with trillions lines of existing code, there is a lot to consider, because a lot is at stake.
  - pron 13y ago
    I think that while backwards compatibility has always been a very important concern of Java's (as it should for such a popular language), this is also a matter of philosophy. Java's maintainers know that every feature comes at a price (of complicating the language), so the first consideration is always whether the feature provides enough benefit to justify its cost. The second consideration is whether the feature conforms with Java's "spirit" as a "blue-collar" language, designed for use on multi-MLOC projects, possibly worked on by hundreds of developers. Such a language has different requirements and a different "feel" from languages designed for quick development and comparatively small teams. Obviously, at this stage Java has accumulated quite a lot of baggage, as could be expected from such a mature and ubiquitous language. Some of these issues are addressed in Java 8, and some by other JVM languages with various degrees of adherence to the Java philosophy. I would strongly recommend watching these two talks by Joshua Bloch, where he explains Java's goals, philosophy and design. These goals were later adopted by Google for their own new languages, Dart and Go, that have the same "Java feel": * http://parleys.com/play/514892250364bc17fc56bb15/chapter11/about http://parleys.com/play/514892250364bc17fc56bb15/chapter11/a... * http://parleys.com/play/514892290364bc17fc56c444/chapter0/about http://parleys.com/play/514892290364bc17fc56c444/chapter0/ab...

SwellJoe 13y ago

And, yet, one of the languages you've mentioned (Scala), and many other languages that have moved faster than Java (most of the ones in common usage today, in fact) have far smaller budgets than even Sun was able to throw at Java. Does it really take such a large budget to improve Java? Why does it take so much larger a budget than, say, Go or Haskell or Python or Scala?

RyanZAG 13y ago
Java is very heavily set on backwards compatibility - no new feature is allowed to affect existing code and any new features must fit into the existing features. This is different to Python for example where they had backwards incompatible changes in v3. Another issue is the depth of the process on each change: there are a number of discussions on each feature with multiple proposals to determine the best way to implement any feature and how it will fit in, etc. The number of companies and people involved in the feature design and implementation in each change is generally an order of magnitude greater than those other languages. Comes down to heavy bureaucracy and design by committee creating a very long process - but the end result is generally extremely well thought through and tested, so I'm personally not complaining since I'm not footing the bill.
- frowaway001 13y ago
  > but the end result is generally extremely well thought through and tested Have you looked at the API of function types? If we needed a definition of incoherent, overcomplicated, painfully stupid non-sense, this would be it. I'd say the issue with Oracle's style of development is that it is primarily time-driven which just doesn't work for evolving languages. Features are not developed and shipped when they are ready. Instead, they decide that they want to ship X in the upcoming version Y and sacrifice the quality to reach the dead-line. Of course, stuff is ugly and inconsistent if it has been rushed all the time. That the persons involved in designing those features are completely under-qualified doesn't help either.
  - RyanZAG 13y ago
    Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true.
    - frowaway001 13y ago
      > Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/package-summary.html http://download.java.net/jdk8/docs/api/java/util/function/pa... The amount of times they managed to back themselves into a corner is just horrifying. > Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true. And to Java 9. Any actual improvement would assume that a considerable amount of people would have kept working on those things in the meantime. First delaying the feature and then reallocating the people to extinguish fires somewhere else (security, applets, ...) doesn't help. Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway. Let's at least hope that they documented the experience they gained, so that they don't repeat all the mistakes again.
      - pron 13y ago
        > I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/pa.. http://download.java.net/jdk8/docs/api/java/util/function/pa.... I'm not sure you understand what you're looking at. Defining a "function type" in Java 8 looks like this: interface MyFunctionType { double f(String x, Runnable y, int z); } That package merely defines some common types. They are all interchangeable, by the way, so if your method takes a parameter of type "YourFunctionType", defined so: interface MyFunctionType { double foo(String a, Runnable b, int c); } Then the same lambda expression could represent both MyFunctionType and YourFunctionType. You don't need to use the types defined in that package, you don't need to remember what they're called etc. > Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway. I'm not sure how much is "lost", but most Java users specifically said, in this case and in others, that they prefer postponing a feature until its been done "right" after die consideration. And when a language is used by millions of developers and with trillions lines of existing code, there is a lot to consider, because a lot is at stake.
- pron 13y ago
  I think that while backwards compatibility has always been a very important concern of Java's (as it should for such a popular language), this is also a matter of philosophy. Java's maintainers know that every feature comes at a price (of complicating the language), so the first consideration is always whether the feature provides enough benefit to justify its cost. The second consideration is whether the feature conforms with Java's "spirit" as a "blue-collar" language, designed for use on multi-MLOC projects, possibly worked on by hundreds of developers. Such a language has different requirements and a different "feel" from languages designed for quick development and comparatively small teams. Obviously, at this stage Java has accumulated quite a lot of baggage, as could be expected from such a mature and ubiquitous language. Some of these issues are addressed in Java 8, and some by other JVM languages with various degrees of adherence to the Java philosophy. I would strongly recommend watching these two talks by Joshua Bloch, where he explains Java's goals, philosophy and design. These goals were later adopted by Google for their own new languages, Dart and Go, that have the same "Java feel": * http://parleys.com/play/514892250364bc17fc56bb15/chapter11/about http://parleys.com/play/514892250364bc17fc56bb15/chapter11/a... * http://parleys.com/play/514892290364bc17fc56c444/chapter0/about http://parleys.com/play/514892290364bc17fc56c444/chapter0/ab...