The problem of Qt Jambi

I like desktop UI development. Especially I like architecture of Swing, but not so long ago I felt the power of Qt, thanx to Qt Jambi. Now I know that while Qt have some architecture problems it has superior Graphics, more usable widgets, and saves a lot of time on borders and pixels manipulations thanx to it's advanced widgets.

But Nokia decided to stop supporting Qt Jambi, and gave it away to "community". While there are some smart guys on Qt Jambi mailing lists - it is not community yet. And of course I thought about ways to help Jambi survive.

The problem is, I am Java developer, and Jambi was created for Java developers. Most of people on Jambi mailing list are Java developers. It is not very popular among C++ developers because they will not be able to use the result of their work. While Jambi generator is written in C++, and to be able to update Jambi according to Qt changes you should know C++.

Ok, let's assume I am learning C++, to help Qt Jambi to write Java apps using Qt. Well, not Qt itself but bindings of Qt to Java. Do you see the problem? Why should I use Jambi if I already know C++ and I can use Qt itself, without bindings and additional abstraction levels. Then, why should I help Jambi if I will not use it?...

As for me Jambi-like project will not survive without support of some company, and stopping Jambi support Trolltech/Nokia almost killed the project. Now it most likely some parts of Jambi will be salvaged, for example it's extremely cool generator. Maybe in some time I will learn C++ a bit better and will dive a bit inside of Generator sources, and maybe even write something similar in Java if I'll have nothing better to do...

Homegrown projects: versioning

From time to time you need to set up some project at home. There are plenty of reasons: you are starting new opensource project, want to write few HelloWorlds with new frameworks, or you just don't want to go to office today.

And of course you want to use some VCS with your project, because it allows you to perform development in steps, plus standard VCS features like revert/diff.

I worked with CVS, SVN, Perforce and a tiny bit with VSS. And few days ago I tried Mercurial. Mostly because great support from NetBeans. But now Mercurial is total winner for home usage, only two simple steps and your repository is up and ready to be used from your favorite IDE. With Mercurial you don't need to start servers, use network connection, configure some system files using root privileges, just install and init project. And enjoy lightweight source control system that will provide you with all benefits of versioning.

JPA 2.0 migration experience

Java EE 6 specification released not so long ago, and now includes release of JPA 2.0 specification. Obviously, you'd like to use JPA 2.0 for your new project. But the problem is, how to choose good implementation and where to get it?

First you will go to Sun's persistance page. You'll read a bit and click on "download" link that will take you on Glassfish Persistance page. But the problem is, you will not find JPA 2.0 reference implementations on that page.

Ok, next step - ask google. Google sais that EclipseLink is reference implementation for JPA 2.0, and wikipedia confirms. Let's go to EclipseLink downloads. Yea, there are some files to download, but again everything is packed into single huge JAR with dozens of features we don't really need (yea, I have "classpath paranoia"), and the main component is missing - sources for JPA 2.0 API, that can be added to NetBeans libraries to read javadocs and to help it with method argument names (do you remember that Library Manager in NetBeans?).

We must not give up. Let's go to JSR page and take a look. Wikipedia states it's JSR 317. After clicking on "Download" link we can see another link, that will direct us to "EclipseLink's Reference Implementation Downloads". After downloading both and taking a look inside of each package we can see that "EclipseLink 2.0.0 - minimal bundles that are shipped in the Java EE6 RI" is what we really need. Finally, everything we may need and packed in separate small JARs, so we can include only features we need.

Now, let's make it work. I have project that used JPA 1 with EclipseLink 1.2.0. I removed all EclipseLink libraries, added javax.persistence_2.0.0.v200911271158.jar (JPA 2.0 API) and org.eclipse.persistence.jpa_2.0.0.v20091127-r5931.jar (one that contains org.eclipse.persistence.jpa.PersistenceProvider). First few starts of application ClassNotFound were reported, I searched for required classes and added their JARs. Finally, here is the full list of JARs you need to work with standard JPA 2.0 feature set:

javax.persistence_2.0.0.v200911271158.jar
org.eclipse.persistence.jpa_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.core_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.asm_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.antlr_2.0.0.v20091127-r5931.jar

