Closures in Java 7: Not Likely

http://www.davidflanagan.com/2010/05/closures-in-jav.html

by fogus • 16 years ago

30 21 16 years ago

Daishiman• 16 years ago

That's Oracle for you. In the end the only way for the JVM environment to advance would be if large users of the JVM push for new features until the FOSS community forks and begins patching up.

Zarkonnen2• 16 years ago

Speaking as someone whose current long-term main project is Java-based: Java's development has stalled. Go and learn Scala, Clojure, Python, Haskell, <brand x>. (Note that is not to say that you need to abandon whatever Java you're working on, just that Java's pain points getting fixed looks very unlikely.)

jacquesm3• 16 years ago

Working on it. But it's the steepest learning curve since I learned to program the first time.

It almost feels as though already being able to program is actually a hindrance.

frisco• 16 years ago

Which? Scala, Clojure, Haskell ...?

JoshCole• 16 years ago

I've had the learning curve problem as well. So far the resource which has most helped ease the curve is http://clojure-notes.rubylearning.org/. If you have/find anything better let me know.

ivenkys• 16 years ago

"It almost feels as though already being able to program is actually a hindrance."

Hmm , that's interesting i faced the same problem.

Fwiw , here is a technique i use to ease the learning curve. I picked up a light-weight project - Lancet from Stu Holloway's book. Following the book, i wrote all the code tasks given there in the known language (Java or Python)- to understand the problem- and then transcribed it into Clojure. Initially it was really bad non-idiomatic Clojure , i was aware of this but would consciously only aim to finish the task. This gave me some confidence, made me "think" in Clojure and allowed me to learn some of the clojure libraries. I have finished the book.

Now, i am looking at the clojure-contrib code and discovering/learning idiomatic Clojure and going back to my Clojure code and changing that to be more idiomatic. This time i don't need Java code to actually understand the problem. Hopefully, at the end of this cycle i will be a little better.

I also found that knowing programming language fundamentals helps a little but only in the abstract , it doesn't help in being fluent in a language.

francoisdevlin• 16 years ago

Take a look here:

http://news.ycombinator.com/item?id=1033503

jshen3• 16 years ago

This highlights the difference between open and open.

java is technically open source, yet the decisions are made behind closed doors without any transparency.

redstripe• 16 years ago

And the standard open source response is "fork it". Are you prevented from building your own java with closure support and distributing it?

When ubuntu recently altered where window icons appear there was a lot of complaining even though linux is "open". Someone is in charge of all "open" projects and likely whatever decisions they make will upset some people.

JeffJenkins• 16 years ago

It's actually difficult to get a fork of java going that people will actually use because of the technology compatibility kit. See here: http://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_...

jshen3• 16 years ago

"Are you prevented from building your own java with closure support and distributing it?"

I really hate this smug answer. At best it's naive.

Practically speaking I am prevented from doing that. I have two small children and a full time job. This leaves very little time for productive coding. Also, my expertise is not in VM implementation and design. I'm sure I could learn that stuff if I put my mind to it, if only I had a lot of free time which I don't.

Having said that, a real open source project is built around a community. Typically the community wants to have some visibility into the decision making process, and that simply isn't happening with the jvm imo. I don't think it's too much to ask of them to be open about an issue like closures rather than swinging from one side to the other seemingly at the whim of a few people without any explanation.

justlearning• 16 years ago

" yet the decisions are made behind closed doors without any transparency"

care to explain who are these decision makers? Given the JSR and other process, curious to know who makes these hidden decisions.

gafter• 16 years ago

Given the lack of JSRs filed for Java SE 7, the decision makers appear to be employees of Oracle (previously Sun).

jshen3• 16 years ago

Take closures for example. We were told they weren't going into java 7. Then at that one presentation on fork/join we were suddenly told they were going in. There was never much explanation behind the bipolar decision making.

This is not transparency, it's the whims of a small cabal.

pmjordan• 16 years ago

I'm more disappointed that continuations don't appear to have made it. They're available as a patch, but actually compiling an OpenJDK with them is evidently an arcane art I haven't yet mastered.

WilliamLP• 16 years ago

I think "Java 7: Not Likely" will be the next news. The fact that the only people excited about it are non-Java JVM users should reveal something.

hraberg• 16 years ago

If you're still interested in closures for Java, my port of Ruby's Enumerable module, Enumerable.java, has a limited version for valid Java 5. The current release is 0.2.4, but this post is the best introduction: http://www.jroller.com/ghettoJedi/entry/closures_in_valid_ja...

Closures in Java 7: Not Likely

Related Stories