Showing messages 1 through 43 of 43.

• Alternative syntax for BGGA
  2008-07-08 05:23:28 ankostis [Reply | View]
  
  Please consider adding a poll-option for BGGA with the alternative syntax propsed by Rémi Forax':
  http://weblogs.java.net/blog/forax/archive/2008/07/alternative_syn.html

• Groovy
  2008-05-09 11:52:41 ackounts [Reply | View]
  
  Groovy's colsures is the way... just include Groovy in JDK.

• Thanks for the votes
  2008-02-22 02:29:56 scolebourne [Reply | View]
  
  I'd just like to thank everyone for voting in this poll, and especially those who chose FCM. Having the support of developers is vital for those of us that spend our free time trying to improve Java, while still protecting what makes it special.
  
  Stephen Colebourne, co-author FCM
• Thanks for the votes
  2008-02-24 15:44:00 talden [Reply | View]
  
  It's interesting that the proportions have stayed very stable as word of mouth has spread - and the consistency of representation might suggest that this is a good indicator of how the general java market might respond.
  
  This puts considerable pressure on closures to deliver some effective early gains (APIs accepting closures would be a good start) and also keep the learning-curve as flat as possible so that the more complicated uses of closures are the exception instead of the rule.

• Video introduction to BGGA
  2008-02-20 20:45:39 gafter [Reply | View]
  
  See a video introduction to BGGA here.

• closures are just a luxury
  2008-02-19 17:11:21 sana167 [Reply | View]
  
  There are so many dynamic languages that support closures and run on java platform (Ruby, Groovy, Scala...). Modifying java would make it complex and unweildy. More on my blog at Anand Subramanian@jroller.
• closures are just a luxury
  2008-02-20 08:40:01 mthornton [Reply | View]
  
  The inspiration for adding closures to Java was to simplify the use of proposed concurrent libraries. This application is performance critical and thus suggestions of working in dynamic languages are completely inappropriate.
• closures are just a luxury
  2008-02-20 19:01:31 sana167 [Reply | View]
  
  Introducing closures is definitely not going to improve performance, because all the proposals are compile time translations only. What we are trying to achieve with closures is getting rid of boilerplate code which you dont have to write anyway with the latest IDEs. I agree it makes code more easier to write, but it is not like we cant live without it. Meanwhile the argument against closures is that it makes the language complex. Take C for instance. The widespread adoption is mainly due to its simplicity of syntax. With most of the recent languages adopting an interpreter based approach, why hasnt lisp or smalltalk made a comeback? Because they are complex. Complex to write, complex to maintain and complex to read.
  
  Dynamic languages are definitely not suitable for performance criticial applications, but closures doesnt make it better either. So if you still want to code in closures, we should adopt a dynamic language that already supports it and make it faster. No point in trying to make java complex.
• closures are just a luxury
  2008-03-17 10:17:44 stephaneggermont [Reply | View]
  
  We don't need performance improvements. We need productivity improvements. Otherwise we wouldn't be programming in java or .net and be using relational databases.
  
  c simple? Both lisp and smalltalk are significantly simpler,
  and the leading web framework, seaside, is written in smalltalk.
  Smalltalk is definitely making a comeback. It is simple to write, to maintain, to read, and it has the better IDE.
• closures are just a luxury
  2008-02-20 08:21:04 scotty69 [Reply | View]
  
  This argument is often heard, but really absurd. If closures are a good thing (which i do believe), then they should be supported by Java, point. If closures make a language too complex and unwieldy, then the mentioned dynamic languages would not be a viable choice either...
• closures are just a luxury
  2008-02-20 13:10:08 aehrenr [Reply | View]
  
  That's not true. Dynamic languages, also called scripting languages, have a totally different purpose than statically typed languages. Scripting languages should be used when code needs to written fast, mainly by a single programmer. The focus is on programming speed, not on maintainability. Static languages are for projects that are better planned, often worked on by a group of programmers and that need to be maintained by different persons for a long time. You loose programming speed due to typing but produce more solid code due to type checking, that can be better maintained.
  To fit these two different purposes scripting languages and statically typed languages need different language features beside the typing story.
  For the quick and dirty approach it is perfect to have closures with all their potential side effects and runtime errors while it is very bad to have them in long living code.
  Therefore I like to use closures in Groovy for quick hacking but would hate to see them in Java. They add complexity and solve problems that Java shouldn't have.
