|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 25
Messages: 25
Messages: 25
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Stephen Colebourne on comparing closure specs
Stephen Colebourne has posted "Comparing closures - CICE, BGGA and FCM," looking at how three closure specifications (Lee/Lea/Bloch - CICE, Bracha/Gafter/James Gosling/von der Ahé - BGGA, and himself/Stefan Schulz - FCM) do some fairly likely tasks, including some examples that other languages use to illustrate closures.
The examples use equivalent Java 6 code first, then show some possibilities with each of the closure specs. It may have been more interesting to see the closure specifications' offerings first, just to give an idea of how easy they actually are to understand:- CICE:
public void init(JButton button) {
button.addActionListener(ActionListener(ActionEvent ev) {
handleButtonPress(ev); // a method in the class
});
} - BGGA:
public void init(JButton button) {
button.addActionListener({ActionEvent ev => handleButtonPress(ev);
});
}Alternatively:public void init(JButton button) {
button.addActionListener(ActionEvent ev : ) {
handleButtonPress(ev);
}
} - FCM:
public void init(JButton button) {
button.addActionListener(#(ActionEvent ev) {
handleButtonPress(ev);
});
}Alternatively:public void init(JButton button) {
button.addActionListener(this#handleButtonPress(ActionEvent));
}
The Java 6 code uses an anonymous inner class to invoke handleButtonPress(ActionEvent).
The "multiply two integers" example is a whole lot of code just to do "x*y" with functional programming, but highlights creation of a new class with a specialized method. Here are the examples:- CICE:
public int multiplier = 3;
IntMultiplier mult = new IntMultiplier() {
public int multiply(int value) {
return value * multiplier;
}
};
int result = mult.multiply(6); - BGGA:
int multiplier = 3;
{int => int} mult = {int value =>
value * multiplier
};
int result = mult.invoke(6); - FCM:
int multiplier = 3;
#(int(int)) mult = #(int value) {
return value * multiplier;
};
int result = mult.invoke(6);
Mr. Colebourne is biased (as he readily admits), having co-authored the FCM specification, but he's done a good job providing simple examples for each of the closure specifications being proposed. Which one of those seems most clear? Which one of the three are you most likely to prefer writing? Are any of these going to make closures worth including in Java 7?
|
|
|
Message #228358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Stephen Colebourne on comparing closure specs
In my opinion closures without type inference is adding complexity, not removing it. In all of the examples we had to add new syntax just for defining the functional types. It most probably would be a lesser evil to just allow the compiler to infer (locally) types and pass closures instead of one-method interfaces. This would only require new syntax for specifying block arguments, which would never show up in contracts.
Jevgeni Kabanov
www.araneaframework.org
|
|
|
Message #228363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OMG, you can't be serious
I can't believe what I'm seeing. Supposedly a simple concept of closures, is turning into a syntax nightmare. I don't see why all of this syntax is needed.
What's wrong with either creating a method type...
int multiplier = 3;
Method m = int comput(value) {
return mutliplier * value;
}
int result = m.invoke(3);
Even the current workaround with anonymous inner classes, just with allowing non-final fields, would be easier to understand/use.
Overall, I think CICE implementation is more sane.
Ilya
|
|
|
Message #228365
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OMG, you can't be serious
sorry, I mistyped...
int multiplier = 3;
public method m = int method(int value) {
return multipler * value;
}
int result = m.invoke(3);
|
|
|
Message #228392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
CICE looks like status quo
I'm having trouble seeing how CICE is any different from the inner classes we have now. Oh ... it's just a sleight-of-hand rebinding of 'this'. How vastly unimpressive.
As for which I prefer: none of them. They're all a godawful soup of overcomplicated syntax. Here's the syntax I want:
button.addActionListener(handleButtonPress);
Is it too hard to figure out this basic freaking idea of first-class functional values? Have I grossly overestimated the intelligence of Java's custodians?
|
|
|
Message #228394
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
on overestimating intelligence
It occurs to me that ambiguous conditions can appear in the face of overloading and covariance, so there needs to be some means of adding type annotations to resolve which instance of handleButtonPress you need, if it comes to that -- and probably 95% of the time, it won't. In this case, something like FCM without the noisy punctuation wart wins out for me. I don't know what the replacement is, figure it out. Maybe a new keyword?
I suspect that the proposal that does the very least and has the names of the most Java insiders attached to it will win. Score another win for every language but Java. Yes, I'm bitter.
|
|
|
Message #228397
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OMG, you can't be serious
If all method references have the same type it's like using java.lang.Object for all object references. Java cannot compromise type safety.
Taras
|
|
|
Message #228402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OMG, you can't be serious
sorry, I mistyped...
int multiplier = 3;
public method m = int method(int value) {
return multipler * value;
}
int result = m.invoke(3);
You can just use:
int result = m(3);
|
|
|
Message #228412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Need better examples
IMO, the goal of closures is to enable better API-s, like generics have done.
Swing API has already found a way to use closures-like anonymous inner classes. The biggest opportunity for closures is in other API-s:
- Each method that returns an Iterator/Enumeration (or enables iteration in some other way, like through ResultSet) is candidate for alternative forEach() method
- When you have openXXX()/closeXXX() or beginXXX()/endXXX() methods (or whenever try-finally is recommended), you may consider closure based withXXX() method, like withTransaction()
Also, nice syntax for closure invocation and closure type definition is less important, it is usualy part of an API implementation.
Something like control invocation syntax (part of BBGA) is my favorite. Triple ")};" is just too noisy.
Nebojsa
|
|
|
Message #228413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: CICE looks like status quo
Your solution is vastly superior to any of the ones I have seen so far. Quite similar to the way .Net does it, if I remember correctly.
|
|
|
Message #228447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Need better examples
Neal Gafter: http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java
My comments to the proposal:
I prefer "lock.with(..." over "Lock.withLock(lock...", or "myCollection.forEach(..." over "forEach(myCollection...". BTW, am influenced by Smalltalk when think about closures.
Syntax "c.forEach(Item t :) {...}" is closest to my expectations. But do we need colon? Why don't use "c.forEach(Item t) {...}" and "lock.with() {...}". Isn't opening curly bracket after closing parenthesis enough to denote new syntax?
Nebojsa
|
|
|
Message #228452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Control invocation syntax
A number of replies have focussed on the control invocation syntax of BGGA, which allows you to do the following:
Locks.withLock(lock) {
// some code protected by the lock
}
Both CICE and FCM deliberately do not tackle this type of syntax, however they do so for different reasons.
The authors of CICE (Josh Bloch notably) do not believe that developers should be allowed to write code in this style. They believe that only language designers should be able to make changes that look visually like keywords.
The authors of FCM (ie. Stefan and I) believe that a control invocation syntax is very useful, but we think it should be considered separately to proposals to simplify working with methods. We believe that BGGA has greatly complicated matters by attempting to cover both in the same spec.
|
|
|
Message #228456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Control invocation syntax
The authors of CICE (Josh Bloch notably) do not believe that developers should be allowed to write code in this style. They believe that only language designers should be able to make changes that look visually like keywords.
The authors of FCM (ie. Stefan and I) believe that a control invocation syntax is very useful, but we think it should be considered separately to proposals to simplify working with methods. We believe that BGGA has greatly complicated matters by attempting to cover both in the same spec.
In real world applications, I expect almost 100% of closure literals will be parameters of method calls. So, syntax for "method call with a closure parameter" is primary use case, even more important then closure literal syntax itself. You may put only this syntax in a proposal and it makes sense.
I like functional programming, but I think that all proposals are too focused on functional programming aspect of closures.
So, I agree that we should separate proposals to simplify working with methods and proposals on the rest of closures aspects, but I have different opinion what is priority.
I also, agree that changes that look visually like keywords are not good and a comment in my previous post goes in this direction.
Nebojsa
|
|
|
Message #228457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Stephen Colebourne on comparing closure specs
In my opinion closures without type inference is adding complexity, not removing it.
Type inference is already being proposed elsewhere, so this proposal will hopefully benefit from that. Adding it in this proposal, one might end up being incompatible with whatever type inference makes it into Java. Plus, it makes the spec somewhat easier to understand, not to mention type inference.
|
|
|
Message #228458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OMG, you can't be serious
What's wrong with either creating a method type...
int multiplier = 3;
Method m = int comput(value) {
return mutliplier * value;
}
int result = m.invoke(3);
Method, assuming you mean java.lang.reflect.Method, can throw some exceptions when you call invoke. In your example, what use is the name 'comput'? You could just do Method m=int(value){stuff}. Of course, that starts to look like a method call instead, but at least we're not giving names to things that don't need them.
How does the compiler know what type to give value? Wouldn't you need Method m=int comput(int value){stuff}? I'm not sure that's much of a win over #(int(int value)){stuff}. Without the unnecessary name, comput, yours looks like int(int value){stuff}, which is only a # and a pair of () away from the proposal.
Further, FCM solves another issue, allowing you to refer to existing methods. The # allows both issues to be solved with reasonably similar syntax.
|
|
|
Message #228460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: CICE looks like status quo
Here's the syntax I want:
button.addActionListener(handleButtonPress);
Is it too hard to figure out this basic freaking idea of first-class functional values? Have I grossly overestimated the intelligence of Java's custodians?
button.addActionListener(handleButtonPress) is already valid syntax, and will refer to a field. If you make it also able to refer to a method, that will be ambiguous in some cases, as Java allows fields and methods to have the same name as each other. There would need to be a rule, such as "if there is a field and a method, and both are visible, use the field". I expect this would be workable, but cause confusion in some cases.
The FCM allows what you want, except that currently you have to specify the types, and add a #, so you get:
button.addActionListener(#handleButtonPress(ActionEvent));
It is an open issue in the proposal as to whether to require the types when the method isn't overloaded:
"5. Is there a shortcut syntax to avoid specifying the types in a method literal or invocable method reference when the method is not overloaded, for example Object#equals(...)"
|
|
|
Message #228482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: CICE looks like status quo
It is an open issue in the proposal as to whether to require the types when the method isn't overloaded:
"5. Is there a shortcut syntax to avoid specifying the types in a method literal or invocable method reference when the method is not overloaded, for example Object#equals(...)"
My gut reaction is to consider the issue closed -- it shouldn't require the type, ever. Possibly this runs into problems with late binding, but then again you get the problem anyway.
As for ambiguity between methods and fields, if functions were real actual types (no, reflection does not count) then this simply wouldn't be a problem. addActionListener would be overloaded to take an ActionEvent->void type, and handleButtonPress would be selected as the more specific type. Now if there actually was ambiguity, I'd expect the compiler to call it an error and require an explicit type signature (you could abuse the typecast syntax for this, or *sigh* use reflection).
All right, though, I'll admit that the Java designers don't want methods suddenly appearing in a namespace that was formerly populated by locals, with special rules on which one is selected. My personal attitude is "too bad, we have overloading anyway", but I can concede the need for a syntax. And # is decent, it's reminiscent of smalltalk. And there goes another piece of punctuation that can't easily be used by anything else in the future -- we're getting painted into a corner here when we don't have the ability to program syntax.
|
|
|
Message #228502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Stephen Colebourne on comparing closure specs
One thing that really bugs me about FCM is that they are overloading the hash (#) symbol. How will they resolve this with Java-7's XML integration, where this was used in the proposed syntax at JavaOne? (http://blogs.sun.com/mr/resource/integrating-xml-j1-2006.pdf)
I tend to like CICE because it stays the truest to the language and is the most obvious to new users and old timers alike. I don't like weird syntax that gets away from Java's core value of simplicity. (Heck, I'd have prefered a new keyword than the ':' for /for each/, but alas..)
|
|
|
Message #228511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native XML
I'm betting that native XML won't happen - it's never struck me as a good language change idea.
Stephen Colebourne, FCM
|
|
|
Message #228517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why not
Why not use the following:
{ String a; |
System.out.println( "Hello " + a ); }.value( "World" );
The most important thing is that block can be assigned to a variable, so:
Block m = { String a; |
System.out.println( "Hello " + a ); };
m.value( "World" );
It shouldn't be more complicated than that.
If the "|" character is not welcome, here is an alternative:
new Block( String a ) {
System.out.println( "Hello " + a ); }.value( "World" );
So again this could be written:
Block m = new Block( String a ) {
System.out.println( "Hello " + a ); };
m.value( "World" );
That is pretty consistent with current Java.
|
|
|
Message #228522
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not
There are two components to any language change - syntax and semantics. Syntax only matters in terms of visual appeal, verbosity and clarity, and is often subjective. Semantics are far more important, as they define what the code actually does.
Your proposal to use a | and move the parameters inside the block is simply a syntax change. Having written FCM, I'd say it wasn't as clear, but others will disagree. Its subjective and a matter of taste.
However, your proposal to assign to a Block class is a semantic change. I don't believe that it is acceptable as blocks can have different numbers of parameters, and different return types. Put simply, using a single 'Block' class means that type-safety is lost.
|
|
|
Message #228544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Method pointer
I've not opinion about "anonymous method"/closure. But about named, I think using function pointer like in C, is the simplest solution.
public R myMethod(T1 t1) {
...
}
x.doStuff(methodref(this.myMethod));
public R doStuff(RefMethod<R,T1> method) {
T1 t1 = ...
return method.invoke(t1);
}
I think this type of binding could also be used for property/public field binding.
x.bind(button, propertyref(this.myField));
* This type of syntax is already valid, and could be simulated/prototyped with a pre-processor (like spoon).
* This syntax use the IDE completion and validation (no string)
|
|
|
Message #228717
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Stephen Colebourne on comparing closure specs
I am having a conversation with Stephen and Stefan regarding their proposal and its relationship to the goals of BGGA. Stephen tells me that "We intended FCM to be mostly about syntax sugar, providing a better syntax for code that can be written today. Thus most FCM syntax would simply substitute the existing matching code." and "Stefan and I are still discussing ideas on a control-invocation syntax that would be a complementary document to FCM, and not part of it. This would be specifically to tackle the synchronous use cases"
I think there are some good ideas in FCM, but I'm suspending judgment until I see the full complement of features proposed.
|
|
|
Message #228771
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: CICE looks like status quo
Here's the syntax I want:
button.addActionListener(handleButtonPress);
Is it too hard to figure out this basic freaking idea of first-class functional values? Have I grossly overestimated the intelligence of Java's custodians?
button.addActionListener(handleButtonPress) is already valid syntax, and will refer to a field. If you make it also able to refer to a method, that will be ambiguous in some cases, as Java allows fields and methods to have the same name as each other. There would need to be a rule, such as "if there is a field and a method, and both are visible, use the field". I expect this would be workable, but cause confusion in some cases.
The FCM allows what you want, except that currently you have to specify the types, and add a #, so you get:
button.addActionListener(#handleButtonPress(ActionEvent));
It is an open issue in the proposal as to whether to require the types when the method isn't overloaded:
"5. Is there a shortcut syntax to avoid specifying the types in a method literal or invocable method reference when the method is not overloaded, for example Object#equals(...)"
Politically speaking, Sun Microsystems made a huge stink when Microsoft added function pointers to Java without permission, claiming that it screwed up the language. What's being talked about here is very nearly that.
But I myself think function pointers would be just fine.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
