Skip to main content

Seeking grand challenges

Posted by daniel on October 7, 2003 at 3:52 AM PDT

How do you go about finding a grand challenge? The problem has to be worth solving and, to be grand, should require significant effort with a hope of being solved.


Today in Projects and Communities,

the Java Patterns community links to an article on The Grand Challenges for computer science .The actual criteria for a Grand Challenge are that it "be a 15-year project with international participation. There should be a clear evaluation of success or failure, and it should offer fundamental and radical advances in basic science or engineering."

A UK expert panel is kicking off seven projects with the hopes that one or more of them will be able to graduate to the Grand Challenge level. One project looks to organize the mountain of digital data that you will accumulate throughout your life. Another project concerns Global ubiquitous computing based on the idea that "Within 20 years computers will be ubiquitous and globally connected."

The article ends by citing previous grand challenges:

  • "Human Genome Project - achieved
  • The Turing Test - outstanding
  • A championship chess programme - achieved
  • To find a cure for cancer within 10 years - failed in the 1970s
  • Unify the four forces of physics - in progress "

We also point to JGoodies , our project spotlight for the week. Follow the links to check out the freely downloadable look and feels available from JGoodies . Screenshots are available from the "look" subproject.


In his Weblog entry today Simon Brown praises HttpClient - another great Jakarta Commons component. Rather than implementing HTTP POSTs himself, Simon recently discovered how easy it is to use the Jakarta Commons HttpClient. In a talkback, ajsutton adds that "The best starting point for HttpClient is to read the tutorial. It's available at http://jakarta.apache.org/commons/httpclient/tutorial.html and outlines the right pattern for HttpClient usage. "

David Walend continues the thread that includes arguments on both sides of the exception issue. In Design for Exceptions David writes

Unlike the rest of the API, which gets defined during design, I've found exceptions tend to bubble up from implementation. Sometimes it's obvious that something will go wrong at design time, but often I need to create some new exceptions while implementing the code. Plus I like to create very descriptive subclasses of my abstract exception. Specific subclasses make it easier for code handling the exception to determined what failed and how to react. That's what Dr. Gosling means by, "... in a throws clause ... be as specific as possible."

David also refers to Felipe Leme's latest blog entry It's time to move on. Felipe notes that even if Tiger (J2SE 1.5) were released today, it's going to take a long time before we see adoption in major applications. He point out that J2SE 1.4 is in its third version and despite how long it has been around, there are plenty of applications that still use 1.3. He predicts that "with Tiger and its language changes, this situation can be even worse, as the IDEs have to adapt themselves to these changes."


In Also in Java Today popular culture makes its way into tech writing with Larry O'Brien's Java Eye for the .NET Guy . Larry's article is in a series on Windows and .NET and reminds the community that there is plenty that the .NET programmers can learn from the experience of Java developers. Get past the opening paragraph and comments such as "Of course, there are those who