and files to add to Sources tab (NetBeans will be able to show you sources, javadocs and read method argument names from those sources):

javax.persistence.source_2.0.0.v200911271158.jar
org.eclipse.persistence.jpa.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.core.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.asm.source_2.0.0.v20091127-r5931.jar
org.eclipse.persistence.antlr.source_2.0.0.v20091127-r5931.jar

That's all. Use JPA 2.0 with pleasure, support new versions and software evolution, because otherwise we all will become stupid monkeys and will return back on palms.

GWT EventDispatch and widgets width and height

When you're constructing Widget in GWT - it's size is 0 until it's rendered. It's different from Swing, Swing assumed that you're working in EventDispatcher and calculated all sizes instantly. It is not announced but looks like GWT have it's event dispatcher too, and you can use DeferredCommand class to place Command into events loop. Using this approach you can construct Widget, place it into some Container, and then add some Command to DeferredCommand to work with widget's size after current construction operation will be complete and Widget will get it's size.

It looks like problem of all young widget toolkits, like Swing itself many years ago. They are showing it, its simple, its cool. But when you start coding real application using that toolkit - you'll get many problems, many different "hidden" features and many tricks and workarounds. After many years they'll tell you about EventDispatcher, then they'll implement different kinds of BackgroundWorkers, and different rules how to "use correctly" this toolkit. You can remember situation with "EventDispatcher rule" of Swing and how it was changed from Java5 to Java6 (while nothing inside was changed). Now we can see similar situation with JavaFX, and GWT goes the same way.

Internationalization in UI toolkits

I have some experience with many different UI toolkits. The most with Swing, QtJambi, GWT, and some with SWT and Echo2. Some of them providing you with their own i18n techniques. Let's take a closer look...

Swing is the most comfortable tookit because it gives you full Java API, with source code, possibility to dive deep into it's internals and no external libraries or dependencies. And it gives you standard Java i18n engine: ResourceBundle. It's simple, powerful and effective. And it's customizable (if you know Java of course).

Qt Jambi gives you Qt's native internationalization engine. It works in other manner than ResourceBundles. API is clean and simple, every Qt widget have method tr(String) where you can specify default value, but not the key as ResourceBundle suggested. From one point of view it's good because you're hardcoding default values, and you will be sure that on any system it will at least show default version. From the other side - those messages can take a lot of space in your source files, plus they are actually keys in internationalization files, similar to properties files. Having keys like this is not very good, because modifying single char you have to modify all resource bundles, while in ResourceBundle you can leave code "as is", modifying only value but not key.

GWT is totally different. It's using properties files too, but you have to extend Constants interface, and add all your keys as String methods to interface. As for me GWT is the total winner, because you have properties files with key-value pairs and IDE support, and you have compile-time safety because you're getting those strings from Java class. In ResourceBundle you're operating mostly with Strings, and simple typo can waste lots of your time, while using GWT approach you must ensure your keys only once, then you're totally saved from any kinds of typos using Java methods to get your internationalized messages.

GWT 2.0: almost 6000 downloads in 33 hours

GWT 2.0 released yesterday, but almost reached 6000 downloads already!

Well, I am agree that GWT is pretty cool thing, especially if you must do something for web browsers, but 6000 in 33 hours... Can you remember any other toolkit with same download rate? Even Java developers are not bothering themselves with downloading of new versions.

GWT 2.0 released, HTML drawbacks as new feature

Few minutes ago I read about release of GWT 2.0. It's great new release, with many useful features. Except one: UiBinder. HTML and XML both have their problem - they are page-oriented. You can't just replace some widget as long as it's Widget subclass. You need to repaint all page if you want to layout it in some other manner. GWT allowed you to avoid those drawbacks, providing you with great feature-rich component-based framework. You could do everything in plain Java, and as for me it's big advantage, because average quality of GWT project were relatively high (you at least need to know Java, and maybe some component-based framework like Swing, right?). And now any novice HTML coder can feel something native and ugly using GWT, lowering average code quality and writing another crappy application with cute HTML-like interface. Impossible to debug, impossible to apply any Java techniques, and even making harder to use version control system (I hope you noticed that modern DIFF algorithms are not very good with XML?).

