Java in your hands

I've been giving some serious thought about buying a decent mobile phone (US: cellphone) with current Java capabilities. First of all, I started by looking at my local vendor pages and then looking for more detailed information about specific phones. It can be a lengthy process. However, since I knew I wanted Java capabilities, I wondered if the J2ME pages had more information and sure enough, they do. Here are some pointers I found useful that might get you started if you are thinking of developing for the increasingly powerful small devices via Java:

• J2ME package names, across all of the profiles of J2ME
• Combined with the J2ME survey article, you can orient on the different options (the graphic below comes from this)
• The J2ME Device registry is a great way to search for devices that offer the profile you need
• The J2ME FAQ - pretty darned useful
• The main Java Mobility page has all the other pointers you might need
• After you get an idea what you want to do and which profile you want to target, then you need some decent tools to get productive: NetBeans 4.0 includes the NetBeans Mobility Pack with support for J2ME development (MIDP 2.0 and CLDC 1.1, including code obfuscation, and it integrates with the J2ME Wireless Toolkit 2.2) - perfect

(2004-12-20 10:36:56.0) Permalink

NetBeans 4.0 kicks!

NetBeans 4.0 has gone live. If you are a Java developer, you need to give yourself some time to take a serious look at it. I just did and the uninstall for Eclipse is running as I write this.

