But now the application needs to consume "third-party generated" HTML code too. And NetClue tends to stall the whole application when it encounters HTML it doesn't like.

So I'm looking for alternatives, pure Java ones preferred. What HTML renderes are available and what are the licensing options?

The Kitikat Java Framework is a powerful but simple Datastore processing framework.

A Datastore represents an in-memory copy of data. A program may retrieve the data from a data source, such as a relational database, manipulate the data and then propagate the updates of the data back to the original data source or to a different data source. Once the data is retrieved, it is a disconnected, data source independent version of the data. A change history of the data is maintained to provide dynamic updates to a data source and there are several levels of concurrency control provided for multi-user environments.

It goes on with a list of features, supported application servers and a quick start guide.

The most important thing this web sites lacks is the answers to questions such as

• Why should I want to use this software?
• What kind of problems does it help me solve?
• Why is it better than product X, Y and Z?

I'm pretty sure the developers of Kitikat know the answers. They must have thought of typical use cases and applications. It's a shame that the web site doesn't communicate it.

I don't want to pick specifically on the Kitikat guys. It's just that I read the blurb on the front page, scanned the documentation and went "Huh?". I'd really like to know what I could do with it.

Instead, the developers decided to evolutionary improve Ant 1.x.

Good read.

Surprisingly enough, the discussion is pretty civilised and lacks the typical "Sun will never get native fidelity right" and "Stuff like that makes my Swing application look unprofessional" posts.

Libraries for simplifying JNI

• Jace
• JNIWrapper
• NativeCall
• Noodleglue
• J2Native
• OOJNI
• xFunction

Java/COM integration

• com4j
• ComfyJ (spin-off of JNIWrapper)
• EZ JCom
• Interfacetool for Java
• J-Integra for COM
• j-Interop
• Jacob
• jacoZoom
• Java2COM
• Jawin
• JCom
• OLEJA

Of these toolkits, J-Integra and j-Interop stand out. They integrate Java with COM in pure Java. By talking to COM components over TCP/IP, J-Integra and j-Interop even work on non-Microsoft plattforms.

Special interest

There are various libraries available that provide access to specific functionality on Windows. Many of those could be replaced by the likes of JNIWrapper. Nevertheless, I included them for completeness.

• JNIRegistry
• jRegistryKey
• JMatLink
• JConfig
• JDun
• JFlashplayer
• JIEBrowser
• JTray
• Java Systray Manager
• SysTray for Java

Nota bene: I think it's pretty obvious that the Java community lacks creativity when it comes to product names. We really should stop naming our products "JSomething" or "Something4j".

Update(29.01.06): Included NativeCall and OLEJA.

Update(16.09.06): Included ComfyJ and j-Interop.

Since JNIWrapper is commercial, it's difficult to find help on the web. Their support is exceptional, but for getting in contact with other users, getting help or advice I prefer to use a forum.

Now they only need to support RSS and I'm lucky.

Update: I asked. RSS will be available in late August.

A woman, while at the funeral of her own mother, met this guy whom she did not know.  She thought this guy was amazing, so much her dream guy, she believed him to be just that!  She fell in love with him right there, but never asked for his number and could not find him.  A few days later she killed her sister. 

Question: What is her motive in killing her sister?

Give this some thought, before you answer. Then proceed.

I've already written about COM-Java-integration with JNIWrapper, my tool of choice. It's great to see more and more articles pop up about it. I guess it has to do with the resurgence of Desktop Java.

The tested class is a somewhat complex piece of code for managing X.509 certificate chains. It makes sure that the chain is valid, that every single certificate is electronically signed, that the certificates aren't expired. And that's what happened: one of the certificates used to test this class expired.

The worst thing isn't the time wasted while trying to debug the problem; it's that we can't use older releases as-is.

I wonder what I can do in order to avoid it in the future. The nature of the tested code, the test arguments and the environment might make it hard. I can't just create a new X.509 certificate during test setup as it has to be signed by a certificate authority.

