Behind the Wheel
...of a nimble Java-powered robot
If you grew up wishing you could control "Johnny Sokko's Flying Robot" or the Wing Zero Gundam, and don't mind downsizing your ambitions just a bit, a pair of JavaOne contests have just the thing for you. The Robosapiens Developer Contests being held at JavaOne will let developers program the RS
Media Java ME powered Robosapiens robot from WowWee
Robotics. "The RS Media Robosapien robot provides a complete
multimedia robotic experience with the unique ability to be fully
customized and programmable. The robot is equipped with a head-mounted camera, a color LCD screen in his chest, a full speaker
system embedded in his armor. The robot is capable of playing MP3,
taking and displaying photos and videos, recording and playing audio
clips, and comes with Java games."
For those ready to program the robot, two contests are being held. The first is The Dance Contest, where the goal is "to create a midlet that successfully integrates original choreography, utilizing the robot's movements, with crowd-pleasing music. Dance moves are limited only by physical constraints of the robot." The second is The Escape Contest, where you need to "create a midlet that uses all of the robot's sensors and systems to enable the robot to escape the "The Room of Doom," which is a 5' x 5' hexagonal shaped area with a red and white color scheme. The room's exit has a large red area which is recognizable with the robot's vision sensors."
How 'bout that: a dancing, trap-escaping, Java ME robot. All we need now is little missiles to shoot out of its fingers and we'll have total robot street cred.
Also in Java Today,
TheServerSide notes the conclusion of a series of blogs on the Top 10 Java EE performance problems. "For the last two and a half months, Vincent Partington has been blogging about the top ten Enterprise Java Application Performance Problems. [...] Now he wraps up the countdown with some conclusions about Enterprise Java performance in general."
The "Plugins" tab on the NetBeans home page now takes you to the newly implemented NetBeans Plugin Portal. You can use the new NetBeans Plugin Portal to add your own plugins, comment on plugins, rate plugins, and add the Plugin Portal as an Update Center to your NetBeans IDE.
More details about the new portal are available in NB Evangelist Dave Botterill's blog Check Out The New NetBeans Plugin Portal.
In today's Forums,
rickcarson follows up on an open question from yesterday and makes the case for Jini in
Re: Java Cluster, whats the best way?
"Jini is a really good way to do a clustered supercomputer. What you do is on each of the computers you put a Jini client. Then you expose a Jini service. What happens is that the client goes to the service and asks for work. The service gives it some work to do. The client does the work. The client goes back to the service to ask for more work. Jini is nice in this case because it has the concept of expiry. Eg if one of the clients bursts into flame its lease will expire, and the service can figure out that if the lease expires whatever piece of work it last handed to that client needs to be handed to a different client. Moreover, real users can be using the computers for other stuff, and you can run the Jini clients highly niced and in the background, just using the spare cpu cycles without stealing from the users."
Joe Shevland offers a reality check on JPA annotations in
RE: EJBQL Exception.
"I'd say though the cases where you don't need to define a property->column mapping are pretty rare (almost restricted to tutorials and shallow examples I'd say) - all projects I've worked on to date have either had a legacy database, or a schema that's being dictated by DBA's/database standards for column names etc. A JPA-generated database schema is probably not going to be very good if you don't use the Column mapping for things like length, nullability etc. Or on the other hand, you'd have getters/setters like getPrs_Fst_Nm() which I personally wouldn't allow in a codebase."
hunterpreports a seemingly pathological garbage collection problem in GC killing me.
"I have an app and GC is killing me. everything is fine until the memory reaches the heap then gc takes forever (while still applying load) and the app is completely unresponsive (up to 2 minute wait times). I thought the time ratio combined with incremental would collect more aggressively (i have lots of free cpu). But with the parameters below, for a 4 minute run, the jvm spent well under a minute GC before it hit the wall and blew up. FYI the PSOldGen space is where 75% of the garbage stays until the wall. I've tried the -XX:MinHeapFreeRatio=30 (instead of default 40) but no difference."