• closures are just a luxury
  2008-02-21 00:43:53 scotty69 [Reply | View]
  
  Please read my comment carefully. I replied to the argument of sana167 that closures make a language complex and unwieldy. Obviously you do not agree either, because otherwise you would not do quick hacking with Groovy closures. Your argument against closures is yet another story.

• Just say no
  2008-02-19 14:55:05 dbrosius [Reply | View]
  
  When was the last time you were sitting around trying to figure how to solve something, and said, dang-it, if java only had closures... now i'll have to use an anonymous class. Seems like a lot of crap to inject into a language and have 95% of the developers incorrectly use, for the very little benefit it would bring the 5%.
• Just say no
  2008-02-24 15:52:52 talden [Reply | View]
  
  When was the last time you were sitting around trying to figure how to solve something, and said, dang-it, if java only had closures...
  
  Apparently more often than you. I agree that the most complex uses of BGGA are complex to understand, but then these more complex cases are complex to express in java anyway - if these most complex cases prove to be common in your code-base you are probably abusing the facility and not writing the simplest solution to solve the problem... Abuse of language features in java is possible with boxing, anonymous classes, statics, initialisers - it's nothing new and poor language use by some developers is not a reason to restrict the growth of the language.
  
  That said, if it proves more complex than the concept it's expressing it is an issue and if it sets the knowledge bar too high, making acquiring adequate developer resources impossible java may shit in its own nest - forcing projects to other languages.
• Just say no
  2008-03-06 08:42:59 bobh [Reply | View]
  
  I joined the forum just to comment and only because I really like programming in java.
  When was the last time... is exactly how I feel.
  Don't add more complexity to java.
  I wish it wasn't too late to vote.

• Direction not clear
  2008-02-19 13:19:10 andygavin [Reply | View]
  
  I think the worse thing in the world would be to add closures to Java7 too early and have half thought out schemes like these. Postpone adding closures or fork the language.
  
  Language design is about expressionability and consistency not being clever.
  
  BGGA is the worst spec. I'm not against braces, but it is inconsistent with the rest of the language.
  
  "Full Closures" too is quite an advert when they're not really. Full seems to suggest completeness and I can't see how it is.

• BEFORE VOTING FOR BGGA READ THIS
  2008-02-19 11:35:04 aehrenr [Reply | View]
  
  Please read this, as it argues very well:
  
  http://www.jroller.com/scolebourne/entry/evaluating_bgga_closures
  
  Don't destroy Java by transforming it in a scripting language. It is for different purposes, most important to produce code that can be easily maintained by different persons. Use Groovy for scripting, its already here and perfect for this.
  Or use Scala if you like something more elegant.

• FCM
  2008-02-19 08:14:37 aberrant [Reply | View]
  
  I feel FCM is more straight forward then BGGA. Also when you look at reducing boiler-plate code you HAVE to look at the overhead for defining a reusable structure. In all other proposals you need to define the "closure way" of invoking a chunk of code. If you need to invoke the same chunk of code the "regular way" it needs to be in a method. If you need both then you need to define it twice with different syntax. FCM uses one syntax and works with EVERY method in every 3rd party library that has EVER been written in java. People talk about the work to update old code and FCM will make the process easier. In my book if it takes parameters and returns a value then it's a method. there is no reason to have an alternate syntax for something that is clearly defined today.
• FCM
  2008-02-19 08:20:58 gafter [Reply | View]
  
  Actually, once you're created a "method reference" in FCM, you don't invoke it the same way as the original method. Much of the FCM proposal defers to BGGA for its details. The draft JSR for closures at http://www.javac.info/consensus-closures-jsr.html is based on BGGA with the addition of "method references" from FCM.
• FCM
  2008-02-19 20:09:48 aberrant [Reply | View]
  
  No the point is not when you need a to consume a method reference. As long as java is type safe there will be a need to define the parameter and return type of a method reference/closure and the method object will need to be invoked. The point is when you PASS the code in to the consuming method. BGGA has the programmer use an entirely different syntax to specify what amounts to all the properties of a method. WHY? Why a new syntax for something that java programmers already do all the time? Why something that requires a programmer to wrap already existing methods into closures? What does BGGA have that FCM + JCA does not?
• FCM
  2008-02-21 20:20:59 gafter [Reply | View]
  
  'What does BGGA have that FCM + JCA does not?'
  
  To start with: Exception transparency. Completion transparency. The possibility of wrapping a block of code in a closure without changing its meaning. Useful subtyping relationships among function types. Proper handling of definite assignment. Loop abstractions that enable the invoker to 'break' or 'continue'.
  
  However, as you can see from the draft JSR proposal based on BGGA here http://www.javac.info/consensus-closures-jsr.html we intend to add a conversion from a 'reference to a method' into a closure.

