Netuality

Mr. Jesus M. Rodriguez asked fellow Java bloggers where are all those SWT apps. Here's a possible answer.

First, do not forget that Eclipse is a big ecosystem. There are a bunch of software development shops making a living from selling Eclipse plugins : Omondo, Genuitec, Instantiations, Exadel, etc. Add here the vast majority of the older/bigger tool producers (such as Borland/Together, Visual Paradigm …) which ported their products as Eclipse plugins. Count also important product suites from (of course) IBM (WSDD, Rational, etc.), (for sure) Lotus and (surprise ?) Novell and SAP. There is life in here and a great deal of it is due to SWT. There are a few strange Swingonian hybrids, but most of the plugins and products are purely SWT-based.

SWT is still young, so unfortunately there are only a few interesting opensourced projects based on SWT. Among them there's Azureus, a BitTorrent client which is consistently in the top 5 downloads at SourceForge. I have noticed an interesting fact : Azureus is THE ONLY desktop Java app (which is not an IDE or a development tool) and which I consistently find installed on different systems (friends, coworkers). Add to the list Sancho, a P2P multiprotocol client, SQLAdmin another rdb administration tool and RSSOwl plain simple RSS feedreader. These are all decent performing apps and their sources are ripe for grabbing and inspiration.

But this is just the tip of the iceberg. The Eclipse newsgroups are full of people discussing RCP development strategies and asking SWT questions. And – you know – they're not all unemployed ex-dotcommers with Yahoo emails. But let's not make speculations about people email addresses – let's just look at an interesting existing product : GDFSuite is a whole suite/platform targeted at geobusiness applications. In their presentation from EclipseCon 2004, Frank Gerhardt (SENS) and Chris Wege (DaimlerChrysler AG) shared a few development experiences related with GDFSuite rich client, built upon the Eclipse platform. I bet there are a few other important RCP-based products which will be announced during 2004.

Last, but not least, I have some personal experience to share as well. My current employer sells a production supervision tool targeted at food industry, with a SWT-based rich client. When I say “sells” I mean “already sold quite a few licenses and currently successfully installing at big customers”. The SWT-client is deployed in its Motif version on P3/500Mhz machines running Linux. It's fast and slick. It's not very aesthetically pleasing and you can not play Solitaire on it, but this doesn't seem to interest the guys cutting meat or the girls which are inspecting the barcodes on the package of your next 1.99$ steak. Some other SWT-based products are undergoing development in our Java department, but of course they are really really really secret, they will be announced as soon as they are ready and they'll kick some serious ass There are probably quite a lot of other companies capitalizing on SWT to make fast (or 'rich') clients for their commercial products.

Swing is beautiful. Swing is conceived with MVC in mind. Swing has Jgoodies. Swing is also slowly-moving and memory-bulimic. When all I have to do is a simple interface with a text displayed in big fonts and a “Print barcode” button, does it really have to pass through 10 nested layers of listeners ? What shall I do with Swing on a CPU-handicapped computer in production environment, where 200ms is considered a big delay ? But of course, if you want intellectual challenges and nicely architectured clients, go for Swing. If all you need is to be efficient and please the customer, take SWT for a ride.

I know, I know – I may sound like the VB advocates a few years ago. But it's not the point. It's a matter of doing the right compromise between a rich functional API and a simple fast API, between generalization and the need for custom coding. My opinion is that Swing has – for the moment – failed to reach the good compromise. SWT it's just the next candidate.

PS Jess is a dual-licensed inference engine for Java. The next version (7 aka 'Charlemagne') includes an Eclipse-based IDE. Unfortunately, not being a licensed Jess user I do not have access to latest beta versions. Maybe somebody could shed some light upon this question.

PPS There's some more stuff at SWT Community Page

PPPS A bit of history : Swing (JFC) was made public in april 1997. SWT became available to developers, along with the Eclipse donation, in november 2001.