Stupid frameworks are forcing you to do stupid things

I am working with GWT+GXT right now. And I have strange problem - I can't save some user object. Just can't. When user logined to the system I want to save user object, containing his name, mail, role, group and other things. But as soon as F5 pressed - all static is cleared from the application, so even static fields can't help me. Cookies can help me, but they're limited to String only...

Of course my imagination works fine, and I can implement some GWT RPC service and get user from the server (where I have user's session, and I can save User object into that session). But it's stupid, isn't it?

NetBeans and Safari

On my Windows box I am using Safari to read javadocs. Because of fonts antialiasing of course. And just noticed strange effect - NetBeans starts to lag when Safari is opened. Sources parsing is slower, autocomplete waits visibly longer before suggest something... Do you know where is the problem?

GWT2 Firefox plugin download

First release candidate of GWT2 released on November 17, it can be downloaded here. One of the first changes you'll notice - they removed their "hosted browser" and added plugins for some browsers that will help browser (Firefox?) to do the job of "hosted browser". The first time you'll run application - it will suggest you to download plugin. But what can you do it you want to copy your project on workstation with strict or no internet? Or it you're planning to clean Firefox profile from time to time?

I asked question about where can I get those plugins on Google Groups for GWT, but 7 days passed and no answers...

So here is the small guide how you can get it manually.
1. Find folder where firefox storing it's plugins. For me it was C:\Documents and Settings\Username\Application Data\Mozilla\Firefox\Profiles\5zchoudq.default\extensions\gwt-dmp-ff35@gwt.google.com (yes, yes, I am still using Windows on my job).
2. Open install.rdf in text editor. After reading it for some time the only interesting line you'll find looks like this: http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/update.rdf in em:updateURL tag.
3. Open that link in browser and read that file. Now you can see the link where you can get that extension, can't you? Here is it: https://dl-ssl.google.com/gwt/plugins/firefox/gwt-dev-plugin.xpi.
4. Now you can save it for farther usage.

Java things that make you go "hmm"

I am preparing myself to SCJP exam, and while reading preparation book I found "feature" I didn't knew about. Take a look at the following code:

public class Main {

 public static void main(String[] args) {
  new B();
 }

 static class A {
  public A() {
   System.out.println("A constructor");
  }
 }
 static class B extends A {
  {
   System.out.println("B init");
  }
  public B() {
   System.out.println("B constructor");
  }
 }
}

How do you think, what output will it generate?

Java single inheritance questions

There are few structures in Java that are not so intuitive as others. Take a look:

public class InnerInvocation {

 String getValue() {
  return "Outer Value";
 }

 private class InnerClass {
  String getValue() {
   return "Inner Value";
  }

  void work() {
   // insert code here
  }
 }
}

What code do you need to invoke getValue() method from outer class?

Here is the answer:

  void work() {
   InnerInvocation.this.getValue();
  }

And now the question of the day: there is syntax that possibly can allow multiple inheritance in Java, so why is it forbidden? Because you as developer can make lots of mistakes? Why then they allowed reflections?

Eclipse and NetBeans compared

Eclipse 3.5 released few days ago, and NetBeans 6.7 just released. Of course I am using NetBeans 6.7 starting from beta versions and I know how it works, so I wanted to test eclipse. After using it for few hours came this comparison.
Both IDEs have clean install and run.

About

Two about dialogs to show used versions

Memory usage at the beginning

Memory usage just after startup. It's pretty comparable to say "there is no winner".

Step 1: project creation

Eclipse

New project dialog:

Eclipse gives lots of options on project creation page, and defaults are quite ugly. May be that is the reason why eclipse users are never writing small projects just to test some API?...

NetBeans

New project dialog:

NetBeans gives option to create Main class for project at once, but we will ignore this suggesion for comparison purposes.

Step 2: main class

Eclipse

Eclipse shows another overloaded window. Of course first bug in package input, Ctrl+Space just does not work there. As for me to save user's time it would be better to create just empty class as soon as possible, and editor will give possibilities to modify that options.

NetBeans

Quite better options than Eclipse gives, you see all possible templates for your Java project organised in tree.

But there is next window to complete Main class creation. It's a bit more usable than Eclipse's version because of good focusing system, but still it's step 2.

Step 3: autocomplete

Eclipse 1

Basic autocomplete is just ass-ugly. No text coloration, small and not monospaced fonts just suitable to print errors, but not information for developer.

NetBeans 1

Text coloration helps more than icons, but icons differs each other if compare to Eclipse's round icons with just letter changed. And of course monospaced font.

Eclipse 2

One point to Eclipse - after autocomplete focus is given to set type of list.

NetBeans 2

Not much to look at.

Eclipse 3

Another ugly autocomplete window.

NetBeans 3

Only imported types shown. Once this was IDEA's feature and it makes good job.

Eclipse 4

It's very strange to see icons and other information here, just can't understand who needs it.

NetBeans 4

Quite lot of variants.

Eclipse 5

Cool. 5 items in list and none will work for us.

NetBeans 5

Same problem, just showed everything it knew.

Eclipse 6

Nothing interesting.

NetBeans 6

The same.

Eclipse 7

Were there any worse possibilities?

NetBeans 7

Pretty good, all found List implementations will help us. Just why to show classes from com.sun.* packages?...

Eclipse 8

Still no help from IDE! I can do the same in plain text editor, why do I need IDE like this?

NetBeans 8

Perfect. The most suitable class and full javadoc for it.

Eclipse 9

One more point to Eclipse. It's good to write type and brackets when class is already known.

NetBeans 9

No brackets... I have to press another autocomplete to see available constructors. Even no autopopup of autocomplete here.

Eclipse 10

Another ass-ugly autocomplete. No text coloration, no text alignment, some strange info about class of object, and that stupig "arg0" labels... I don't know, did Eclipse guys ever saw what they developed?

NetBeans 10

Just perfect. Bold marks methods implemented in class and plain - inherited methods, text aligned to let you browse return types with ease.

Eclipse 11

arg0?...

NetBeans 11

Well, it's really the best found option around.

Eclipse 12

Hm... no text autoquoting?...

It even can't put semicolon to the right place!...

NetBeans 12

Oh, here is text autoquoting, autoputting of semicolons... But it's NetBeans who helped me to save my time.

Eclipse 13

Wait... but there is src.zip with my JDK installation, it's full of javadocs! Why can't it just show me javadoc from there? Do I really need to go and download javadoc.zip in 21st century?

NetBeans 13

Here we go, it's not hard, is it?

Memory usage now

Memory usage after comparison above. And you will be next to say me that "native SWT is faster than interpreted Swing"? I'll write separate article about that myth.

Conclusion

"IDE" stands for integrated, but as naturally I expect my IDE to help me in my every day job. Help in this case stands for autoquoting, autosemicolons, simple and fast dialogs, and of course pretty and usable interface, that saves your time searching required items. Currently NetBeans is only IDE that really tries to help me as much as it can, though there are things to work on. And that makes me NetBeans user, not just big user base or Sun trademark.

Java and music player

Today I found post on elliotth's blog about Java and MP3. Being developer of Xine engine for aTunes I have own thoughts about it.

Step 1: Target users
At first you should decide who will be your users. Depending on this choice you have different amount of possibilities. For example, Qt Jambi with Phonon will fit for all systems, while Xine is not available for M$Windows users.

Step 2: Engine
Second part of music player is engine. I am long time SUSE user and I prefer Xine over other because it ships with SUSE and all best KDE apps are using it as engine. Also popular MPlayer, VLC and Gstreamer. Of course I hate Gstreamer because of strange format support politics and trashy sound, but it's your own choice.

Step 3: How to use engine
After you decided what engine you want to use - there is a question how to use it.

a) JNI
You can use some wrapper generator like SWIG to generate wrappers and use it from your application. While this is the fastest way to invoke engine - there are few possible problems:
1. You have to build your application for all platforms yourself. It can be hard enough if you have no compilers for target platform and you have never used some of target platforms, or you have only 32bit CPU.
2. Static vs dynamic linking. I am not C/C++ guru, but I noticed that some apps build on other systems than mine can't find libs from system folders like /usr/lib. It's easy to understand that there are some linking problems for target platform depending on libs path or libs versions.

