NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
You can read about most of it
here
. Basically all but one has joined up behind a proposal for a JSR about adding closures to Java.
Since the authors of all three current major closure proposals, except notably my personal coding hero Joshua Bloch (author of the Java bible - Effective Java), seem to be backing this JSR. Chances are very high that you will be directly affected by the outcome of this JSR, so speak up and praise the lord for this proposal to Pimp My Java.
Personally I wonder where the solution will land. At CICE (fixing anonymous inner classes with a better syntax), BGGA (adding a construct that basically let you add new language constructs to Java) or FCM (somewhere in between)? I found a
good post
by "Crazy Bob", with a nice graph, though it doesn't include FCM.
The fact that Joshua Bloch is missing from the list is peculiar. It might just be because of legal reasons within Google and have no real meaning but it is interesting nevertheless. Josh has IMO always been extremely clear sighted about the mechanisms behind good coding and good language constructs, so his position might be interesting. Let's see how that evolves.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
The usual attention to detail has been paid. Let's assume that FCS means FCM.
Bob Lee's graph predates FCM.
> The fact that Joshua Bloch is missing from the list
> is peculiar. It might just be because of legal
> reasons within Google and have no real meaning but it
> is interesting nevertheless.
I don't think that legal reasons have much to do with it; rather it is just his opinion that closures should satisfy only a few use cases, nowhere near as many or as useful as Neal Gafter and the other spec authors would like.
> Josh has IMO always been
> extremely clear sighted
In this case, possibly short-sighted. I'd certainly like to hear more from him on this. His reasoning was merely "to keep things simple", which is actually what the JSR is promoting. He would rather have switches on strings; something that I feel would encourage some poor coding practices.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> it; rather it is just his opinion that closures
> should satisfy only a few use cases, nowhere near as
> many or as useful as Neal Gafter and the other spec
> authors would like.
>
> > Josh has IMO always been
> > extremely clear sighted
>
> In this case, possibly short-sighted. I'd certainly
> like to hear more from him on this. His reasoning
> was merely "to keep things simple", which is actually
> what the JSR is promoting. He would rather have
> switches on strings; something that I feel would
> encourage some poor coding practices.
So he's shortsighted for not liking your latest favourite "XXX has it so Java must have it too" thingy.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
The reason final was made mandatory for closed over variables was to avoid bugs and to keep things simple. What has changed since that decision? Did developers suddenly get less bug prone or did education suddenly get better on all levels?
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> The reason final was made mandatory for closed over
> variables was to avoid bugs and to keep things
> simple.
You're misinformed. The reason was that if they'd allowed non-final access then local variables could end up on the heap. That scared the bejesus out of the C++ programmers involved in shaping Java in the early days, who were paranoid about performance.
Re: Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
Will this JSR be developed in the open or at least having a read-only developer mailing list available? It would be interesting following the development of this JSR and at least indirectly comment on its progress.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> He would rather have
> switches on strings; something that I feel would
> encourage some poor coding practices.
How would switches on Strings encourage poor coding practices any more than ordinal types? "If then else, if then else, if then else" is ugly and verbose.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> How would switches on Strings encourage poor coding
> practices any more than ordinal types? "If then
> else, if then else, if then else" is ugly and verbose.
Last Thursday I was teaching a small group of students. One of them was using Strings for control, e.g., in one place:
action="doThisThenThat";
Then he was trying to do a switch in another place:
switch (action)
{
case "thisThenThat":
thiss();
that();
break;
case "thatThenThis":
that();
thiss();
break;
}
Spot the deliberate mistake (other than that switches on Strings don't compile)? He didn't. String-based protocols are brittle. We have objects, let's use them:
action=thisThenThat;
Then elsewhere:
action.invoke();
Fine, this particular programmer is a beginner, but I'd rather that the language encouraged even beginners to do good things. I feel that closures would have made things even better - he wouldn't have even been tempted to have names for thisThenThat:
action={ => thiss(); that(); };
Elsewhere:
action.invoke();
Perhaps you know some use cases for switches on Strings that have eluded me.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
You are very fortunate to have students to support your point. Students that have no problems with closures, but are using raw string constants without IDEs and make simple typing errors that they don't catch. Sweet.
Switch Strings are just convenience for "if else" constructs involving strings. They do not hinder better OO unless you have very convenient students. I personally don't think switch string would be particularly useful, but they won't hurt either.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> You are very fortunate to have students to support
> your point. Students that have no problems with
> closures, but are using raw string constants without
> IDEs and make simple typing errors that they don't
> catch. Sweet.
I don't generally mention closures to students, except to say "I know this syntax is a bit long-winded, there's a better one on the way".
> Switch Strings are just convenience for "if else"
> constructs involving strings.
I understand that. But comparing strings to constant values is already a bad pattern, and not because nested if..else statements are ugly. I think the language should encourage better patterns than that.
> I
> personally don't think switch string would be
> particularly useful, but they won't hurt either.
I'd rather that it was implementable as an API than 'hard-coded' in the language.
Re: Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
I'm sorry, I just don't feel that the benefits of closure are greater than the cost it brings (at least in its current form). I wish you could just access the non-final fields using the existing syntax. Just my 2 cents.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> > Switch Strings are just convenience for "if
> > else" constructs involving strings.
>
> I understand that. But comparing strings to constant
> values is already a bad pattern, and not because
> nested if..else statements are ugly. I think the
> language should encourage better patterns than that.
I'm all for encouraging good programming practices, but there are times -- particularly when processing user input -- that you just have to compare string values. And sometimes you need to compare a value against a long list of potential string values. This is where having a 'switch' construct can help to improve readability. Plus, the compiler could probably generate code that's more efficient than a naive 'if..else if..else if..' sequence.
J2ME programmers count bytes the way a super-model counts calories.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> I'm all for encouraging good programming practices,
> but there are times -- particularly when processing
> user input -- that you just have to compare string
> values.
The strategy pattern can replace all of those cases, as far as I know. If not, post one.
> Plus, the compiler could
> probably generate code that's more efficient than a
> naive 'if..else if..else if..' sequence.
There's no information in a switch statement that the compiler could not glean from a nested if..else tree.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> > > Switch Strings are just convenience for "if
> > > else" constructs involving strings.
> >
> > I understand that. But comparing strings to constant
> > values is already a bad pattern, and not because
> > nested if..else statements are ugly. I think the
> > language should encourage better patterns than that.
>
> I'm all for encouraging good programming practices,
> but there are times -- particularly when processing
> user input -- that you just have to compare string
> values. And sometimes you need to compare a value
> against a long list of potential string values. This
> is where having a 'switch' construct can help to
> improve readability. Plus, the compiler could
> probably generate code that's more efficient than a
> naive 'if..else if..else if..' sequence.
Doesn't Java 1.5's enumerated type handle situations where you would want to switch on strings. Like this:
publicclass TrivialHttpRequestHandler {
enum HttpMethod {GET, POST, PUT, DELETE, HEAD}
publicvoid acceptRequest(InputStream is, OutputStream os) {
Reader r = new BufferedReader(new InputStreamReader(is));
StreamTokenizer st = new StreamTokenizer(r);
st.nextToken();
switch(HttpMethod.valueOf(st.ttype)) {
GET:
doGet(is, os);
break;
POST:
doPost(is, os);
break;
PUT:
doPut(is, os);
break;
DELETE:
doDelete(is, os);
break;
HEAD:
doHead(is, os);
break;
}
}
}
Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
URL: A Summary at java.net
At 6:41 PM on Apr 30, 2007, Mikael Grev
wrote:
Fresh Jobs for Developers Post a job opportunity
Since the authors of all three current major closure proposals, except notably my personal coding hero Joshua Bloch (author of the Java bible - Effective Java), seem to be backing this JSR. Chances are very high that you will be directly affected by the outcome of this JSR, so speak up and praise the lord for this proposal to Pimp My Java.
Personally I wonder where the solution will land. At CICE (fixing anonymous inner classes with a better syntax), BGGA (adding a construct that basically let you add new language constructs to Java) or FCM (somewhere in between)? I found a good post by "Crazy Bob", with a nice graph, though it doesn't include FCM.
The fact that Joshua Bloch is missing from the list is peculiar. It might just be because of legal reasons within Google and have no real meaning but it is interesting nevertheless. Josh has IMO always been extremely clear sighted about the mechanisms behind good coding and good language constructs, so his position might be interesting. Let's see how that evolves.
Cheers,
Mikael Grev
23 replies so far (
Post your own)
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
The usual attention to detail has been paid. Let's assume that FCS means FCM.Bob Lee's graph predates FCM.
> The fact that Joshua Bloch is missing from the list
> is peculiar. It might just be because of legal
> reasons within Google and have no real meaning but it
> is interesting nevertheless.
I don't think that legal reasons have much to do with it; rather it is just his opinion that closures should satisfy only a few use cases, nowhere near as many or as useful as Neal Gafter and the other spec authors would like.
> Josh has IMO always been
> extremely clear sighted
In this case, possibly short-sighted. I'd certainly like to hear more from him on this. His reasoning was merely "to keep things simple", which is actually what the JSR is promoting. He would rather have switches on strings; something that I feel would encourage some poor coding practices.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> it; rather it is just his opinion that closures> should satisfy only a few use cases, nowhere near as
> many or as useful as Neal Gafter and the other spec
> authors would like.
>
> > Josh has IMO always been
> > extremely clear sighted
>
> In this case, possibly short-sighted. I'd certainly
> like to hear more from him on this. His reasoning
> was merely "to keep things simple", which is actually
> what the JSR is promoting. He would rather have
> switches on strings; something that I feel would
> encourage some poor coding practices.
So he's shortsighted for not liking your latest favourite "XXX has it so Java must have it too" thingy.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
The reason final was made mandatory for closed over variables was to avoid bugs and to keep things simple. What has changed since that decision? Did developers suddenly get less bug prone or did education suddenly get better on all levels?Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> So he's shortsighted for not liking your latest> favourite "XXX has it so Java must have it too"
> thingy.
Kindly point to one place where I have used that logic. Just one.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> The reason final was made mandatory for closed over> variables was to avoid bugs and to keep things
> simple.
You're misinformed. The reason was that if they'd allowed non-final access then local variables could end up on the heap. That scared the bejesus out of the C++ programmers involved in shaping Java in the early days, who were paranoid about performance.
It has since been regarded as a mistake.
Re: Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
Will this JSR be developed in the open or at least having a read-only developer mailing list available? It would be interesting following the development of this JSR and at least indirectly comment on its progress.Regards,
Georg Lundesgaard
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> He would rather have> switches on strings; something that I feel would
> encourage some poor coding practices.
How would switches on Strings encourage poor coding practices any more than ordinal types? "If then else, if then else, if then else" is ugly and verbose.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> How would switches on Strings encourage poor coding> practices any more than ordinal types? "If then
> else, if then else, if then else" is ugly and verbose.
Last Thursday I was teaching a small group of students. One of them was using Strings for control, e.g., in one place:
action="doThisThenThat";
Then he was trying to do a switch in another place:
switch (action) { case "thisThenThat": thiss(); that(); break; case "thatThenThis": that(); thiss(); break; }Spot the deliberate mistake (other than that switches on Strings don't compile)? He didn't. String-based protocols are brittle. We have objects, let's use them:
action=thisThenThat;
Then elsewhere:
action.invoke();
Fine, this particular programmer is a beginner, but I'd rather that the language encouraged even beginners to do good things. I feel that closures would have made things even better - he wouldn't have even been tempted to have names for thisThenThat:
action={ => thiss(); that(); };
Elsewhere:
action.invoke();
Perhaps you know some use cases for switches on Strings that have eluded me.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
You are very fortunate to have students to support your point. Students that have no problems with closures, but are using raw string constants without IDEs and make simple typing errors that they don't catch. Sweet.Switch Strings are just convenience for "if else" constructs involving strings. They do not hinder better OO unless you have very convenient students. I personally don't think switch string would be particularly useful, but they won't hurt either.
Cheers,
MiG Java Calendar Component, MiG Layout for Swing/SWT (Vote -> JDK)
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> You are very fortunate to have students to support> your point. Students that have no problems with
> closures, but are using raw string constants without
> IDEs and make simple typing errors that they don't
> catch. Sweet.
I don't generally mention closures to students, except to say "I know this syntax is a bit long-winded, there's a better one on the way".
This is the most I've ever gone into on it: http://docs.google.com/Doc?id=dx5mfkq_64c9c6fv
> Switch Strings are just convenience for "if else"
> constructs involving strings.
I understand that. But comparing strings to constant values is already a bad pattern, and not because nested if..else statements are ugly. I think the language should encourage better patterns than that.
> I
> personally don't think switch string would be
> particularly useful, but they won't hurt either.
I'd rather that it was implementable as an API than 'hard-coded' in the language.
Re: Closures Consensus. FCM, CICE(-1) and BGGA Unite. Horray Say the Geeks!
I'm sorry, I just don't feel that the benefits of closure are greater than the cost it brings (at least in its current form). I wish you could just access the non-final fields using the existing syntax. Just my 2 cents.Gili
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> > Switch Strings are just convenience for "if> > else" constructs involving strings.
>
> I understand that. But comparing strings to constant
> values is already a bad pattern, and not because
> nested if..else statements are ugly. I think the
> language should encourage better patterns than that.
I'm all for encouraging good programming practices, but there are times -- particularly when processing user input -- that you just have to compare string values. And sometimes you need to compare a value against a long list of potential string values. This is where having a 'switch' construct can help to improve readability. Plus, the compiler could probably generate code that's more efficient than a naive 'if..else if..else if..' sequence.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> I'm all for encouraging good programming practices,> but there are times -- particularly when processing
> user input -- that you just have to compare string
> values.
The strategy pattern can replace all of those cases, as far as I know. If not, post one.
> Plus, the compiler could
> probably generate code that's more efficient than a
> naive 'if..else if..else if..' sequence.
There's no information in a switch statement that the compiler could not glean from a nested if..else tree.
Re: Closures Consensus. FCS, CICE(-1) and BGGA Unite. Horray Say the Geeks!
> > > Switch Strings are just convenience for "if> > > else" constructs involving strings.
> >
> > I understand that. But comparing strings to constant
> > values is already a bad pattern, and not because
> > nested if..else statements are ugly. I think the
> > language should encourage better patterns than that.
>
> I'm all for encouraging good programming practices,
> but there are times -- particularly when processing
> user input -- that you just have to compare string
> values. And sometimes you need to compare a value
> against a long list of potential string values. This
> is where having a 'switch' construct can help to
> improve readability. Plus, the compiler could
> probably generate code that's more efficient than a
> naive 'if..else if..else if..' sequence.
Doesn't Java 1.5's enumerated type handle situations where you would want to switch on strings. Like this:
public class TrivialHttpRequestHandler { enum HttpMethod {GET, POST, PUT, DELETE, HEAD} public void acceptRequest(InputStream is, OutputStream os) { Reader r = new BufferedReader(new InputStreamReader(is)); StreamTokenizer st = new StreamTokenizer(r); st.nextToken(); switch(HttpMethod.valueOf(st.ttype)) { GET: doGet(is, os); break; POST: doPost(is, os); break; PUT: doPut(is, os); break; DELETE: doDelete(is, os); break; HEAD: doHead(is, os); break; } } }