According to David Heinemeier Hansson, the RAILS 1KLOC (!) web framework written in Ruby was used to develop Basecamp, a mildly complex project management webapp. What's fascinating is the Ruby code used to develop Basecamp is only 4KLOC (according to the RAILS document) and was developed in less than 2man*month (including 212 test cases and all the bells and gingles). Although I strongly suspect that there was a lot of templating going on behind the hoods and I doubt that template development time was included, the efficiency is amazing, especially if you consider that they have started almost from scratch. Makes you wonder what would be possible to perform in Ruby with a comprehensive library such as PHP's PEAR (well, duh, ignoring the fact that it should be called REAR which is a very very very nasty name) ?

My first contact with Tapestry was more than 18 months ago. Back then, I was interested to find a web framework for integration with our custom Avalon-based (using the now-obsoleted) Phoenix server*. The web interface was ment to be backoffice stuff, for simple administration tasks as well as statistics reports. Given that the data access and bussines logic were already developed, we were looking for something simple to plug into a no-frills servlet container such as Jetty. we managed very easily to integrate Jetty as a Phoenix service and pass data through the engine context. But when we finally integrated Tapestry [into Jetty [inside Phoenix]] and make it display some aggregated statistics, the project funding was cut and the startup went south. But, that’s another story and rather uninteresting one.

Meanwhile, things have changed a bit. Tapestry had become a firsthand Apache Jakarta project, the Tapestry users list is more and more crowded, and again I see it used in my day work (by Teodor Danciu, one of my coworkers and incidentally author of Jasper Reports) and doing some moonlighting by myself for an older web project idea. And there is exceptional Eclipse support via Spindle plugin. While the ‘buzzword impact’ on Tapestry on a Java developer CV doesn’t yet measure up with Struts, this framework has obviously gained a lot of attention lately.

So, what’s so special about it ? If I’d have to choose only one small phrase I’d quote Howard Lewis Ship, Tapestry lead developer, from the preface of his book ‘Tapestry in Action’:

The central goal of Tapestry is to make the easiest choice the correct choice.

In my opinion this is the weight conceptual center of the framework. Everything, from the template system which has only the bare minimum scripting power, passing through the componentized model, up to the precise detailed error-reporting (quite unique feature in the opensource frameworks world) gently pushes you (the developer) to Do The Right Thing. To: put logic where it belongs (classes not templates), organize repetitive code in components, ignore the HTTP plumbing and use a real, consistent, MVC model in your apps (forms are readable and writable components of your pages). You don’t need to be Harry Tuttle to make a good Tapestry webapp, just a decent Java developer is enough. That’s more than I can tell about Struts …

Coming from a classic JSP-based webapp world, Tapestry is really a culture shock. The most appropriate way to visualise the difference is to imagine a pure C programmer abruptly passing to C++, into the objects world**. For a while, he will try to emulate the ‘old’ way of work, but soon enough he’ll give up and start coding his own classes. However, this C programmer will have to make some serious efforts, not necessarily because OOP is hard to leard, but in order to break his/her old habits.

“Tapestry in Action” is your exit route from the ugly world of HTTP stateless pages and spaghetti HTML intertwingled with Java code and various macros. It’ one of the best JSP detoxification pills available on the market right now.

The first part of the book (‘Using basic Tapestry components’) is nothing to brag about. It’s basically an updated and nicely organized version of the various tutorials already available via the Tapestry site, excepting probably some sections in chapter 5 (‘Form input validation’). By the way, the chapter 5 is freely downloadable on the Manning site and is a perfect read if you want a glimpse of the fundamental differences between Tapestry and a classic web framework (form validation being an essential part of any dynamic site). However, if you want to go over the ‘Hangman’*** phase you really need to dig into the next two book sections.

The second section ‘Creating Tapestry components’ is less covered by the documentation and tutorials. I’m specifically pointing here to the subsections ‘Tapestry under the hood’ (juicy details about pages and components lifecycle) and ‘Advanced techniques’ (there’s even an ‘Integrating with JSP’ chapter !). While it is true that any point from this chapter will generally be revealed by a search on Tapestry user list or (if you’re patient) by a kind soul answering your question on this same list, it’s nethertheless a good thing to have all the answers nicely organized on the corner of your desk.