b) JNA
It's my favorite. JNA guys did a great job. They solved all possible problems in JNI approach, building jna.jar for all platforms and supporting dynamic linking. The only problem - mostly you have to read *.h files and write classes to wrap them. It is simple if you know a bit of C/C++.

c) cmd line
You always can invoke your engine from command line. MPlayer have it's own command line interface, so you can just send commands and read responses from Process stream. Also, Amarok supports commands like "amarok -s" to stop. May be your favorite player also does? Of course you should give user to choose path to your supported engine, while Linux platforms can be found in $PATH it will not work on M$Windows.

d) Use Qt Jambi
I already wrote about Qt Jambi. It's great solution for any desktop application, not just music player. And it have it's own media API, that can be found in examples. I suggest you to download and take a look yourself.

e) choose from existing wrappers
Many engines have it's own wrappers already. Here are some of them:

• VLC


• Xine have both JNI and JNA implementation (JNA is sound only)


• Gstreamer


• DirectShow

Qt Jambi first experience

Being long time KDE user and Java developer - I couldn't ignore Qt Jambi release. Of course I downloaded it and tried as soon as version 1.0 vas released. Yes, at first it was version 1.0, built with Qt 4.3. Only after some time Jambi got version as its Qt.

I was impressed even with first version, but it seemed a bit slow and not yet ready for every day usage. But last week there were some news about Qt 4.5 and LGPL license, so I downloaded last available version of Jambi and started few example apps.

