Topic Archive: Java

JSTM for GWT: An Interesting Solution for Object Replication and Synchronization

Dietrich Kappe, Friday, April 18, 2008 @ 3:00 pm

Didier Girard, the peripatetic publisher of onGWT, read my post yesterday and pointed me toward XSTM, the open source OO distributed object cache. It has Java, .NET and GWT implementations that can interoperate.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

GWT 1.5: Get Ready to Fix All of Your JSNI that Uses long

Dietrich Kappe, Thursday, April 3, 2008 @ 12:58 pm

I've been humming along with GWT 1.5, reading the release notes and compiling from trunk. Today I had a nasty little surprise. All of my JSNI code that used long as either a parameter or return value stopped working. So, something like the following...

public native long method(long param) /*-{
   // do something useful
}-*/;

...would throw a nice little exception in hosted mode:

Return value of type 'long' is an opaque, non-numeric value in JS code
Parameter 'value': 'long' is an opaque, non-numeric value in JS code

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

QWT: Qooxdoo Web Toolkit

Dietrich Kappe, Friday, March 28, 2008 @ 3:39 pm

Qooxdoo is an Ajax framework that I haven't spent much time with, but after meeting the guys of Qooxdoo at AjaxWorld East and finding out that it's pronounced "guckst du," as in the German slang "Was guckst du?" (Rough translation: "What are you looking at?"), my interest has been piqued.

One interesting recent addition to qooxdoo is QWT, the Qooxdoo Web Toolkit, a Java to JavaScript "compiler" that works with the qooxdoo framework. I put "compiler" in quotations because, after looking at the code, it looks more like a Java to JavaScript translator. Also, where GWT has a hosted mode where you can debug in Java, QWT doesn't appear to have that feature, so debugging wonky QWT code promises to be a bit of an adventure.

Still, an community effort of this kind indicates that qooxdoo is a vibrant framework. I intend to give qooxdoo a closer look over the next few months.

Technorati Tags: ajax, qooxdoo, qwt, gwt, java

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Upcoming Talk at AjaxWorld East - Saving Your Investment: Transforming J2EE Applications into Web 2.0 Using GWT

Dietrich Kappe, Friday, March 14, 2008 @ 2:39 pm

For those of you interested, I'll be speaking at the AjaxWorld East 2008 conference in New York. I'll be looking at the messy underbelly of converting an old Web 1.0 application into a Web 2.0 powerhouse using GWT. From the conference blurb

The pressure is on to keep pace with Web 2.0 entrants into the marketplace. Rewriting is expensive; adding AJAX widgets results in a complex, unmaintainable application. Both require you to hire scarce JavaScript developers. Google Web Toolkit - the SDK that allows you to write AJAX interfaces in Java - enables your Java developers to layer a desktop-like interface on top of your web app. Learn to analyze the service profile of your application, to change HTML views into XML or JSON services, and to resist opening security holes by putting state and control flow logic into the client.

That's right, I've got 45 minutes to describe GWT, run through the steps for analyzing an existing webapp, give a quick demo, then talk about security and other concerns. No sweat.

Technorati Tags: ajax, conference, gwt

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Anti-patterns in Code: Ubiquitous HashMap

Ivan Moscoso, Monday, March 3, 2008 @ 12:27 am

This is something I consider an anti-pattern for parameter passing which describes both a specific data structure as well as the mechanisms surrounding its (ab)use.  It involves a way of modeling information where the semantics of the data may be dependent on disparate parts of the system.  There are other names I have given this pattern in the past, such as Great Big Bucket In The Sky, or Passing Parameters Under The Table, or Stuff In The Context Of Everything, or just Big Giant HashMap You get the idea.  I will describe a specific case, and then describe why I feel this approach is problematic.

First, however, a story that just so happens to be rooted in fact...

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

agile ajax

Grails and JSONP: How Easy is That?

Dietrich Kappe, Friday, February 29, 2008 @ 4:15 pm

For all of those Java developers casting longing glances at their buddies doing Rails development, there is hope. Grails, which has just celebrated its 1.0 release, is a Rails-like "convention over configuration" framework that aims to do for the Java world what Rails has done for Ruby. Instead of Ruby, the dynamic programming language of choice is Groovy, which compiles to bytecode (no Groovy to Java translation) and integrates smoothly with just about any Java code you may be using.

I'll stop hyping Groovy and Grails in general here; there's plenty of good informational stuff on the Grails and Groovy home pages. I will note that if you run off the tracks a little bit, you can find yourself reading through 500-odd line stack traces of Groovy, Spring and Hibernate -- there's room for some improvement there.

One of the many nice things about Grails is it's support for JSON and XML. Let me put together a simple example that shows off some of Grails' power.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