The third and last chapter (‘Building complete Tapestry application’) is a complete novelty for Tapestry fans. It’s basically a thorough description of how to build a web application (a ‘virtual library’) from scratch using Tapestry. While the Jboss-EJB combination chosen by the author is not exactly my cup of tea (I’m rather into the Jetty+Picocontainer+Hibernate stuff) I can understand the strong appeal that it is suppposed to have among the J2EE jocks. Anyway, given the componentized nature of Tapestry, I should be able to migrate it relatively easily if I feel the need for it. The example app is contained in a hefty 1Meg downloadable archive of sources, build and deployment scripts included.

To conclude, ‘Tapestry in Action’ is a great book about how to change the way you are developing web applications. The steep learning courve is a little price to pay for a two or three-fold improvement in overall productivity. And this book should get you started really quick.

*Which AFAIK is still used at our former customer.
**There were some posts on Tapestry user list on about a certain conceptual ressemblance with Apple’s WebObjects. I can’t really pronounce upon this because I do not know WebObjects, but the name in itself is an interesting clue.
***’Hangman’ is the Tapestry ‘Petshop’ (although there is also a ‘real’ Tapestry Petshop referenced in the Wiki).

One of my current responsibilities is to maintain an internally developed plugin, used by various members of the team to generate code from the analysis model. As far as I can tell by the webstats of the update site, every version is downloaded by 18 people, a small but heterogeneous user base.

My biggest problem is the Eclipse version. The analysts are not exactly Java geeks waiting anxiously for nightly builds of Eclipse, they use a 'standard' 2.1.2, mainly because it's stable and well internationalized. Things go wilder in the programmers team : versions ranging from conservative (2.1.x) to liberal (3.0M4) and even the occasional dumbass with the latest integration build (that would be me, of course).