Any of you unit test gurus have an idea?

OK, I can't prevent referer spam from hitting my site. But I can filter the log file later. Derefspam does exactly that. It cleans the log file using the blacklist maintained by MT-Blacklist. It works surprisingly well.

Articles

• Update distributed applications - Article at Javaworld comparing three solutions for auto-updating Java applications: Java Web Start, Quest DeployDirector and PowerUpdate.
• Make Applications Update-Aware - Employ Java Web Start to place JAR files on a web server to facilitate error-free update

Solutions

• Java Web Start
• ZeroG PowerUpdate
• InstallShield UpdateService
• Quest DeployDirector
• AutoUpdater
• stableUpdate
• Java Application Update Utility Software
• JRunner

Most of the comments and several emails suggested Java Web Start. I still don't know enough about it. Most of our users don't have Java installed. To take care of that our application comes with it's own JVM.  It is private and not registered with the system. I have no clue how to integrate that with Web Start/JNLP. The FAQ doesn't help.

Anyway, next step: evaluation.

We develop in Java; the applications are deployed using a traditional graphical installer. When we need to deliver bugfixes, we  use a simplistic approach:

The command compares two directories and adds every differing file to a zip file. Later, this file is wrapped in a self-extractor and sent to the customer. Of course, this works only if the new release doesn't contain any incompatibilities.

In the foreseeable future, we need to deliver more complex updates, possibly introducing changes in the data format.

So my questions are:

• How do you manage changes and incompatibilities?
• Do tools exist that support the process or automate it?
• After you've identified every change that needs to make it into the update, how do you deliver it?
• Besides Webstart, are there any Java-based solutions available for automatic updating?

Every hint is appreciated.

Not that I care about stuff like that, but I'm pleased he asked for permission. It shows that these guys are careful when it comes to taking code from the net -- even if it's just one line.

Update:

I was a bit lazy with error handling. Usually, I'm totally not like that ;-). Thank you, Peter, for reminding me in the comments that listFiles() can return a null value.

I should turn this into a series.

Der ideale Kandidat hat

• mehrere Jahre Erfahrung mit J2EE-Applikationen (JSP, Servlets, Enterprise Beans, JMS)
• mehrere Jahre Erfahrung mit Entwurf, Entwicklung und Optimierung von Datenbankanwendungen. Von Vorteil sind Kenntnisse in der Datenbankprogrammierung unter Java mit JDBC und OR-Mappern wie Castor JDO oder Hibernate.
• Routine im Umgang mit XML-Technologien: XML 1.0, XSLT, XML Schema
• gute Englischkenntnisse

Bonuspunkte gibt es für

• Kenntniss weiterer Programmier- und Skriptsprachen (C/C++, Python, Perl, Awk, Shell)
• Erfahrung mit JBoss und PostgreSQL
• Praxis im Umgang mit alternativen Frameworks zur Entwicklung von Webapplikationen, insbesondere ZOPE

Mein persönlicher Favorit hat außerdem eine schöne Musiksammlung.

Wir sind eine kleine, knuffige Firma mit Sitz in Berlin (Mitte).

Interessenten können mir eine Email mit den üblichen Bewerbungsunterlagen im PDF-Format  senden; ich kümmere mich um die Details.

Dear English reader: my employer looks for an experienced Java developer in Berlin/Germany. Should you  know someone, please refer him to me.

I have started developing a windows application in C# using the express c# visual studio ide. It is a simple application, similar to many chat clients. While I can do all the logic and lay out components on the GUI, I'm horrified at how ugly it looks! I've done a small number of GUIs in Java as well, but there are some very nice L&Fs for Java which turn an average GUI into something nice ...

So what is it with us Java developers?  We always whine about the lousy looking desktop applications; at the same time, .NET developers are jealous of our variety of look and feels.

Something is wrong in Javaland.

Execute this code on a full disk (on Linux/Unix, you can simulate it with hard quota):

