Posted by editor
on September 20, 2007 at 7:31 AM PDT
Why program in one language when you can use two? Also:
Feature Article: Scripting With Balance in Design and Performance
Java Today: Filthy Rich Clients review, HotSpot talk at Intel developer forum, and why RSS is bad
Weblogs: Open Source Mobile Conference report, data pagination in jMaki tables, and EclipseZone on NetBeans' award win
Forum Posts: jMakiEventListener, SwingX antialiasing, and markup design for Project Wonderland files
Why program in one language when you can use two?
Presumably, by this point, everyone's sufficiently comfortable with the idea of running scripting languages in Java, as formalized by Java SE 6's
javax.script package, that we can all look beyond the novelty of running a scripting language on the JVM and get into the bigger question of what you can do with this ability.
It's one thing to just run an application written entirely in another language in a JVM interpreter, like deploying your Ruby apps on JRuby. What's potentially more interesting is interspersing scripting langauges into your otherwise-Java apps where they make sense. Imagine, for a moment, that you have some part of your functionality where you look at it and think "I really wish I could use something other than Java for this." For example, if you needed to crunch some logic with a rule engine, you could use Drools, but you might also consider just switching to Prolog for that part of your functionality. A deeply recursive problem might be well-suited to LISP/Scheme. And I'm sure you can think of more examples, perhaps involving domain-specific languages.
But is there an art or a science to mixing interpreted languages into your Java code? Can you still maintain a clean, object-oriented design while adopting languages that lack Java's formalities? Scripting in Java author Dejan Bosanac dives into this question in today's Feature Article , in which he writes about
Scripting With Balance in Design and Performance :
When thinking about scripting languages in Java applications, two key questions come up: how it will affect software architecture and how will it affect performance. By keeping the design with interface principle at our focus and applying simple patterns shown in this article, we can successfully tackle both of these questions. The rest is left to you to choose what language best suits your programming needs, but also when and how much scripting you want to use in your projects.
In Java Today ,
InfoQ has posted a review and excerpt from Filthy Rich Clients , the new book by Chet Haase and Romain Guy. Reviewer Andy Roberts writes, "the term "Filthy Rich Clients" was only coined relatively recently by the authors to describe "applications that are so graphically rich that they ooze cool. [...] In short, they make users actually enjoy their application experience". With that in mind, the book goes on to explain how to utilise Java2D and Swing in order to enhance your desktop applications."
David Dagastine blogs that he'll be presenting a Sun HotSpot JVM Talk at Intel IDF today in San Francisco. "'ll be presenting tomorrow at Intel Developer Forum in San Francisco with an esteemed colleague from Intel, Kingsum Chow. The session is SSGS003: "How to Get the Most Performance from Sun JVM on Intel Multi-Core Servers"." Along with an overview of how HotSpot takes advantage of current and future Intel multi-core CPU's, the talk will offer "a look at how to select JVM parameters for your application to get the most performance, and at employing VM parameters tuning as a last resort."
The ever-interesting Bruce Eckel is back with a surprising criticism of one of the net's most popular standards, in RSS: The Wrong Solution to a Broken Internet . "RSS seems clever close-up, if you ignore the internet traffic increase issues. But if you look at the real problem, RSS is a workaround that just supports the existing problem: anonymity." He goes on to argue that the need for privacy prevents a far more efficient publish-and-subscribe model, and instead forces RSS clients to reply on inefficient and bandwidth-wasting polling.