Why? Because NetBeans 4 is a major release in every sense. The features summary tells the full story; 4.0 gives the demanding Java developer (and who isn't demanding?) a complete and current IDE...

• Serious usability enhancements - this is definitely not the NetBeans UI I used to know back in the 3.0 days
• Full Java 5 (Tiger) support - now I can really use all those productivity features
• Support for Java Mobiilty platforms - MIDP 2.0 and CLDC 1.1
• Refactoring capabilities (of course), but with real visibility and control

It still has the other features I want like CVS support and a Swing GUI builder, but one innovation I really like is the use of Ant to store and represent all project configuration. This means that as a developer, I can use the NetBeans IDE to create and build projects, but a release engineer can use the standard Ant command-line tool to build my project exactly the same way.

And it's nice to know that NetBeans 4.1 is already in EA1 quality with the final release due in April next year bringing full-featured J2EE support.

(2004-12-18 10:36:58.0) Permalink Comments [2]

Java and J# - serialisation is interoperable

Interesting to see an MSDN blog that claims to demonstrate interoperability between an object serialised by a Java app and a J# app de-serialising it. Sample code included. Of course you can't use RMI between Java and J#, but you could exchange the object via HTTP-GET, a message service (via JMS), web services or even the filesystem. It's not clear if there are limits to this interoperability, but it's an interesting achievement. I'm sticking with Swing for desktop apps so that I can use Java end-to-end, but it's nice to know there are some ways for a .NET client to interoperate say with J2EE.

(2004-12-10 08:23:34.0) Permalink

LizardTech choose Java for ubiquity

Another company announced a Java-based product just last night (and is choosing to open-source). LizardTech have created a very efficient readonly file format, particularly for geospatial and document imaging markets. They will develop a thin open-source viewer for this format, using Java to reach the broadest set of platforms. See the article on OSDir for more information.

(2004-12-07 01:52:39.0) Permalink

MediaFrame - Phat server, Smart client, All Java

The impending launch of MediaFrame has got to be interesting. It's a media streaming server (Mpeg-1, with Mpeg-4 soon) and a thin client with programmable UI controls (including a JavaScript API for browser embedding) - it's GPL, and it's end-to-end Java.

The impressive feature list, combined with the portability of Java sounds like a killer app as more of us get our music and movies from the network.

Read more about the launch and existing customers here. (2004-12-06 13:59:41.0) Permalink

Java Libraries for Web File Protocols (http, webdav, ftp)

I recently needed to develop a pure-Java prototype application that supported multiple web protocols. The JDK comes with built-in support that meet the needs of many application developers who primarily want to interact with web protocols using URLs (effectively the same way that a end-user uses a browser).

If you have tried the standard JDK libraries and you need more, the table below contains a summary of my brief investigations and the libraries I chose to use. You'll notice I favoured Jakarta's libraries - that's because they're generally very functional, well supported and they have open-source licenses that permit use and contribution by both open and closed source developers.

Protocol (spec link)	Information/Desired features	Suggested library
http	Features (and pointer to library comparison) Desired features HTTPS, HTTP proxy support Authentication (Basic, Digest and NTLM) Automatic Cookie response Connection timeouts	Apache Jakarta HttpClient - javadoc HttpClient implements the following IETF standards: RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 RFC2617 HTTP Authentication: Basic and Digest Access Authentication RFC2109 HTTP State Management Mechanism (Cookies) RFC2396 Uniform Resource Identifiers (URI): Generic Syntax RFC1867 Form-based File Upload in HTML
webdav	Features Desired features Versions Collections Properties Access control Locking	Apache Jakarta Slide (client) - javadoc - article
ftp (extensions)	Java FTP client libraries reviewed	Apache Jakarta Commons Net (FTP) - javadoc In addition to FTP, this library also implements FTP, NNTP, SMTP, POP3, Telnet, TFTP, Finger, Whois, rexec/rcmd/rlogin, Time (rdate) and Daytime, Echo, Discard.

If you want an abstract API that sits on top of other web protocols, take a look at the Filesystems API in the NetBeans Open APIs suite; the Explorer and Modules APIs also look useful. I hope to find some time to probe NetBeans in more depth one of these dark winter evenings.

I can recommend the Hamsam Instant Messaging API abstraction for Yahoo, MSN and AOL support. Smack completes the IM picture by providing XMPP (Jabber) suppport.

Finally, if you're looking for an implementation for another protocol, freshmeat "java protocol -GPL" is certainly not the worst place to start, especially if you drill-down further using the advanced search option.

(2004-11-29 10:38:54.0) Permalink

Design by Contract in C# and Java

A Microsoft labs project called Spec# has developed a pre-compiler for C# that supports the design-by-contract feature of Eiffel, and adds the capability of the C/C++ "const" keyword. Interestingly, the same post highlights a 3 year old project I wasn't aware of called iContract that provides similar features for Java.

A little background: 12 years ago (back when Bertrand Meyer was the god of Object-Orientation, when Bjarne Stroustrup was at best the regent to the OO throne, and Java was an inkling in James Gosling's eye ;) I sampled but never seriously used the Eiffel language with it's unique focus on design by contract. Eiffel syntax directly allows the constraints or contract of a method to be expressed in a literate natural style within the implementation code. At first glance, the pre-conditions ("require" keyword), post-conditions ("ensure") and invariants ("invariant") seem like they are analogues of C's "assert.h" or even Java assertions, but they are an advance in two main ways:

• they automatically appear in the documentation, which helps the caller of a method to know what they should provide (pre-conditions) what they can expect to happen (post-conditions), and what should not go wrong (invariants)
• critically, the contract expressed in a base class is inherited and enforced for sub-classes

All of these constraints can be removed from the compiled code; Java has one important advantage here in that the assertions can be enabled or disabled at runtime.

So Spec# and iContract have similar features. Where they differ is in maturity (iContract has been around since 2001) and in syntax:

• Spec# essentially uses the Eiffel syntax, but it adds some sugar in the form of the "!" beside the name of a method parameter which asserts (or "require"s) that the parameter may not be null.
• iContract uses javadoc extensions

The advantage of iContract's use of javadoc comments is that the constraints are naturally ignored by a regular compiler. This is nice as you can adopt design-by-contract on a specific sub-project without changing the build environment for any container project. It also means they can be easily included in the javadoc-generated documentation, or used as part of a compile-time step to add the assertions into the output code. Here's a quick sample for the sqrt() method (note the use of "return" to enable the method's return value to be part of a post-condition):

/**
* @pre f >= 0.0
* @post Math.abs((return * return) - f) < 0.001
*/ 

So iContract looks like it's worth trying. If you want a blast of nostalgia, you can program in Eiffel and target the JRE - the SmartEiffel project includes a compiler for Java bytecode. I haven't looked at it too closely, but if it allows you to use Java API's from Eiffel, it could be worth looking at.

(2004-11-17 09:02:50.0) Permalink

Java and open-source - to the point

Newsforge has an exceptionally insightful article on Java and open-source, from which I will just quote the conclusion:

Businesses and developers who fret about whether or not Java is or will become open source are missing the point. The free availability and near ubiquity of Java in the enterprise software market means that the open source software being created with Java is much more interesting than the open source status of Java.

Companies basing their business on Java software must have a well defined strategy about open source. A simple "ignore" or "accept" will not do. Companies as different as Sun and BEA see business value in open source, yet engage open source in very different ways. To succeed today, you must know how to match your business' value with the value of open source.

(2004-11-15 14:26:00.0) Permalink

More open-source capabilities for Java on the desktop

The Tiger release of Java just blew me away, but I'm always looking for even more ways to create portable Java applications that integrate really well with native desktops. Well, here's another one to add to that starter set of desktop Java components I described earlier.

Janel is a native Windows executable that launches your Java application jar using the JRE, classpath and other parameters described in a text properties file.

Two cool aspects to this approach:

1. Users launch a regular native application that could have it's own icon.
2. You don't have to write a batch or command file.

Now it would be really nice if Janel was available for other platforms (how hard can it to port the Win32-related code to Unix/X11?) and it would be even better if Netbeans could create a base Janel configuration file for you (the file may need to be modified at install time just to pick up a specific installed JRE). Then you could forget about writing platform-specific launch scripts for your Java applications, and commercial apps would no longer need their own launcher executables.

One tiny feature request: it would be nice if Janel had a configuration option to display a splash screen image (one that doesn't stay on top).

(2004-11-03 11:35:02.0) Permalink

Java and Desktop/Platform Integration

Ok, we all know that Java has the goal of enabling application portability to the most important platforms and devices, which in turn enables the largest possible market or user base for the application. But every now and again, I wanted to write a really slick desktop app that needed to do something on a platform that I could not do using a J2SE API. Shock, horror!

Although JNI is fine as a low-level universal bridge to native API's, it limits portability to the platforms supported by that native API. For those cases, it would be nice to have a portable Java API (perhaps not part of J2SE) but which includes appropriate a native backend "driver" to each of the platforms I need to integrate with (a little like Java Media Framework and its platform performance packs).

Well, the good news is that there are excellent solutions for many use cases, and there are some standard techniques for writing your own portable abstract API for use in your Java applications. I wish there was a good site to locate them all, but I don't know one - so I'd like to share a few of the best ones that I know about with you.

JDIC

The JDIC (Java Desktop Integration Components) project provides a set of independent API's under a common license (LGPL) and allow a portable Java application to use native features on many desktop platforms; your 100% pure Java code can:

• Launch or even window-embed a native browser (such as IE or Mozilla)
• Use the mailto: URL syntax to launch the desktop's registered mail application, open a Compose Mail dialog and set some attributes (subject, to, cc, etc.)
  
• Launch the desktop's registered handler application for a file type (such as a document or media)
• Register an application (such as your Java app) as the handler for a file type
  

The JDIC Packager is incredibly useful; if you create a Java Web Start (JNLP) setup to allow your application to be installed from any browser, you can use Packager to automatically create a native installer for Windows (MSI), Linux (RPM) and Solaris (PKG). Stunning stuff!

There are other JDIC projects in the incubator phase, including a Screensaver SDK (wrapper to allow a 100% pure Java screensaver to be integrated into the native screensaver system on Windows or X11 (Linux/Solaris) systems and the Tray Icon API (which appears in some respects to be even better than Systray for Java).

Java Service Wrapper

JDIC is far and away not the only resource for developers who need desktop integration. There is also the very useful Java Service Wrapper which can enable a Java application to:

• Run as a Windows service or as a UNIX daemon
• Re-start automatically if it terminates or hangs
  
• Have platform-dependent JRE configuration properties specified in a plaform-independent manner (using a configuration file), eliminating the need to write a platform-specific or path-dependent launch script
  
• Have its console output re-directed to a file or a system logger (Windows events or Linux/Solaris syslog)

While JDIC provides API's that  allow you to use features of the platform, Java Service Wrapper enhances your existing application to make it run better and more reliably on multiple platforms - very nice, to put it mildly.

OpenOffice.org technologies

Finally there are the OpenOffice.org technologies - UNO and the OfficeBean.

UNO (the ambitious acronym stands for Universal Network Objects) is a middleware for writing components or exposing API's that may be used from multiple languages, such as Java, C, C++, Python and even .NET-based languages. You can also implement components in most of these languages. The result is language- and platform-neutrality; component programmers can be productive in their favourite language, while application programmers can use those components in their preferred language. Whoohoo!

And the best part about the OfficeBean is that it is a component API written using UNO that allows an application to use or window-embed a pre-installed OpenOffice.org-based application, such as OpenOffice.org itself or a commercial product like StarOffice. UNO was designed to make it easy to add support for other languages simply by implementing a UNO Bridge.

Down to cases

Ok, so that's my shopping list of Java/desktop integration technologies - let's look at some use cases for these technologies; these are just a few that occur to me, using the example of writing a mail client using Java and Swing:

• you want to launch mail attachments using the standard registered desktop application (which could be native or Java) - simply save the attachment to a temporary file and use the JDIC-Desktop API to launch the app - job done
  
• you would like to give your users the option to use a full-power office productivity application to compose mail messages - you just need to write a simple HTMLEditorWrapper interface that can use either Swing's HTMLEditorKit or the OfficeBean - no problemo
  
• you want to render HTML mail messages quickly, but you also want to give the user full support for web standards if they need it; similar to the HTMLEditorWrapper you can create a HTMLViewerWrapper which can use the lightweight Swing HTMLEditorKit to display HTML, or you can use the JDIC-Browser API to embed the native browser in your Swing UI - quick and easy
• you want to be able to view document attachments right inside of your Java mail client; you can use the OfficeBean and OpenOffice.org-based applications to display Microsoft Office or OASIS Open Office (standard OpenOffice.org) documents - powerful

Roll your own Java/desktop integration API

I mentioned Java Media Framework earlier as an example of how you can provide a portable API that can use native components, but perhaps the best example of the right architecture is JDBC which provides an API for application programmers and an SPI (service provider interface or "plug-in" interface) that is used to develop installable drivers for different kinds of databases and/or platforms, including databases with native API's. Because each backend database (Oracle, Postgres, HSQLDB, etc.) is supported using an installable "driver", updates to the driver for a specific backend can be obtained or distributed independently of the wrapper/abstraction API and the applications that use it. Similarly, a Java/desktop integration API should consist of a portable abstract API, a mechanism for finding the installed set of drivers or plug-ins, and an SPI for writing and installing a driver. For example, the JDIC-Browser API could have one installable "driver" for Mozilla support, and another for Internet Explorer, etc; the best part is that the driver can be shipped with the backend (e.g. Mozilla) so that it is up-to-date, and because the SPI is Java, the driver can be linked reliably.

Epilogue

There are certainly more Java/desktop integration API's than I mentioned above. I'd like to leave you with some technologies and techniques for implementing your own portable Java abstract API.

• JOGL - an OpenGL wrapper technology used for example in Sun's Looking Glass project; JOGL is an example of a Java API that works with a portable native API; as long as the native API is feature complete and sufficiently portable for your needs, why not benefit from the RAD advantages of Java as a 100% portable application programming language and platform? (of course, Java has Java3D (now open-source) which is 100% portable and offers a very powerful model, but if you already know OpenGL top to bottom, JOGL makes good sense)
  
• com4j - a Microsoft COM API wrapper generator; alternatively you can use JACOB if you want to use only COM IDispatch interfaces and you prefer not to need generated code, and there are even more options listed on the Java/Win32 Integration resources page; com4j is not a portable abstract API, but it provides an effective means to write a Windows-based "driver" for a portable 100% pure Java abstract API
• SWT - I don't favour this technology because it attempts to solve a problem that's already solved in a 100% portable way by J2SE Swing; however, SWT's implementation approach (exposing the native windowing API via JNI using a 1-1 mapping to Java native methods) is worth considering as it has the advantage that most of the native adaptation code is in Java, although it has the disadvantage that it requires many fine-grained calls from Java to native code which impacts on performance

Hmm, that was a little more than I planned for one blog, I hope some of it was interesting to you.

(2004-09-10 01:06:31.0) Permalink Comments [2]