• Two, not one
  2008-02-19 07:19:28 binkley [Reply | View]
  
  Please combine BGGA with FCM.

• C3S
  2008-02-18 13:22:42 hlovatt [Reply | View]
  
  

  As the proposer of C3S I obviously support that proposal:

  http://www.artima.com/weblogs/viewpost.jsp?thread=182412

  I think it combines simple semantics, no need for closure conversions, restricted closures, etc., and clear Java like syntax that uses an unabbreviated keyword, e.g.:

  withLock lock, method{out.println "Hello"};
  

• FCM for me (again)
  2008-02-18 03:39:52 npiguet [Reply | View]
  
  Additionally to what I said in the post below, I must point out that all the new literals introduced by FCM are its main competitive advantage.
  
  Field literals, Constructor literals and Method literals sound so useful, I can easily remember several occasions where those would have saved me a lot of time and headaches.
  
  No other proposition has those literals, which is a deal breaker to me.
• New literals
  2008-02-18 03:45:44 mthornton [Reply | View]
  
  I don't think there would be any problem in adding literals to the other proposals, or in adding just the literals from FCM without the rest of it.

• FCM for me
  2008-02-18 03:19:24 npiguet [Reply | View]
  
  FCM feels like it is a much needed and natural extension of java. Semantics of keywords such as return and break basically do what you expect them to do. The meaning of this in FCM is also well defined and intuitive.
  
  I also like the fact that it creates an actual method type, that you can use as a method argument, and actually pass existing methods by reference. This finally gives me a way to do some dynamic bean and property get/setting in a type safe manner avoiding the use of the reflection API and its 5 Exceptions that always need to be caught.
  
  I know syntax is probably not something to bitch about just now, but clearly BGGA is extremely weird and confusing. FCM fit the java style much better by using a syntax for method/function type that is reminiscent of the way you normally declare a method.
  
  My opinion is that FCM will probably cover 95% of the real use cases that BGGA can also do, but with only 20% of the added complexity, hence making it a much better deal for us developers.

• Why not BGGA with FCM syntax
  2008-02-18 01:11:32 freddy33 [Reply | View]
  
  Personally I found FCM a LOT more readable than BGGA.
  And the high level of control invocation capabilities in BGGA seems that it's pushing too much in a strange world.
  I know what is a method in Java I want to be able to manipulate it as a type: This I fully manage and understand.
  So, please vote for FCM!