FileOutputStream ostream = new FileOutputStream("out");
ostream.write("hello".getBytes());
ostream.close();

No exception is thrown. All you get is a zero-byte-sized file. I don't know about you, but this is not what I expected.

After hours of googling and searching the bug parade, I found a workaround based on FileDescriptor. Every FileOutputStream has an associated file descriptor. With it's sync()-method, one can force all system buffers to synchronize with the underlying device. The following code -- executed on a full disk -- raises a SyncFailedException:

FileOutputStream ostream = new FileOutputStream("out");
ostream.write("hello".getBytes());
ostream.getFD().sync();
ostream.close();

I don't know the performance implications yet. But I'd rather suffer from a small performance loss than from data loss.

One thing, though, I have to admit: even if it makes my software look bad, bugs like 4338871 on bug parade have a certain beauty.

Adobe Reader ships with an ActiveX control. It is normally used for displaying PDF files in Internet Explorer. Since ActiveX controls are embedable, I thought I might use it to print PDF documents from Java. Embedding is easy-- just use JNIWrapper:

Via the magic of OLE automation, the program opens and prints a  file with Adobe Reader (see method printFile(...)). It actually looks like an easy thing to do. Unfortunately, the devil is in the details:

1. The line _container.createObject("PDF.PdfCtrl.5"); works only with Adobe Reader 5. Sometimes, but I can't exactly say when, it also works with Adobe Reader 6. But in order to be sure, you have to call  _container.createObject("PDF.PdfCtrl.6") as well. In versions 5 and 6, the control understands the same messages. Why Adobe chose to name the controls differently, I don't know.
2. When the document contains more than one page, the print dialog automatically selects the Option "Print Pages 1 to 1". There exists the option "Print All", but there's no way to select it via OLE. The user has to do it manually. Urgh.