The 'enhanced binary compatibility' in 3.0M7 came as a relief, diminishing the need to switch between Eclipse versions in order to develop the plugin or work on other tasks. Well, I still have to briefly test the damn thing on Eclipse 2.1.x before releases. However, running simultaneously two or three Eclipse instances is no piece of cake for my 512Mb laptop (I still haven't found who I have to kill here in order to be awarded a memory upgrade). Unfortunately, checking out the plugin source into M7 has shown the invisible ugly face of 'binary compatibility': the plugin doesn't compile.

There are just a handful of lines of code, some emphasizing differences in Eclipse API which are somehow hidden in 'compatibility mode', some effectively showing small bugs in plugin behavior. But the real issue here is that I cannot really develop the plugin in M7 until I manage somehow to compile it, while not losing downwards compatibility.

Let's dissect one of the compilation issues. The bummer concerns automatic opening of an editor (or focus if already opened) when clicking on its reference (somehow similar to what happens when you Ctrl+click on a class name in JDT). In the older API it was a question of page.openEditor(file); where page is a IWorkbenchPage and file is an IFile. This simple stuff worked well until 3.0M4, then (M5) things changed to page.openEditor(new org.eclipse.ui.part.FileEditorInput(file),editorId); where FileEditorInput implements (among others) an IEditorInput. While this is certainly nice because you may directly link editors to something other than files***, obviously the old code does not compile under M7.

Maintaining different projects for 'old' and 'new' style projects for 10 or so lines of code is obviously overkill. Second solution – via reflection, but it would mean more than few lines of code and the result would not exactly be comprehensible nor maintainable. Only thing left : use a scripting language.

Of course I could have taken any decent scripting language embedded in Java. Decision to go with Groovy was taken mainly because of its coolness factor, but I am sure the idea will apply easily with Jython (big favorite of mine) or the performance-aware Pnuts, for instance.

In a nutshell, you have to execute a line of code depending of the current Eclipse version (it's a little bit trickier, but we'll discuss later about it).

groovy.lang.Binding binding = new Binding();

binding.setVariable("page", page);

binding.setVariable("file", file);

groovy.lang.GroovyShell groovyShell = new GroovyShell(getClass().getClassLoader(), binding);

if (newPlatform)

{

	return groovyShell.evaluate("page.openEditor(new org.eclipse.ui.part.FileEditorInput(file),editorId);", someExpressionId);

}

else

{

	return groovyShell.evaluate("page.openEditor(file);", someExpressionId);

}

It's basically a vanilla flavored ripoff of the Groovy embedding example from the docs. The boring part : caching the binding, hiding everything behind a nice facade, is left as an exercise for the [interested] reader. Remember to pass the classLoader of the current class, do not create a GroovyClassLoader out of nowhere or you'll end up dealing with Eclipse own class loader, which means trouble for simple tasks like these.

How do we know that the Eclipse version is the 'new' or the 'old' one is not that simple because remember : 'old' means 2.x up to 3.0M4. So finding out Eclipse SDK version is not enough, you have to find out another discriminant which in our case is the 'org.eclipse.ui.ide' plugin. Result:

boolean newPlatform;

//find out if we are inside a new or an old platform

PluginVersionIdentifier pvi = Platform.getPluginRegistry().getPluginDescriptor("org.eclipse.platform").getVersionIdentifier();

newPlatform = pvi.getMajorComponent() >= 3 && Platform.getPluginRegistry().getPluginDescriptor("org.eclipse.ui.ide") != null;

No, we are not ready to deploy yet. A small trick has to be performed or the plugin won't start under older versions of Eclipse. We had to add some new plugins to dependencies (in the pligin descriptor) such as the aforementioned 'org.eclipse.ui.ide', obviously the older versions of Eclipse will not find it, hence block our plugin activation on startup. In order to overcome this, you have to add (by hand !) a lesser known attribute ('optional') in the corresponding tag from the plugin.xml file : <import plugin=”org.eclipse.ui.ide”/> becomes <import plugin=”org.eclipse.ui.ide” optional=”true”/>. Now, the plugin is ready to be deployed.

For those brave enough to dare distributing such a plugin via an update site remember to 'cheat' by not allowing new plugins such as 'org.eclipse.ui.ide' in the feature.xml file (again, delete by hand). The 'optional' attribute doesn't help in this case. Go figure…

I hope that some of you will find useful this recipe for maintaining compatibility between different Eclipse versions with minimum of fuss. However, please note the specific prerequisites for this type of solution :

• there are only simple 'few-lines' modifications
• the code is not expected to evolve a lot in the 'affected' areas
• the evaluated code is not in a performance-sensitive area

***Interesting enough, this was one of the reasons I recommended against adopting RCP in one of our apps, a few weeks ago. It's nice to see that – now – the mechanism linking editors and resources is MUCH more flexible. Anyway, this won't probably change the decision of not using RCP because the main issue it's the volume of code we have to change. Development of one of the app modules started almost a year ago and the animal it's already sold and deployed on different production sites: upgrading would be a real nightmare. Maintaining a fork of the app is not an option either. Well, I guess we'll just have to cope with 'plain old' Jface and SWT.

PS After some days of 'silence', I have noticed from the logs that most popular posts on my blog are those concerning Eclipse plugins and Manning books (I seem to have a nice Google ranking on these topics). So, expect more of these (I am reading the MEAP of 'Tapestry in action' – a review should be up shortly).

At first, this might seem a mind-boggling combination. What do
jython and PHP have in common (excepting the fact that I am a Python fan
and my current consulting task is in a PHP project) ?
Well, internationalizing a PHP app is pretty much a trivial task.
If you are a sensible PHP programmer insisting to use PEAR instead of randomly choosing a script from the tons of snippets
populating the “scripting websites”, I18N is probably the
safest choice.
Maybe – for you – application maintainability and performance are not exactly important concerns.
For me, they are. This is why I chose to store internationalized texts in files rather than database.
I'd rather keep the database for real data, which is created, modified, aggregated and such.
And I'd rather like to have an internationalized error message on the screen even if the database is down.
Now we know that we'll use I18N and text will be kept in some php files. However, I am no professional translator and
have no desire to translate or to manually maintain the correspondence between translators files and PHP files
(no, translators won't modify PHP code, stop this nonsense right away).
Code generation comes immediately in mind.
Basically, my first idea was to investigate wether the files used by the translators can be quickly transformed to PHP,
and if I am able to generate their formats from my own files (aka. “roundtrip internationalization process” ?).
Unfortunately, this is not an easy task – as the only clue was that the translators use Office tools such as Word or Excel, because they
rely upon some specialized translation software integrated with these products.
The easy choice is Excel, since it allows a better organization of data than having to search for tables in a Word document.
The hard choice is the tool that I'd use for automatically reading and even generating Excel files.

The difficulty comes from the fact I don't have Windows with Office installed on my desktop, just Gentoo Linux and OpenOffice.
Thus, I am unable to write a simple Python script which could perform my generation tasks via automation.
Fortunately, this is not the first time I am confronted with the issue.
I happen to know that there is a very nice Java tool that I wholeheartedly
recommend for your Excel processing needs :
JExcelApi.

Still, Java is a heavyweight programming language – it would be a really bad idea to fire up the

$messages = array(
'loggedin'=>'You are authenticated successfully as user %1$s with profile %2$s.'
);
$this->set($messages);

$messages = array(
'loggedin'=>'Vous avez le profile %2$s en tant qu'utilisateur %1$s.'
);
$this->set($messages);

#this is the multiple parameter function
function complexTranslation($i18n, $label, $params)
{
  return call_user_func_array('sprintf',array_merge(array($i18n->_($label)),$params));
}

#specific I18N initialization stuff
require_once 'I18N/Messages/File.php';
$g_language_dir = dirname($_SERVER['PATH_TRANSLATED']).'/localization/';
$i18n =& new I18N_Messages_File($g_langCode,$script_name,$g_language_dir);

#translate the successfull login message
$loginbox = Tools::complexTranslation($i18n,'loggedin',array($operator->name,$profile->description));

Currently developing Eclipse plugins, I am constantly searching for things on the net. Have to admit that PDE documentation is very scarce as soon as you enter into the depths of Eclipse such as tight integration with the search mechanism or extending JDT. Searching this kind of things, absolutely by pure chance I have found two not very known Eclipse plugins.

UrbanSim is a “software-based simulation model for integrated planning and analysis of urban development”, and it's an Eclipse plugin ! Something like SimCity for geeks, without the fancy graphics. You can only log different urban evolution data and subsequently process it with your own tools if you want to. For real fun, computed data can be extracted from the database (yes, you have to install MySql) and viewed with a GIS tool such as ArcView. Not valuable per se for us Java developers but : - all the code is downloadable (GPLed). Some of algorithms might be worth a look. - UrbanSim includes a suite of acceptance tests derived from the FIT framework. AFAIK this is the first time FIT is used in a large open-source project. - (their own) continuous integration system Fireman is also visible on the net. Hey, where can I download that ? A presentation of UrbanSim is in the program of EclipseCon 2004.

From the Collaborative Software Development Laboratory Department of Information and Computer Sciences, University of Hawaii, a plugin called Jupiter, which is described as “a code review plug-in tool for Eclipse to facilitate review process”. The plugin allows management of code annotations, storing “reviews” in an XML file, which can be shared with your team by CVS. This makes it much more than a code review tool, since it is quite possible to use the Jupiter “reviews” in order to share bug reports, enhancement requirements etc. What's interesting is that you can relate the reviews to specific Java code, this is a great feature; AFAIK missing from the mainstream issue trackers. A missing feature from Jupiter are issue metrics, but computing them from the XML files shouldn't be a difficult task. I see Jupiter more as a complement to traditional issue databases more than as a replacement, for different reasons: - is accessible only from Eclipse in Java development environment (would have been nice to be able to annotate other types of files) - in bigger teams, the XML files containing the reports are probably subject to frequent CVS conflicts - there is no review “history”, thus the project dynamics will not be available unless you process somehow all the CVS revisions of review files To conclude, Jupiter is somewhere between a smarter, enriched TODO with filters and a a poor man issue tracker. Worth a try. Also from CSDL, there is the Hackystat project which plays in a totally different league. Hackystat “provides automated support for collecting and analyzing metrics of the process and products of software development”. Technically, it's a server with a JSP frontoffice, aggregating data received via SOAP from various “sensors” installed in developer's tools : IDEs like Eclipse, build tools such as Ant, testing tools such as Junit. Something like a BigBrother approach for PSP, everything you do is tracked, measured and put in a chart or on a graph. I strongly suspect that this type of tools will soon be available commercially and used by management for performance evaluation of software engineers. NOT necessarily a good thing. Note that CSDL teams are using their own, inhouse-developed, tool for code coverage, JBlanket.

Last, week I got to visit Web Services & XML Integration Forum in Paris. It was an interesting day and I’ll probably come back with some more info, but for now I’ll just talk about what really impressed me. There was a nice triagle of expo booths somewhere in the ‘North-East’ area of the Forum, three little companies you might’ve heard about : Microsoft, Sun and Borland.

The difference was striking. Microsoft is by far more prepared for this public event. They weren’t using presentation rooms, but instead conferencing right there in the booth all day long (with a lunch break of course). Although the presentation rooms were at least 4 times larger than the space they prepared (3 benchesx2m apx), I think they’ve got the best coverage at the Forum. They and Adobe, but Adobe was slightly off-topic (PDF is king at Adobe, and for a reason).

Instead of using a classic projector, casting large shadows every time they wanted to point something on the screen, MS people installed a large (plasma, I think) flat-screen in their booth. They were the only ones I saw with wireless microphones, which gave them a lot of freedom to walk, wave hands and hypnotize the audience. But wait, there’s more … The Microsoft guys were talking “agile enterprise and processes” and one of them said once “you can put any backend database here, say MySQL for instance”. No, there is no confusion with “MS SQL”, the guy standing next to me was as stunned as I was. And to complete a superb marketing image, they wear no suits, no ties – everybody was relaxed and smiling. The only glitch was that the latest rage among MS employees seems to be cloning Bill’s haircut. I mean wake up guys, you can cut your hair in differents lenghts an shapes, you know…

Just a few meters away, in the much smaller Borland booth, there was also a plasma display. However, no real presentations showing. Just a loop of images, logos of products and the word SPEED written in large, red letters. Um, ok. After 30 seconds I had to walk, it was incredibly boring.

No crowd was gathered at Sun’s booth, neither. Some LCDs were displaying what looked like a non-interactive Project Rave demo and some screenshots of a Windows’look’alike Linux distribution, their famous Sun Desktop blabla whatever. WHY were they showing this at a Web Services & XML Forum ? But, probably Sun’s intentions were to scare away the visitors so they could watch undisturbed Microsoft presentations. In that case, they succeded extremely well. Plus, their unique positioning gave them a perfect view of the presentations – or was it Microsoft which strategically placed their flat screen in Sun’s direction ? Hmmm, makes you wonder.

Anyway, to conclude, I watched two Microsoft speeches (one about their Web services strategy and one about Biztalk). It was fun, it was interesting, it was well explained. But it was not Java – and I am a Java developer. Should I be – hmm, ashamed or something ? For not watching instead : what, the bored faces of Sun staff ? Or : Jbuilder logo and words in big red letters ? Java has what we call an image problem. Some steps were made (the java.com site for instance) but there’s still a long way to go. It’s a matter of ‘packaging’ and might seem useless and frivolous. But how will Sun impose ‘friendlier’ development tools if the language itself still has a cold, silent, sad, geeky image, competing with .Net platform which has a much “sexier” look ?

You can tell that my Palm m105 is not exactly bleeding edge. Both by its rather bland dark ugly look (completely out of fashion compared with today's shiny brigh colored semi-transparent PDAs) and its feature list which does not include webcam, MP3 player, Internet browsing and Office compatibility. However, back to 2001 when I received it as a gift it was a pretty decent machine.

Nevertheless, this little piece of silicone and glass is playing an important role in my life. I keep my agenda and calendar on it, I use it as an alarm clock and especially for evening reading. Instead of printing articles and waste trees, I use Pyrite publisher to easily convert between major formats and store files on Palm for subsequent reading.

PDF is a major format, but haven't really felt the need to convert it to Palm-readable until recently. As a IEEE Computer subscriber, I have access to the Digital Library, where articles are first published in PDF format, then – only after a few weeks – in HTML. My first thought was to save files as TXT from Acrobat Reader (6), but it's a no-no (although, I vaguely remember being able to save in a different format from Acrobat 5). OK then, let's just use the text tool, select everything and copy/paste into an editor. Well – stupid design flaw or feature crippled on purpose – the text selection can be done only INSIDE a single page. So – 20 pages mean 20 copy/paste operations. Ctrl-A does select only text from the current page. Then, I tried to bypass the “functionality” by using automation and the ActiveX Acrobat control. More or less expected, the control does not allow usage of text tool and selection is not possible (yes you can display documents, walk through them page by page, but that's the most you can do). Grrr.

My hope that GhostScript and GhostView could perform a text extraction proved utopic. Yes it probably works on some simple test files, but on Computer's documents with different layouts and formats and their inserted textboxes it either produce a completely unreadable textfile or it simply fails with a cryptic error.

All this left me with only two choices : buy a conversion product (huh, is there a market for such a thing ?) or use Adobe Acrobat for Palm, latest (3.05) version. My hardware is in the supported list, I have a hefty 8MB of RAM on my Palm so I decided to go with the latter. It was a mistake.

First, PDF “conversion” of files does almost nothing to reduce file size. If you start with a 3MB PDF, you'll end up loading a 3MB PDF into your Palm (that is, if you have the available memory). Go on, check graphic resize in preferences – it's NOT helping. Second, it's slow as hell. A few seconds to pass from a page to another. But what the heck, I could read PDF documents and this was my initial purpose. Alas, it was too early to declare victory.

My reading pattern in bed is quite simple : I read until I'm too asleep to continue, then put my Palm next to the bed and turn off the light. Don't even bother turning off the Palm, since it automatically turns off after 30 seconds of inactivity. That is, until I had installed Adobe Acrobat.

Next morning, instead of the familiar tut-tut-tut of my Palm alarm clock, there is someone knocking energically at the door. And surprise-surprise, it's not 7 o'clock but almost 9 ! It was another day when I was supposed to be the driver and give a lift to the office to other 3 co-workers, usually leaving around 8:20. No wonder they were at my door wondering if I was sick or something. No, I was perfectly well and my Palm was alive and kicking, still on and displaying happily the now familiar Acrobat screen with the last page from the previous night. The Palm was FREEZED, unresponsive to any button and only the hidden reset switch from the back had managed to provoke some faint reaction. I left in a big hurry.

After a long day back in the evening, almost forgotten the incident, watched a movie, read some blogs and back to bed. No reading this time. But it seems that, after a whole night turned on, the AAA batteries are low so I can't turn on the alarm clock (what sort of idiosincracy is this, forbidding an action because the batteries are low). It was too late to call anybody, so I ended up WARMING the Palm to trick it into thinking that the batteries are a tad more active and allow me to activate the alarm clock. So much for the useful things learned in the electronics classes.

Anyway, the next synch crashed on me, and the synch after, and the few subsequent retries. It calmed down only after uninstalling Acrobat. So I guess it was not a victory after all. From now on, I'll stick with reading simple plain text files on my Palm. Anyway, Reader is a free product after all so I'll stop the rant here – but I was expecting something more from a company such as Adobe.

wx4j is a Java wrapper around the *tried and tested* wxWindows widget framework. The main idea may be similar with one which gave birth to SWT : hide native widgets behing a [more or less] thin layer of Java. By “native” I mean widgets for Windows flavours, Linux/Unix with GTK+ or Motif, and MacOS as well. However I see some interesting differences :
+++ source code is available for native wxWindows, however not available for native part of SWT ?!?
+++ wx has considerably more C++ than Java. Some layers such as event loop are native to the OS thus (afaik) faster than SWT's.
— what about wxEmbedded ? would be nice to integrate also … SWT has already made some steps in this direction
— I find somehow questionable the sanity of the “native” approach, because we'll eventually end up writing small Java control layers manipulating native GUIs and native data sources (OTL anyone ?). But then again, this might be a valid approach.
As well as in SWT, there is some ["non-Javaic"] memory management needed such as destroying transient windows containers and deleting memory used by drawing contexts … Although the library is extremely young the doc is quite useful, even showing non-obvious things like how to deploy a wx4j app with webstart.