And now I am really impressed! I used to think about Swing as fast and developer-friendly when developing some desktop applications, but now I know Qt is really two heads higher in desktop apps development. Jambi evolved and now there is no problem of setting LD_LIBRARY_PATH and other params, you can simply include jar file with Qt and Jambi libs to your classpath.

Then I started a bit bigger project to have complete application in Jambi. As long as there is no fast and stable notepads for Windows I wrote QEdit. You can see sources here.

Now, after I have some first experience with Jambi I can compare Jambi and Swing:

+ Jambi has better shortcuts system. You don't have to work with root panes and actionmaps, you can just ass some shortcut to your action.
+ QStatusBar. I thought about writing something similar for Swing few month ago, but here you can assign statusTip to your action and that tip will appear in status bar on rollover.
+ QSettings. It is much more usable than Properties for storing your settings.
+ QToolBar. Even if it is possible to do something similar in Swing - you will never spend so much time to do it like Qt can. You can download and run QEdit to see how you can move toolbars to different parts of main window and this position will be saved between sessions.
+ QFontDialog. Almost every Swing application have to implement Font Chooser themselves, while QFontDialog is almost the same in every application.
+ Components already have their scrollbars, you can just enable or disable them. I can't remember at least one case when you don't need to wrap JTextArea into JScrollPane.
+ Wide range of supported graphic formats and components adjust size of graphic automatically.
- Jambi can't see if wrapped C++ classes extend some other classes.
- Jambi QFile is very slow and locking file. I don't like when File object locks real file on file system, only io operation should block it. So don't try to use Qt Jambi for all your tasks at once.
- No way to extend or customize QFileDialog. Even style is not applied to QFileDialog.
- Signals in "action system"... It's just wrong in Java. Thanks that application fails on first start but not in time of invocation if something is wrong in source.
- You can't give both small and large icon to QAction. After providing 22x22 icons some of them looks too smooth in main menu.
- Lack of documentation. If you are not enough documentation and examples from Jambi distribution - even Google will not give you a lot.
- Looks like all the work is performed in blocking QApplication.exec() method. I can't find is there anything like SwingWorker for Qt or Jambi...
- There are lots of possible pitfalls when you are writing huge application, and Swing "experience base" is huge enough to help you in almost everything, plus Swing is pure Java where you can debug everything you want. But where to go with Jambi? There is support in Trolltech for commercial version...

Java is faster than native

There is a myth that native is much faster than java. Lots of frameworks speculate this myth and using lots of native methods from java. But how often they are implementing same functionality and check native against true-java? They are often diving so deep in own fantasies about native performance that it is almost religion, they just don't accept facts. But how much it takes to JVM to invoke method from native library? And how much is it comparing to raw java interpretation?