• BGGA... With perhaps some syntax tweaking..
  2008-02-17 13:38:16 talden [Reply | View]
  
  It's BGGA for me... I like the examples from Zdeněk Troníček referenced on Neal Gafter's blog...
  
  Some of the examples highlight to me though, how easy it is to glance over a section of code and mistake => as part of a conditional expression. Given the significance of the operator I'd prefer replacing
  
  { int x => a <= x && x <= b }
  
  with
  
  { int x # a <= x && x <= b }
  
  Also it'd be nice to see if the ".invoke" could be dissolved as it's merely a distraction whose only redeeming feature is symmetry with the closure conversion syntax.

• BGGA... With perhaps some syntax tweaking..
  2008-02-17 13:37:59 talden [Reply | View]
  
  It's BGGA for me... I like the examples from Zdeněk Troníček referenced on Neal Gafter's blog...
  
  Some of the examples highlight to me though, how easy it is to glance over a section of code and mistake => as part of a conditional expression. Given the significance of the operator I'd prefer replacing
  
  { int x => a <= x && x <= b }
  
  with
  
  { int x => a <= x && x <= b }
  
  Also it'd be nice to see if the ".invoke" could be dissolved as it's merely a distraction whose only redeeming feature is symmetry with the closure conversion syntax.

• Freeze the java language
  2008-02-17 11:09:51 ravn [Reply | View]
  
  The java language is ok as it is, but the interoperability with other languages running on the JVM should be strengthened.
  
  Then you would write type sensitive code in a functionali language like LISP or Haskell, etc.
  
  Keeping it all in javac is a typical example of "not invented here" which I think has plagued the java world for much too long.
• Freeze the java language
  2008-02-20 09:29:01 scotty69 [Reply | View]
  
  Freeze Java for a year, for two years, for a decade, forever?

• Still watching...
  2008-02-15 15:30:31 mkaufman [Reply | View]
  
  Want them in theory - but only if it can be done well (i.e. in keeping with rest of language, without lots of complexity, without making the next addition even worse etc). Otherwise no.
  
  Still watching how the proposals mature, but not optimistic so far.
• Still watching...
  2008-02-17 10:47:13 jessewilson [Reply | View]
  
  It might help if you think of FCM as typesafe reflection - how can that be bad?

• Pollution...
  2008-02-15 10:51:45 alski [Reply | View]
  
  ...to me, they are some serious pollution. I find that they are unreadable to the point that they are confusing. Even the so called "tutorials" are bad. I really don't see a need for them.
  
  When it comes to pure language features, I think the rules should be very very strict in that the changes need to solve a common existing problem and there has to be an overwhelming need for them. I just don't see a need at all. I don't so much mind seeing new packages / libraries added to the JRE.
  
  Someone, please make it stop...
• Pollution...
  2008-02-18 07:03:06 agherna [Reply | View]
  
  Leave closures to other languages that run on the JVM (Groovy, JRuby, etc.). Seems like another "me too" feature to the language that we don't need.
• Pollution...
  2008-02-17 23:56:12 jwenting [Reply | View]
  
  correct. "Closures" (aka OO function pointers) will do what Java's opponents have been trying for over a decade: they will kill the language, reduce its acceptance for new projects to a mere trickle, reducing it to a has been that's used only where it's too expensive to convert the source base to other languages.

  As it is 1.6 is coming close to that. Hardly anyone uses it seriously, rather sticking with 1.4 and 1.5. 1.7 will be worse, it will actively start people looking at alternatives, drive them away from Java for new development and force projects to consider the cost of porting to another environment as compared to the risk of sticking with a dying technology.

• Pollution...
  2008-02-18 10:53:22 evickroy [Reply | View]
  
  I find this hard to swallow. If this were true, then how did Java become so popular in comparison to languages such as C/C++ that DID have these features? Where do you find Java 1.6 not being used? The app server vendors are typically many years behind in adoption, so you can't use that for guidance. From what I have seen, desktops either have 1.5 or 1.6 on them now. Most development environments are still 1.5 because 1.6 has only been available for slightly over a year. This has always been the way of adoption of new platforms.
• Java 1.6 pre-installed
  2008-02-19 01:05:46 mthornton [Reply | View]
  
  on my most recent box from Dell.
• Pollution...
  2008-02-19 00:29:31 jwenting [Reply | View]
  
  appservers ARE a good indication. A high percentage of Java software happens to run on them...

  And just because desktops are delivered with 1.5 (and maybe, though I've not seen them 1.6) JREs preinstalled by now doesn't mean the software running on those JVMs is written for them. Most of it is still written to 1.4 and maybe 1.5 standards.

  As to C(++), it was designed with function pointers in mind, they weren't bolted on as an afterthought in a way that's poorly designed and obfuscates the syntax of the language at a time when that language has been around for over a decade and has perfectly good alternatives that have a syntax that IS in line with the general design of the language.

• Closures are good
  2008-02-15 10:27:29 prime21 [Reply | View]
  
  Funny that most people want to either go "all the way" with BGGA, or they don't want any closures at all. I would think that anyone who falls into the "I don't want closures" category probably mean that they want CICE, or FCM. Personally I think that FCM is the right way to go. BGGA makes things more complicated than they need to be for very little benefit.
• Closures are good
  2008-02-20 05:01:41 andygavin [Reply | View]
  
  When I say I don't want closures. I meant I don't want any of the proposals in the main-line java language. If people want functional-language extentions to java put these in a different language. JavaF or something. The reason being if elaborate closures take over the language some of the community that have come to java to keep their solution simple will look for alternative platforms.
  
  One of the problems with the closure debate I have is some people want syntatic sugar for inner classes and others want binding of variables. Isn't it a bit late in the day to try and redefine java's scoping?
• Closures are good
  2008-02-15 11:30:43 mthornton [Reply | View]
  
  No I think most of the nay sayers mean exactly that. They really don't want any form of closure. Hey they may well not like anonymous inner classes either, but they are stuck with those.
• Closures are (not) good (enough)
  2008-02-18 01:21:08 fenring [Reply | View]
  
  exactely. solving anonymous inner class would add more things that i don't like. they are not so bad anyway.
  
  Though, I'd like to vote for ARM.
  
  Keep It Straight Simple !