Category Archives: Uncategorized

ProcessBuilder and quotes

Recently, I have spent few happy hours chasing a bug in my code. It was connected to the ProcessBuilder class. This class was introduced to Java 5 in order to simplify calling of external processes.

I needed to run following rsync command, to synchronize some files from the server. It simply takes all *.txt files from all directories and ignores all other files.

rsync -vtlr --include="*.txt" --include="**/" --exclude="*" rsync.example.org::module ./mirror

With ProcessBuilder it is easy, you just have to write the following code.



    ProcessBuilder pb = new ProcessBuilder("rsync","-vtlr", "--include=\"*.txt\"","--include=\"**/\"", "--exclude=\"*\"", "rsync.example.org::module", "./mirror");

    pb.directory(directory);

    Process process = pb.start();

    int result = process.waitFor();

It works good, without any problem. But only on Windows. When I deployed the application on the Linux server, it synchronized all the files. It looked like that –exclude directive was simply ignored.

The weird thing was, that when I run the command from the shell it worked as it was supposed to run. The usual suspects were the quotes. Since the command worked, only some parameters were ignored, it was evident that the problem is subtle. I tried to replace double quotes with single quotes, put all parameters to one. I even tried to call the command using Runtime.exec(). It was just vain effort. (Runtime.exec() internally uses ProcessBuilder). The solution is simple. Just remove all the quotes from all parameters.



ProcessBuilder pb = new ProcessBuilder("rsync","-vtlr", "--include=*.txt","--include=**/", "--exclude=*", "rsync.example.org::module", "./mirror");

    pb.directory(directory);

    Process process = pb.start();

    int result = process.waitFor();

Like this, it works on both Linux and Windows.

NIH by SUN

This week I have written a blog entry about Not Invented Here syndrome at Sun. It was reaction on presentation of Kohsuke Kawaguchi on CZJUG meeting. There were some comments under the entry that it would be more fair to write it in English so Kohsuke and others can react. So I am writing it again. It is not exact translation, this entry is much shorter and less bitter.

So what is the problem? Kohsuke was showing new Glassfish v3 server. The idea is great, they are trying to create a modular server that will be able to start really fast, initialize its parts on demand, will be able to run RoR, PHP etc. Moreover, they are using Maven in really interesting way. But during the whole presentation I was thinking that I see a nice example of NIH syndrome. They needed module system. So they wrote one. They needed IoC container. So they wrote one. It does not matter that there already are dozens of IoC containers. They just wrote their own. What is the reason for it? I am quite sure that it is not stupidity or lack of experience. They have to be quite clever and experienced to be able to write an application server. I think that there is politics behind it. Although Glassfish is an open source project, it is primarily project owned by Sun. And Sun can not use some existing IoC container that dos not even have its own JSR. Imagine that. Sun using Spring (or Guice or whatever) internally. It would be unbelievable. The same is with the module system. Sun just can not use OSGi, they are at war with them. (Or at least it seems like they are). It does not matter that OSGi is proven solution. They just have to create their own. Why? Because of NIH.

NIH podle Sunu

V pondělí jsem se zúčastnil CZJUGu. Obě přednášky byly zajímavé, ale při druhé, týkající se nového Glassfishe, se mi do mysli neodbytně vkrádala zkratka NIH. Pro ty, kteří nevědí co to NIH je doporučuji pěkný Dagiho článek.

Zkratka NIH znamená Not Invented Here, česky by se dalo snad říci „nevymyšleno u nás“. Používá se, když někdo vymýšlí něco co už bylo dávno vymyšleno, jenom proto, že to nevymyslel on. Přesně v tomto duchu se nesla prezentace Glassfishe. Potřebovali modulární systém, tak si ho naimplementovali. Potřebovali IoC kontejner, tak si ho naimplementovali. Potřebovali jezdit do práce, tak si sestrojili něco na čtyřech kolech s motorem. (I když, teď si nejsem jistý, jestli to poslední zmiňovali). Vůbec nevadí, že už existují funkční vyzkoušené modulární systémy. Vůbec nevadí, že existuje hromada IoC frameworků. Napíšeme si to znovu a mnohem lépe.

Domnívám se, že v tomto případě nešlo o hloupost nebo neznalost. Myslím, že za tím stojí politika. Asi si myslí, že by vypadalo hloupě, kdyby používali Spring. Co by tomu řekli lidi. Vynálezci EJB, autoři přehršle skvělých a bezchybných JSR používají něco co není posvěceno JCP! Nebo nedejbože používat OSGi. Fuj.

U toho OSGi bych se chvíli zdržel. Je to standard, se kterým se budeme setkávat stále více a více. Slouží k implementaci modulárních systémů, umožňuje nadefinovat moduly, které mezi sebou komunikují pomocí daného rozhraní, definuje životní cyklus a mnoho dalšího. První verze spatřila světlo světa v roce 2000, teď je ve verzi 4. Existuje několik implementací. Používá se v automobilech, stojí na něm Eclipse, začíná ho používat BEA, jede na něm WebSphere 6.1 a další. Člověk by řekl, že to je věc, která by stála zato, aby ji vzal na vědomí i Sun.

Chyba lávky, Sun rozjel vlastní specifikaci JSR 277 (Java Module systém), která obsahuje jakousi nekompatibilní podmnožinou možností OSGi (mimochodem OSGi najdete pod JSR 291). Jelikož za JSR 277 stojí Sun, má velkou šanci se dostat do Java EE 6. Že neexistuje žádná vyzkoušená implementace? Nevadí. Že se nepoučili z chyb ostatních? Nevadí. Peter Kriens, jeden s klíčových lidí OSGi, popisuje, jak se snažil dostat do skupiny, která na JSR 277 pracuji. Prý ho odmítli s tím, že už jich je tam moc. Proč myslíte, že se Sun takto chová? Já si myslím, že je za tím NIH.

Poznámka: Dnes jsem se nechal trochu unést. Proto jsem článek prošpikoval odkazy, abyste si mohli udělat vlastní obrázek. Budu rád, když mě někdo vyvede z omylu. Zajímavou diskuzi najdete také na InfoQ