I don't like to use things that I don't understand. Almost all methods from Math class is native, and I can't see sources of that classes. There are some functions that would be hard to implement, like Math.sin() or Math.cos(), but there are some easy-to-implement methods. This time I need functionality of method Math.pow(). It is not hard to implement it in java:

private double pow(double value, double pow) {
  double result = value;
  for (int i = 1; i < pow; i++) {
    result = result * value;
  }
  return result;
}

And it is not hard to implement some raw test using case from current developed application:

private static final int times = 1000000;
public static void main(String[] args) {
  // running test 10 times to "hotspot" it
  for (int i = 0; i < 10; i++) {
    // I know, I know, you can never
    // preallocate long, but I like it:
    long start = 0;
    long end = 0;
    start = System.currentTimeMillis();
    for (int j = 0; j < times; j++) {
      pow(10, 10);
    }
    end = System.currentTimeMillis();
    System.out.println("pow: " + (end - start));
    // cleaning JVM every time before next cycle:
    System.gc();
    System.runFinalization();
    System.gc();
    start = System.currentTimeMillis();
    for (int j = 0; j < times; j++) {
      Math.pow(10, 10);
    }
    end = System.currentTimeMillis();
    System.out.println("math: " + (end - start));
    System.gc();
    System.runFinalization();
    System.gc();
    // and running once more to be sure in hotspot:
    start = System.currentTimeMillis();
    for (int j = 0; j < times; j++) {
      pow(10, 10);
    }
    end = System.currentTimeMillis();
    System.out.println("pow: " + (end - start));
    System.gc();
    System.runFinalization();
    System.gc();
    start = System.currentTimeMillis();
    for (int j = 0; j < times; j++) {
      Math.pow(10, 10);
    }
    end = System.currentTimeMillis();
    System.out.println("math: " + (end - start));
    System.gc();
    System.runFinalization();
    System.gc();
  }
}

I just wanted to figure out how slow is my implementation, but results were totally unexpected!

run-single:
pow: 63
math: 797
pow: 78
math: 797
pow: 78
math: 781
pow: 78
math: 781
pow: 63
math: 781
pow: 63
math: 781
pow: 63
math: 797
pow: 63
math: 797
pow: 63
math: 797
pow: 63
math: 782

It's 10 times faster than Math.pow() when raising power of 10!!

Think different. Think faster!

Swing and TreeTable component

TreeTable combines functionality of two components - Tree and Table. And it is really comfortable to show some hierarchical information like file system structure or many others.
TreeTable have great Qt implementation, it's fast, useful and pretty. It's a pity there is no standard Swing implementation of this component. But there are lots of third-party implementations. Let’s review them:

JEdit

JEdit uses TreeTable component for Open-Save dialog. It is extremely fast and pretty. But they did it for their own, with package-private constructor and double-linked to other JEdit components. To use it in other projects means to rewrite it almost from scratch, so JEdit is just a good demo of TreeTable possibilities for Swing.

SwingX

SwingLabs has their implementation. It is feature-rich and customizable. But it has some rendering bugs, much slower than JEdit version, amount of code is too big to extend it yourself and it linked a lot to other SwingX packages.

NetBeans

As Tim Boudreau told us, NetBeans only recently got a good implementation of TreeTable. And this implementation looks great! It works almost as fast as JEdit one, has no rendering bugs, needs only few classes to build it (but not all the framework as previous two implementations) and it's easy to use and customize. But one more problem - you may use it only under either GPL2 or CDDL, and you need to download NetBeans sources and copy org.netbeans.swing.outline package to your project to use it.



All of them extends JTable. I think it's not good, JTable is the biggest class I have ever seen, about 9000 lines of code, and SwingX implementation adds another 4000 lines. It is hard to debug and hard to customize to internals. Swing is so big because backward compatibility, but what sense of JTable compatibility for totally new component? How do you think, may be it is time to write Tree, Table and TreeTable LGPL implementation by ourselves using best practices from core swing, SwingX, JEdit and NetBeans?

