Skip to main content

Artificial Man

Posted by editor on October 4, 2005 at 6:59 AM PDT

The continuing consideration of our intellectual successors.

"There seems to be an increasing level of this thing we cannot adequately define but are very capable of testing for various purposes: intelligence. Whether silicon based or human, the general level of intelligence is rising. The difference between our digital offspring and ourselves is one of degree, not direction."

In today's Feature Article, The Artisan and the Artilect, Part 2 Max Goff continues his consideration of intelligence, natural and artificial, and the implicit possibility (or is it an inevitability) that Moore's Law will eventually lead to an artificial intelligence more capable than our own. In this installment, he considers a question of "how do you get there from here?" In other words, was the emergence of natural intelligence strictly an evolutionary process of good luck? And does buying that require a leap of faith? And if that's not plausible, how else do you get there?

Thinking about these issues is important because it's the critical step in creating the so-called "artilect", the superior artificial intelligence: figure out what's so special about the human brain, and then do version 2.0. This premise sets up the forthcoming final installment of the series, considering the clash of wills that can be expected to accompany that effort.

You need to read today's Weblogs very carefully if you're to understand Bruce Tate's story about
Joe, the Amazing Coding Monkey. By way of description, he blurbs "What an amazing couple of weeks. Beyond Java became generally available last week, and my pet monkey learned to code." But there's a lot more to it than that.

A Read-only database?, Bernt Johnsen writes:
"A read only database can be a useful thing. This application could be implemented as a small Java application on top of a SQL database. And yes, it's easy to make such an application with Apache Derby."

Osvaldo Pinali Doederlein wonders about the consequences as
Tomcat goes Native:
"The new version of Apache Tomcat will support a library of native code to speend some things up. Is this the end of the PureJava dogma?"

In Projects and
developers looking to get involved with the Mobicents VoIP project can now learn the API from the Mobicents Examples 1.0 Beta 1, which offer a Resource Adapter tutorial by Michael Maretzke and a SLEE "wake-up call" example by Francesco Moggia.

Noting that there is currently a Java Sound implementation in J2SE without a JSR spec, the Java Sound JSR Project aims to develop a JSR for sampled and generated sound. The project seeks support from corporations, professionals, and others.

In Also in
Java Today

"We've all heard about the simplicity and power of the EJB 3.0 specification. And because this has proven to be true, we can't help but think that performance must be rather poor. After all, all that simplicity must come at a price." With this premise in mind, Peter Zadrozny and Raghu R. Kodali took Oracle's EJB 3.0 implementation and assessed its performance at common EJB tasks, such as using the Data Access Object and Session Facade patterns. In The Performance of EJB 3.0, they report that the results are very encouraging

Ever written a speech-driven application? They're few and far between. Aimee Silva blames this on the lack of a standard, well-known architecture: "To create robust voice applications, voice developers have had to be familiar with many languages, techniques, architectures, and processes. Compounding this problem, voice applications are often built using proprietary markup languages." In Creating Voice Applications with Reusable Dialog Components she shows how J2EE, JSP, and Struts developers can build voice apps with VoiceXML and the Reusable Dialog Component (RDC) open source project.

In today's Forums,
prunge discusses a handy optimization in
Re: Final as default modifier for method parameters:
"I make it part of my coding style now to use the final modifier on all method parameters. Yes it does lengthen the parameter code a bit but I have found the benefits are worth it. While I do agree that the value of method parameters should not be modified, a language change to accomodate enforcing this IMHO would not be worth it. A very useful tool to enforce this coding style is CheckStyle. It has plug-ins available for most popular IDEs and build systems (Ant, Maven, etc.) and I have set it up so it flags any non-final method parameter as a problem (it shows up as a warning in the IDE). This is very valuable for enforcing this style, expecially when I started coding this way and would forget to make method parameters final half the time."

Swing/JSP Compatiblity, smartinumcp writes:
"Has any project given serious interest to developing a standard to allow client and web based versions for JSP and Swing. The current frameworks (struts, spring) actually push more work on the developer for the front-end then supporting multi-client environments. Our XML configuration seem targeted towards the server and persistence layers. Without a true standard at the HTML and desktop client level we will still remain bound to manual writing or rewriting code. I recommend Sun takes some of the lead on this to combat one of .NET's key strength and to keep the maintainability of our code for future iterations."

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The continuing consideration of our intellectual successors.