Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java SE 8 Proposed Final Draft Specification — Draft 1

cr.openjdk.java.net

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#21

Post by mhixson »

cherioo wrote: post #18
bhauer wrote: post #2

Looking forward to it! We've been experimenting with early builds and the improvements are enjoyable. My colleague's reference for developer-facing changes in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...

Reading through the post, one of the link[1] says something along the line of "Java has 'multiple inheritance' from day 1". How is this the case? [1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-March...

He qualified it with "(of types)", so I believe he was talking about inheriting from multiple interfaces. People already had to be able to deal with "this thing is both a Foo and a Bar", so perhaps it's not a huge leap to go from there to "this thing inherits implementation from Foo and Bar". And by implementation we mean methods, not state.

That's how I read it at least.

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#22

Post by SwellJoe »

kvtrew76557 wrote: post #19

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.

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?

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#23

Post by mhixson »

laureny wrote: post #20
grogenaut wrote: post #17

Earlier quoted context omitted.

Yes, Yes I do. And as for backward compatibility, they already did. I love the myth that java never broke backwards compatibility. Bytecode maybe ( ), they definitely broke syntax compatiblity. : The various xml parsers and other library thrash really do break backwards bytecode compatiblity.

> I love the myth that java never broke backwards compatibility. Bytecode maybe (), they definitely broke syntax compatiblity. Proof?

If by "syntax compatibility" he means code that compiles in one version does not compile is another, that's definitely true. Name collisions with the new default methods in Java 8 are one source. If your Comparator-implementing class has a method "void reverseOrder()", that will no longer compile.

Here's a couple of recent examples the Guava authors have fixed. Fortunately they were in internals and not their public API, so users won't care.

https://code.google.com/p/guava-libraries/source/detail?r=7d... https://code.google.com/p/guava-libraries/source/detail?r=25...

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#24

Post by krzyk »

bhauer wrote: post #2

Looking forward to it! We've been experimenting with early builds and the improvements are enjoyable. My colleague's reference for developer-facing changes in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...

Unfortunately the link you provided discusses lambdas but then after I'm hooked into them it says : "They were considered for Java 8 but were not included, for simplicity and due to time constraints."

So what's the point of describing the on a page talking about additions to Java 8?

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#25

Post by benjiweber »

krzyk wrote: post #24
bhauer wrote: post #2

Looking forward to it! We've been experimenting with early builds and the improvements are enjoyable. My colleague's reference for developer-facing changes in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...

Unfortunately the link you provided discusses lambdas but then after I'm hooked into them it says : "They were considered for Java 8 but were not included, for simplicity and due to time constraints." So what's the point of describing the on a page talking about additions to Java 8?

The author is referring to the additional lambda-related features below (Non-final variable capture, Exception transparency, Control Flow). Lambdas most certainly are included in 8.

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#26

Post by RyanZAG »

SwellJoe wrote: post #22
kvtrew76557 wrote: post #19

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.

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?

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.

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#27

Post by frowaway001 »

RyanZAG wrote: post #26
SwellJoe wrote: post #22

Earlier quoted context omitted.

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?

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 impl…

> 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.

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#28

Post by RyanZAG »

frowaway001 wrote: post #27
RyanZAG wrote: post #26

Earlier quoted context omitted.

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 impl…

> 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 read…

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.

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#29

Post by pron »

frowaway001 wrote: post #27
RyanZAG wrote: post #26

Earlier quoted context omitted.

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 impl…

> 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 read…

This is a talk by Brian Goetz about the design of Java 8's lambdas: http://parleys.com/play/5251c164e4b0a43ac1212459/about

A lot of thought has been put into that, and I think the result is both elegant and at the same time integrates beautifully with legacy code. Perhaps most importantly, a lot of existing libraries will automatically support lambdas naturally without them ever being designed for lambdas and without recompilation.

Java's lambdas have been anything but rushed. They were debated long and hard (for literally years), and different approaches were considered, tried and discarded before the present spec was accepted. Here's a summary of the discussion from 2007: http://blog.joda.org/2007/12/closures-comparing-core-of-bgga...

In the end, the "BGGA" proposal for full function types in Java was rejected in favor of something similar to the Doug Lea-Josh Bloch-Bob Lee proposal. Bob Lee summarized his perspective so[1]: "Loosely speaking, simple syntax sugar for anonymous inner classes buys Java 90% of the power of BGGA closures while carrying only 10% of the weight. We think it's the "knee in curve" where we get the most bang for our buck." This is perfectly in line with the Java philosophy. Other languages may prefer getting 100% of the power for ten times the cost, which might make sense if your requirements and use cases are different.

In the end, though, Lambda's are more powerful than the original "concise syntax for anonymous classes" because method handles are used as the bytecode-level description of lambdas, while anonymous classes are an implementation detail that can be changed later without affecting binary compatibility.

This talk by Joshua Bloch, discusses "the closures controversy" in some depth: http://parleys.com/play/514892250364bc17fc56bb15/chapter0/ab.... He explains that PL research was a declared "non-goal" for Java, which was meant to be kept simple. "Nice" features were rejected by design, with the goal of only including those that solve problems that really hurt.

P.S.

The lambda discussions predate the Oracle acquisition. Also, I wouldn't call Gilad Bracha, Joshua Bloch and Guy Steele underqualifed.

[1]: http://blog.crazybob.org/2006/10/java-closure-spectrum.html

Re: Java SE 8 Proposed Final Draft Specification — Draft 1

#30

Post by pron »

RyanZAG wrote: post #26
SwellJoe wrote: post #22

Earlier quoted context omitted.

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?

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 impl…

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/a...

* http://parleys.com/play/514892290364bc17fc56c444/chapter0/ab...

Post reply on HN