Comparing two collections

There is standard task when you have GUI table and database table, and you need to merge differences.
Most of people I know will do it like this:


Set source; // set of records from UI
Set target; // set of records in database
for (Object o : source) {
    // if we have object in source without
    // same object in target - it was added by user:
    if (!target.contains(o)) {
        target.add(o);
    }
}
Iterator iterator = target.iterator();
while (iterator.hasNext()) {
    Object o = iterator.next();
    // if we have object in target without
    // same object in source - it was removed by user:
    if (!source.contains(o)) {
        iterator.remove();
    }
}


We have 2 full collection iterations. In most cases it will not cause big performance issue. But it looks bad and will cause performance problems with slow Collection implementations or with big amounts of data.

After using my brain few minutes I found the best way of comparing, with only one iteration:


Set source; // set of records from UI
Set target; // set of records in database
// just checking:
if (target.equals(source)) {
    return;
}
Iterator iterator = target.iterator();
while (iterator.hasNext()) {
    Object o = iterator.next();
    if (source.contains(o)) {
        // remove all checked objects for future
        source.remove(o);
    }
    else {
        // if source does not contains object -
        // it was removed by user, removing it from target:
        iterator.remove();
    }
}
// all object left in source are added by user.
// Adding them to target:
target.addAll(source);


Simple enough, isn't it?

Java5 forever or Codename: No Future

Java6 exists almost two years now, and Java5 "is in its Java Technology End of Life (EOL) transition period". While I admire people, using top versions of Sun's Java, there are lots of folks, who are still using Java5. All of them have different reasons: someone just don't want to bother saying "Why should I?", someone have some strange compatibility or porting problems. Someone saying about business, about cost of migrating from Java5 to Java6.

But how long your project will exist on Java5? Year or two? You spent your money on your project, do you really want to join it's lifetime with Java5 lifetime?

Let me explain. You have project, you have N services and X users. If your organization has no evolution - everything is just fine. But if your project grows - you have N = N + 1 services and X = X + 50 users each half-year. Once your current hardware will not be enough, you will move to better hardware. On better hardware you will have new operating system that supports all your hardware (for example, Windows 2003 Server supports only 4 CPUs/CPU kernels). And what if there will be no Java5 for that operating system? Sun is not supporting Java3, Java4 and soon Java5 anymore, who will care about your problems and your needs? Red Hat? Or Microsoft? Currently, there is even no possibility to download Java3 directly from Sun, or there is no Java4 for x86_64 platform. Do you want to make your business on zombie products?

Sun gives you the best platform of our times. Sun gives you standards, public APIs, open and flexible platform. Sun gives you own implementation of it's platform, saying there are lots of them around. Sun also guarantee backward compatibility (Java4-Java5 is another step, I am talking only about Java5-Java6 now), and only possible compatibility problem - usage of sun.** API. But even here Sun gave you compiler warning: "sun.** is Sun proprietary API and may be removed in a future release", and it's some king of mental retardation to ignore warnings like this.

So, as for me - if you can't move from Java5 to Java6 - your project is dead, and you is guilty in its death, no matter how long will it take to make it smell like old corpse.

LookAndFeel chooser

You will not dispute that modern desktop application needs some theming, right? And, being Swing developer, few times you tried to solve this problem, didn't you?..

I have solution now: JLAFChooser.
Now, you can just put JLAFChooser component into your setting dialog, and it will make LookAndFeel chosing possible in runtime. Now you have no need to hardcode all the LookAndFeels you know into your classes or XML files, and user can just download few LookAndFeels and put it somewhere in classpath to make it available to JVM.

It has two main variants: when Apply is allowed and when not.

When Apply is allowed your user can choose something from list and check it at once, and may be choose something else.



When Apply IS NOT allowed you can just show list of possible LookAndFeels, and save somewhere to preferences user selection, to apply it next startup.


Usage is similar to JColorChooser, with few extensions - you can get LookAndFeel instance, it's name or it's class name. Methods to apply and restore LookAndFeel are public, you may use them for your controls.

PS: feel free to mail me for suggestions, bugs, or just to talk about Java, Swing, religion, fantasy or anything...