3. Theoretically, one could circumvent the above by using the method "printPages(from, to)". With Adobe Reader 5 it works as advertised: it prints the selected pages without showing the print dialog. With Adobe Reader 6, though, the control displays a warning "Attention: some script wants to print a document. It might print the whole document." (I'm paraphrasing, as I only know the German message).

   What the ...? I mean, if you don't want some external process to do something with you, don't expose the method.
4. Since Reader 6 is such a moloch, Adobe changed the semantics of object release. With OLE objects, you have to do explicit reference management: if you acquire an object reference then you also have to release it. With Adobe Reader 5, the acrord32.exe disappeared from the process list after the object reference was released. Now, it doesn't. Reader 6 uses about 35MB and the only ways to close it are to kill it or open the Adobe Reader program and close that. That takes care of the acrord32.exe instance.

That's it from the top of my head. I fought a week trying to force my will upon Adobe Reader 6. I'm at a point,were I hate that software with passion.

Summary: What looked like the perfect solution to printing with Java under Windows, turned into a week-long debug fest with questionable results. Adobe Reader 5 worked flawlessly. My main gripe is version 6. It is completely screwed up.

The nice article about the deployment of client-side Java applications by Keyboardsamurais reminds me that I wanted to warn of ZeroG's InstallAnywhere.

On paper, InstallAnywhere looks like the perfect solution for all your installation needs; but if you look closer it's full of bugs -- from small and subtle to downright embarrassing.

The feature list:

• Extensive platform support. It runs on all major platforms, including Linux, Windows and Mac OS X
• GUI designer
• Localizations available for 29 languages
• Platform integration: installers create aliases, shortcuts, and links, execute platform-specific executables, install to system-specific locations (such as the Windows Start Menu or the Mac OS X Dock), register OS-dependent libraries,  manage Windows Services and read/write from the registry.
• LaunchAnywhere: native launcher for applications on all platforms
• Automatic Java VM installation
• And more

Let's start with the file format and parser -- one of the embarrassing bugs. Up to InstallAnywhere 5, InstallAnywhere projects  were renamed Java class files. With version 5, they decided to store the project information in XML. It was promoted as the ideal solution for hand editing, XSL transformations etc. But while the format is XML it is still a meaningless externalization of InstallAnywhere's internal object representation. The structure is undocumented and unreadable. But you'll learn that they use java.util.Vector a lot.

The file parser is a complete nightmare. Some genius decided to write the XML parser inhouse. He must have been under the impression that all the complete, fast and correctly implemented parsers out there aren't good enough. The result? You're in trouble if you use XSLT to make changes to the project file. For instance,  it is valid to have more than one CDATA section:

<tag><![CDATA[Two]]><![CDATA[cdata sections]]></tag>

InstallAnywhere's XML parser can't process that. It may look stupid, but it's coming out of XSLT processors. That means you not only execute a simple XSL transformation; you must perform complex text transformations with sed or Ant as well.

On Windows, InstallAnywhere can register services. Of course, it only covers the basics -- registration of the program, start mode and a description. More complex things, such as dependencies, are not implemented. So if you're service depends on another service your out of luck. Unless you read the stuff up and write the needed registry keys yourself.

It's the same with the uninstaller. InstallAnywhere can create an uninstaller and register it with the Software applet in the Control Panel. The applet supports individual icons for uninstallers. But with InstallAnywhere it displays a generic, ugly icon. Either you accept it or set the registry key by hand.

Sorry, but that's exactly the kind of know-how that I don't want to have.

Installer localization is another pet peeve. The quality of the translations is good. Also, you can customize them in the designer. But only for English. If you need to customize another language you have to edit a property file. As all of our installers are currently in German, we edit that file a lot. To make matters worse, InstallAnywhere likes to overwrite that file from time to time.

What really upsets me is that the localization file contains more than just language. An example: you can create new text files from the installer. We use it to create configuration files. The content of those files is also stored in the localization file. It took me a couple of days to figure that out. I was changing something in the designer, but the installer never executed it. It turned out that if you change the file's content in the designer, it only changed the English localization file.

I could go on and on. Work with InstallAnywhere has never been pleasant but often surprising. If your in the market for a cross-platform installer shop around. If you think, InstallAnywhere suits your needs, download the evaluation copy. It's unrestricted in functionality. Don't buy before you completely implemented the installer and are ready to ship.

The experiences above were made with InstallAnywhere Enterprise Edition 5.0.7. We never updated to version 6. It's too much hassle for way too much money.

My friends Michael Hauf and Daniel Schulz contributed to this post.

Update (14.12.2007): I got contacted by a representative of Macrovision, InstallAnywhere's producer. He assured me that the current version, InstallAnywhere 2008, has improved a lot. Unfortunately, I don't have the time to review the new version. I suggest you download the evaluation copy and try for yourself.

When we bought InstallAnywhere 3 years ago, we thought we had to support lots of platforms but then only shipped on Windows and Linux. Today, we use NSIS on Windows, which is a great open source script-based installer. Our Linux users are either sophisticated or have administrators: We send them tar files. In case you need to support more than those two platforms: I've heard good things about install4j although I haven't used it so I don't know if it's true.

In any event, I still stand by my suggestion made in 2004: Regardless of the installer you'll choose, implement it completely using the evaluation version and don't buy before you're ready to ship.

Java and Desktop/Platform Integration -- Blog that lists APIs and possible use cases for desktop integration that go beyond what J2SE offers.

Flying Saucer: The 100% Java XHTML Renderer -- Beta 3 was published a couple of days ago. Check out the impressing Webstart demo. You don't expect that from a Java desktop application.

Via freshmeat.net and JavaDesktop.

Keyboard navigation in itself is not bad; it's Diego's unique setting that makes it problematic. First, he seemed to have a huge list of entries and hitting a key pulls thousands of objects from the database. Second, that happened when he hit the Del key. The implementation of JList is obviously not optimal:

• It does not filter non-printable characters.
• It's difficult to customize: The KeyListener of JList's UI implementation is created in a private method and calls back into JList's getNextMatch(String prefix, int startIndex, Position.Bias bias).

The mechanism in JComboBox is cleaner: for keyboard navigation one supplies a JComboBox.KeySelectionManager, which hides the navigation logic (the default implementation evaluates only one keystroke).

That JList and JComboBox implement the same feature using different mechanisms is a bit puzzling. Especially if you know that JComboBox uses a JList internally. One thing is scary, though. The JList instance used inside JComboBox's UI delegate still has the it's own KeyListener for navigation. The only way to remove it, is to inherit from BasicComboBoxUI, overwrite createList() and use Diego's trick.

I still find that keyboard navigation is a feature not a bug. Diego complains that this functionality is too dependent of the storage mechanism. In my opinion independence of the storage mechanism is provides by the means of ListModel. Combine that with JComboBox's KeySelectionManager and you have a pretty generic and easily customizable solution. JList's implementation is stupid, I agree with that.

At the core, the JNIWrapper simplifies accessing native code. This is done via a dynamic invocation interface. It is well designed and easy to use:

public class ShellExecute {
  private static final FunctionName SHELL_EXECUTE =
    new FunctionName("ShellExecute");

  public static boolean execute(String file) {
    Function shellExecute =
      Shell32.getInstance().getFunction(SHELL_EXECUTE.toString());
    Int32 ret = new Int32();
    shellExecute.invoke(ret, // return value
                        new Parameter[] {
                          new Handle(), // hWnd
                          new Str("open"), // lpOperation
                          new Str(file), // lpFile
                          new Str(), // lpParameters
                          new Str(), // lpDirectory
                          new Int32(1)  // nShowCmd
                        });
    if(ret.getValue() <= 32) {
        System.err.println("could not execute ShellExecute: " +
                           file + ". Return: " + ret.getValue());
    }
    return (ret.getValue() > 32);
  }
 
  public static void main(String[] args) {
    ShellExecute.execute("http://weblog.janek.org");
  }
}

The code uses Window's ShellExecute function to open my weblog in the Windows standard browser.

On top of JNIWrapper, they implemented WinPack. Just as examples, here's what can be done with it. In my applications, I use it to

• embed Adobe Reader and Flash Player using COM automation,
• provide a Trayicon,
• open URLs in the standard browser (see above), and
• respect internet settings, such as http proxy and automatic dial-up.

JNIWrapper's latest project, JExplorer, provides a Java API for embedding Internet Explorer. It closely resembles theWebBrowser control API. Integration with Mozilla is on the way.

Their support is exceptional. Wenn JNIWrapper 2.4 came out, I discovered a bug on Windows 98. It was fixed in less than an hour. And when you look at their prices, you'll find that the product is downright cheap. A Linux version of JNIWrapper is available as well.

Rickard, if you happen to read that, could you post the size of the database, memory requirements and execution time of the conversion? Just curious.

The user issues a long-running command and the GUI sends it to the command queue. Other threads receive the command from the queue, compute the result and update the GUI through calls to SwingUtilities.invokeLater().

So far so good. For me, the surprising part is his choice for a message bus. David uses Somnifugi, a single-JVM JMS implementation. The obvious choice for me has always been the standard extension API InfoBus. Despite it's relative obscureness, it's the best tool for event-driven programming inside a JVM that I know.

Of course, with InfoBus producers produce data items and consumers process them. But there are APIs that make InfoBus special:

Producers can revoke data items.

Great when the data becomes invalid. 

Consumers can act.

That means, instead of only waiting for event arrival they can request a data item. This can prevent race conditions when the consumer is constructed later than the producer and misses the initial event.

An InfoBus can be guarded.

Whenever a data item is published the a guard can decide what to do with it. This could be used, for instance, to enforce execution order.

All in all, it is a complete API for loosly-coupled component interaction in a one JVM. I believe stock JMS does not address all of it. But then, I might have missed something when skimming over the specification.

• Roxes Ant tasks, which provide several ANT tasks that can create native executables for Windows, MacOS and several Unixes, read and write registry keys, create shortcuts on Windows and KDE and much more.
• JNIWrapper your one-stop-solution to desktop integration on Windows. It makes writing JNI code for Win32 very easy. JNIWrapper ships with the WinPack library, which allows the programmer to
• • open native dialogs (color, file and folder chooser),
  • create transparent, custom-shaped native windows,
  • read and write the registry,
  • access shell functionality (systray, shell folders, system colors and symbolic links),
  • access system services and
  • embed OLE components, such as Adobe Reader, Internet Explorer, Flash player and MS Office applications.
• Kai Toedter's JCalendar calendar beans
• IconExperience a repository of great looking, consistent, reasonably priced icons

I also learned about several new Swing components in the components category. Some of them look pretty decent.

Since it is obvious that a single person can't develop a web browser by himself, he made an intelligent decision: cut the crap. Flying saucer won't be a browser. No bookmarks, history, javascript. It will support XHTML and CSS only. He reasons: "Since this is for embedding in my own programs most of the content will be generated by my own code. I don't need to deal with every browser bug and every malformed webpage out there. I could get by with strictly compliant pages and worry about quirks handling in a compatibility library.".

A prototype is available.

About JDIC's web browser control he writes

The reference implementation uses Mozilla, but why use HTML when you've gone tot he trouble to write a Java GUI? Oh yea... Ads.

I maintain an application for exchanging business documents, such as orders or invoices. It is a desktop application with the classical three-pane layout. For document viewing, I transform the documents to HTML and display them. And that's where pure Java sucks. Three years ago, when development started, I had the following options: JEditorPane, IceBrowser and NetClue. JEditorPane is horrible and IceBrowser prohibitively expensive. So I settled on NetClue. NetClue has it's own issues and, as it seems, has turned into abandon-ware. It has not been updated in years; emails aren't answered. At this point, JDIC's web browser is a great alternative. While it's not pure Java, it's cross-platform enough for my taste.

JDIC has APIs to associate programs with file types. Danno's comment

Just what Java needs, more "JNN is not registered as the default News Reader, would you like to register it now?" dialogs.

is funny. But then, noone forces you to misuse the API. I don't think that associating an application with it's file type during install time is a bad thing. I could see JasperAssistant use this API to associate itself with *.jasper files.

JDIC ships with a tool for putting JNLP applications into installable packages. Danno:

Clicking on a link in the platform native web browser must still be to hard, wizards are much easier.

Yes it is. I have users, who are pretty computer-illiterate. Sometimes they don't even know how to move a window. No kidding. For installation, we couldn't point them to a URL and tell them to click that link. The webstart method of installing software is not going to cut it. They don't have Java installed. It wouldn't work for updates either. Some of the users are, for whatever reason, unable to download updates from the web site. I actually have to ship the CD and tell them to shove it in the CD-ROM and push the "Next" button until the update program is finished. I don't know why, but they manage to do that. The wizard interface works wonder, it seems.

Danno comments:

They are also looking at adding screen savers.

This is silly, indeed.

map.put(key:foo.getId(), value:foo);

or this

map.put(value:foo, key:foo.getId());

It's something that's been available in Python. I have to admit that named parameters have charm. But while I like Python, I don't use named parameters. I'm with Cedric on this one. Named parameters become part of a methods signature. This is bad because a name change of a single parameter breaks compatibility. Besides, there are alternatives that don't require changing the language.

Read the discussion over at Cedric's to get the full dose.

• embed a HTML renderer,
• send an email through the standard mailer,
• open and print documents using their associated standard application, and
• open a URL in the standard browser.

It's about time!

In his article on java.net, Joshua Marinacci tests a couple of open source HTML renderers. The situation seems to be as it was four years ago: the pure Java renders can handle only simple pages.

JRex, on the other hand, handles almost any webpage as it embeds Mozilla. Check out the screenshot:

While this solution is not Pure Java, it's crossplatform enough for my taste. I'm sure, customers don't mind either.