101 Ideas for JSONP - Idea #4: Scraping XML with XPath, Part 1

Dietrich Kappe, Wednesday, January 30, 2008 @ 5:35 am

It's been a while since the last installment of JSONP. Lots of good stuff has happened in the meantime to make our lives easier, but some things are still brutish, ugly and complex. One of the nice things in the more recent version of the JDK is the ever improving support for XML processing. Long gone are the days when you had to hunt around for libraries and hope that your version of the JDK worked with your third party libs. There are still reasons, like performance and extended features, that would cause you to pick an alternate library, but if you just want to add a little bit of XML processing into your apps, things couldn't be easier.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Markdown, GWT & Regular Expressions in Groovy

Ivan Moscoso, Friday, December 28, 2007 @ 8:41 am

If you haven't been able to tell yet, I like Groovy.

I was playing around with enabling some Markdown support in GWT (attempting to use Markdown-J from inside a TextArea instance widget).  Because Markdown-J relies on java.util.regex classes, it can not be invoked directly by GWT. I decided to take two approaches-- the first being to invoke the Markdown-J processor via an RPC call, and secondly to do it all on the client-side (which I will address later).

The first approach meant I could do some interesting things along the way in Groovy.  First off, I wanted to extend the Markdown processor to support table markup similar to, say, a FitNesse test (i.e turning markup like this):

|com.some.fixture.DummyTestFixturePlusOne|| input | expectedOutput? || 10    | 11              || 44    | 45              |

Into HTML output like this..

