Skip to main content

Change of Heart

Posted by editor on June 4, 2007 at 5:35 AM PDT


Google Gears and its Java-based alternatives

So, one of the big announcements last week was Google Gears, which allows web applications to operate in an offline mode. It does this by installing a local database server (SQLite) and a browser extension that offers a JavaScript API to interact with the database.

Because of its use of a browser extension, it is limited to a specific set of browsers and operating systems: currently Firefox and IE on Windows, Mac OS X, and Linux. Presumably, the SQLite install would also require admin privileges. (fact check me on this, someone, please? Also check if Gears' Linux support is Intel-only? Thanks.)

Surely, I can't be the only one thinking... maybe y'all could have done this in Java? Using an applet-embedded database like Derby / JavaDB would offer zero install hassles and not present any concerns about native-OS compatibility. Java would also be compatible with more browsers and OS'es on Day One than the native browser plug-in will probably ever be. And as noted in last week's feature article, applets can be used to maintain state for webapps, even surviving refreshes and page-closes. Setting aside the sometimes iffy nature of JavaScript-applet communication, this seems like a more compatible, lower-maintenance approach.

So how did this option get missed? As your editor often asks, "was Java considered and found lacking, or never considered at all?" This seems like a huge missed opportunity for our favorite platform, especially considering that Sun and Google have a partnership.

Google says "the company's long-term hope is that Google Gears can help the industry as a whole move toward a single standard for offline capabilities that all developers can use." My gut tells me that this arrangement has a "string, tape, and popsicle sticks" design smell that isn't going to hold up, but if that's true, maybe something else will succeed. After all, you can put an all-Java persistence solution to work today, and get to more browsers and operating systems.


Fabrizio Giudici has a different question about Google Gears in today's Weblogs. In

Provocation: with Google Gears, is it still a web app?, he writes:
"Google Gears is a new piece of technology from Google which, in few words, extends your browser with a local database (SQLite) and a JavaScript API that allows applications to keep a persistent state in the client. With this enhancement, e.g. Google Mail can keep a local cache of mail items that can be accessed when you are disconnected. Good. But - thinking in extreme terms - is it still a web app?"

Still on the topic of persistence,
David Van Couvering is
Looking for a few good datbase users.
"I will be conducting a series of interviews with database users to help me understand what database tools and cool features we should be putting into the next release of NetBeans (and beyond). Want to help?"

Finally, in
Woodstox rocks Glassfish v2, Santiago Pericas-Geertsen recaps the integration of the XML parser into GlassFish.
"This is a great example of how your opinion counts and how a community can work together to improve a product. We kept hearing from many of you about how good the Woodstox XML parser was, especially how well it performed. Your voice has been heard, Woodstox is now officially part of Glassfish and this is the story of how it happened."


In Java Today,

NetBeans.org and BlueJ.org are proud to announce the availability of NetBeans IDE 5.5.1 BlueJ Edition. The NetBeans IDE BlueJ Edition is targeted at teachers and students familiar with the popular BlueJ tool. The NetBeans BlueJ Edition helps you "make the jump" from BlueJ to a full-featured
IDE, either when your projects have grown too big to fit comfortably
into BlueJ, or when you want to use features such as code completion and
drag-and-drop GUI building, which BlueJ doesn't directly support.

Calling it "yet another hideous idea from the closures camp," Café Au Lait's Elliotte Rusty Harold dismisses Neal Gafter's thoughts about removing checked exceptions from Java in order to make closures easier to implement. In Voting for Checked Exceptions, he writes "can we take the idea of removing checked exceptions from the language off the table? They are far more important to developing reliable, comprehensible, robust code than closures ever could be."

This year's JavaOne slogan was "Open Possibilities." In the interview Open Possibilities, Artima asks Sun's JCP Chair Onno Kluyt to tell us about new possibilities that some Java developers may find surprising. Specifically, Kluyt describes three Java technologies that allow developers to build new kinds of applications.


This week's Spotlight is on the Blu-Dahlia project, a California-based users' group for developers of Blu-Ray Java applications, and applications for other GEM TV platforms, such as OCAP and MHP and GEM-IPTV. Like the nightclub in Raymond Chandler's 1946 movie, the Blu-Dahlia Java SIG is a place to exchange ideas and best practices among professionals. Blu-Dahlia intends to be an open group for the sharing of best practices in application development, including tools, techniques, frameworks, and shared code.


Windows-specific frustrations top today's Forums. tdanecito complains of a
Major issue with XP??
"I ran into a very interesting and frustrating issue with java and XP. For me I always get a unstatisfied link exception when calling loading a dll through System.LoadLibrary() where the dll references a delayed load dll such as the infamous mpr.dll where an export is missing. I have heard if you use the windows api call of loadlibraryEx() this should not be an issue but I suspect the System.LoadLibrary() does not do this thus fails although it should do this. The happens with all versions of 1.6 JRE. Any ideas?"

Meanwhile, tjquinn is struggling with locked files in
Re: Sun App Server 9.0_01 (build b14) Deployment (undeploy) problems.
"The forum and the issue list has numerous entries on this sort of problem - JARs remaining locked and thus causing undeployments or redeployments to fail. Ultimately this ties back to the Windows prohibition against renaming or deleting open files. Often in these situations the JARs are opened by class loaders based on the JDK's URLClassLoader (or that loader itself) which opens JARs to load classes and find resources but does not provide a way for the caller to indicate that it is finished with that class loader and, therefore, open JARs should be closed. The app server itself uses its own class loader for precisely this reason so that clean-up can occur."

Finally, linuxhippy is evaluating
DeflaterOutputStream vs. pure Java implementations?
"I am currently developing a client-server framework and I am thinking about compressing all Input/Output using DeflaterInput/OutputStream. I am a bit concerned about the native nature of Deflater/Inflater - and several performance related bug-reports surrounding it. Netbeans profiler also points to Inflater/Deflater as beeing a bottleneck, however I don't trust it given the fact I only compress about 200kB, the java-code generating those 200kb is quite complex and I only use default-compression. Have you used Deflater/Inflater or their wrapper-streams successfully in high-load, high-scale enterprise applications, or would you recommend using a pure-java implementations of a compression algorythm? How does it affect scalability? Does it use highly optimized native code - or would pure java implementations be almost as fast?"


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.


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 java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

Google Gears and its Java-based alternatives