Or other alternate (possibly interactive) representations of tabular data using GWT, if you get my drift (but that's another show).

The implementation of Markdown-J is relatively straightforward.  It makes heavy use of regular expressions (java.util.regex can not be referenced by GWT), and thereby serves as a good illustration of the paradox of regular expression support in Java:  You can get the job done, but it's rarely nice to look at.  Groovy makes it so much better.  Here's my first attempt to extend Markdown-J's "MarkdownProcessor" class from a Groovy class.  Nothing special up my sleeve here.

class MarkdownProcessorWithTableSupport extends MarkdownProcessor {    private static final tableRegex = /\|([\d \w\.]+)\|[\n\r](.*\|)(?:[\n\r]?[^\|])/

    public TextEditor runBlockGamut(TextEditor text) {        TextEditor editor = super.runBlockGamut(text)        String content = editor.toString()

        content.eachMatch (tableRegex) { match ->            String headerRow = match[1]            String tableContent = match[2]            // do something with this match..        }        return new TextEditor(content)    }}

This is enough code to extract the first two match groups in the regex and start doing something with them.  The only real item of value in this class is the regular expression.  That regex took me a bit of time to nail down, so obviously it's rewarding to have it represented as closely as possible without any of the double-backslash marks you find with Java strings.  Notice that Groovy avoids the '\\' hell when describing regular expressions with it's "slashy" style strings.  'tableRegex' is still a String, you see.  But unlike the double-quote delimiter, the '/' delimiter allows things like unescaped backslashes.

Other than the regex, everything else in the code is rather boilerplate (iterate over each match, generate some HTML markup, yadda yadda... you get the idea).  Take note of the 'eachMatch' invocation on my String content though.  There's more going on than you might imagine-- Groovy actually takes the regular expression and compiles it down to a java.util.regex.Pattern instance before evaluating the closure.  Isn't that nice?  After all, it's what I would have done in Java anyway.

What's next?  I think it makes sense to try something like Showdown and bake it into a GWT component.  This will be my first attempt to integrate some existing JS library and see how nicely it will play with GWT.  Stay tuned.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

From the Grassy Knoll: Google Android Undermining Java ME

Dietrich Kappe, Friday, November 30, 2007 @ 10:58 am

The dudes at Java Developers Journal (JDJ, for you acronym hipsters) has always had a hard-on for conspiracies involving Microsoft and Java. "Embrace and extend" is a mantra akin to the Dalek's "Exterminate!" in their editorial corridors. Now they see a conspiracy in Google Android.

To put it bluntly, Android as it is currently defined is a fork of the Java ME platform. Android is similar to the Java ME, but it's a non-conformant implementation.  Android is not compliant with Java ME nor is it compliant with Java SE. In fact, it’s not really Java. Although it uses the Java programming language, the core APIs and the virtual machine are not consistent with the Java ME or SE platform - its a fork. This was first pointed out by Stefano Mazzocchi in his November 12th Blog entry entitled "Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME". Stefano missed the fact that Android does not properly implement the CDC or CLDC Java ME APIs ( a minimum requirement for Java ME conformance) - but kudos to him for being the first to report on the fork. The fork has since been picked up in the blogsphere by others here, here and elsewhere.

And this is a huge threat to Java ME, according to JDJ. I think the main takeaway from the article is "it's not really Java." The reasons why folks use J2EE, J2SE and J2ME are varied and don't necessarily overlap. If J2ME goes away, that won't really affect my decisions on whether to use J2EE.

Technorati Tags: ajax, android, j2me, google, microsoft, jdj

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Lessons Learned From Domain Modeling

Ivan Moscoso, Sunday, September 16, 2007 @ 9:43 am

There are many lessons I've learned as a result of working in a more domain-driven way.  My recent work on the UI front has highlighted a few ideas that are just as applicable to other areas of application development (outside the sphere of, say, modeling a complex domain).  Here are three things I believe developers should always keep in mind when designing or implementing code.

1. Hierarchies require coordination between their roots.
2. Uniqueness adds complexity.
3. Null holds meaning, but it's meaning will never be consistent.

Like learning how to write a good unit test, these are simple concepts to explain, but each requires patience and experience to understand really well. (a good pairing partner never hurts either!)

Hierarchies Require Coordination Between Their Roots
A graph of objects often needs to interact with another graph of objects, and while it is initially faster to build direct dependencies between members of each group in an ad hoc fashion, in the long run you benefit from controlling access to those members through the root of each group/hierarchy.  I see this as an extension to the principle of encapsulation applied to hierarchies of objects (ala: Law of Demeter). 

Consider the general case of one object acting as an observer of another.  If there are notable side effects in the handling of an event up or down the graph, it makes sense to put the root in control of the event.  Refactoring across the hierarchy become easier, adding additional behavior introduces fewer edge cases (thus reducing the need for more complicated testing), behavior more predictable etc-- the only exception (as I see it) would occur when the type of messages being passed around do not affect state at all.  Which brings us to our next point:

Uniqueness adds complexity
Stateless systems are invariably easier to grasp and comprehend than stateful ones.  While stateful systems have a temporal dimension to them which is largely absent in stateless ones, this is not the only source of such complexity.  It is the interaction between two or more stateful systems where we begin to see the huge cost in terms of managing complexity (recall your first experience debugging issues in badly written multi-threaded code to remind yourself of this).

This is why value objects are so important as a concept, and why their use is so prevalent in domain-driven design.  While the identity of a value object is determined by it's state, it's state is invariant, so it does not have to be managed the way an object with variable state needs to be managed.  But the use of VO's in domain-driven design is just one manifestation of the broader concept: always strive to reduce the number of parts in an application which rely on uniqueness (even if this requires a few more parts added to the whole), whether you are writing domain logic, UI behavior, etc.

The Meaning Of Null Is Never Consistent
It is easy to miss this point, as witnessed by how often I see code which uses null as a substitute for "I Don't Know...", "Shouldn't Really Happen...", "Just Satisfy The Compiler..." or "This Is A Placeholder".  In reality, null (or nil) is often employed as a mechanism for passing the buck to someone else.  Try as you might to ascribe a single meaning to it for all cases in your API, client code will feel free to redefine this meaning on a case-by-case basis, and its meaning will evolve (or devolve, as the case may be) into code which looks defensive, but behaves unpredictably.  Avoid returning null when possible-- strive for clarity instead.  While in other languages (such as Ruby) it is possible to add behavior to the concept of null, thereby making it's contract with the rest of the code a bit clearer, I'd still choose the alternative, and use something else.

That's it-- three little things that come in handy just about anywhere. My initial intent was to write a line or two for each section, but as you can tell, there is so much to say on each topic, and all of this just scratches the surface.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

JSR-94 - Getting Your Feet Wet

Dietrich Kappe, Friday, July 7, 2006 @ 10:08 pm

Over at the Sun Developer Network, you'll find a nice tutorial on writing a business rules application using JSR-94. It makes use of Jess rule engine for its example.

What is JSR-94? From the tutorial:

The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP)
program, defines a Java runtime API for rule engines by providing a
simple API to access a rule engine from a Java Platform, Standard
Edition (Java SE, formerly known as J2SE) or a Java Platform,
Enterprise Edition (Java EE, formerly known as J2EE) Java technology
client.

Beyond being useful in that the JSR-94 allows you to interface with any rule engine that supports the standard, it's also useful from a pure code reading perspective. Rule-based systems are different from OO and procedural systems; you have to think and design the applications differently. Reading the Java code of the example should give anyone who has never written a rule-based application a practical understanding of how these things should be built.

Give it a look and study the code. Of course, the standard doesn't solve all of your problems. While it does allow you to write one set of Java code to interface with any compliant rule engine, not all rule engines behave the same. More on that later.

• Digg
• Reddit
• del.icio.us

Comments (0)

business rules