Category Archives: Uncategorized

Hey, We’ve Got a New Team Member!

I guess you all know the situation. One day or another, you realize that you’ve got more work than you can manage. So your boss adds a new team member to your team. It goes without saying that you embrace them full-heartedly and teach them their new job with all the respect and empathy they deserve. In virtually no time, they are just as productive as everyone else, and they become a valuable part of your team.

Or not.

It’s the “or not” part this article is about. As to my experience, many people are badly prepared for onboarding new team member. Software developers are no exception. Quite the contrary: many software developers are more interested in tech than in people, which doesn’t help to embrace new team members.

By the way, this article concentrates on software developers, but that’s mostly because I don’t want this article to be overly abstract. It’s easy to rewrite this article for almost every other job.

The good news is that almost everybody manages to wiggle their way into an existing team nonetheless. But it could be a much more pleasant experience if given more thought. And it’s simple to do it right!

What does it feel like to be a new team member?

Empathy is the word of the day. Once you start asking yourself how the new team member feels, you’ll automatically do it right. Thing is, more often than not, we’re too absent-minded to even try. Mind you, the new team member has been hired for a reason: your workload is too high to cope. Everyone has started to get edgy, and increasing the workforce is the only solution.

Here’s the catch: increasing the team size reduces the team’s productivity. If you’re lucky, that’s only a phase, but in the meantime, everybody gets beyond edgy. I’ve seen thing getting nasty at this point more than once.

Switching perspectives

You can avoid most of the trouble by switching perspectives. What does it feel like to be a new team member? Well, they enter an established team playing by rules unknown to the newbies. They don’t know much about your business. They don’t know how the established team tackles problems. Maybe they even have to learn a new programming language, a new IDE, a new framework, or whatever. More generally speaking (because it’s a problem common to every branch, not only software development): the new team members have to learn both new people and the rules of a new game. Sometimes that’s easy. Sometimes it’s quite a challenge.


Some strategies to teach a new team member work better than others. Having them read the manual usually does not work. Telling them to browse through the wiki doesn’t work, either. It’s better to reserve three days exclusively for the rookies and to explain everything from scratch. Often it’s also a good idea to do pair programming. That, in turn, depends on the mentee. Many good developers don’t want to do pair programming. Pair programming is a skill that has to be learned, and it’s not attractive to everybody. But if you meet someone who likes the idea, do it. It’s one of the most efficient ways to bring rookies to speed. Even better: you’ll learn a lot, too.

Another good strategy is to assign bug tickets to the newbies. Solving bugs is a relatively straightforward job, but it gives them the opportunity to see many parts of the program, and to understand how everything’s glued together. After a couple of weeks assign more complex tasks to the rookie, such as developing new features. In any case, give them clear guidelines. When everything is new, it’s possible to stray off in many directions. Try to make sure that they follow the right trails instead of getting lost.

Expecting too much

Sometimes a new team member fails, and that can be quite a surprise. Even an experienced Java programmer can run into problems when joining a new team. There are many different strategies to programming. Some people prefer to test using the UI, while others prefer to write unit tests, sometimes ignoring the UI completely. Most people love their debugger, while other prefer the mainframe-style of debugging (i.e. adding log statements). Some people prefer an interactive programming style, while others prefer to start their program outside the IDE from Maven. The first group needs hot code replacement and a powerful IDE, while the latter group won’t even miss it. If you’ve learned to embrace a certain strategy and join a team using the other strategy, it’s hard to get productive. The problem is that embracing one of the strategies often makes it impossible to use the other strategy. For instance, in my former project, we couldn’t embrace the interactive programming style because hot code replacement was broken due to the project setup. Other projects can’t use the UI centric approach because their application server takes too long to start. The worst thing I’ve ever heard was an application server taking one or two hours to start the program.

So you’d rather be prepared for nasty surprises. Even experts and ace programmers run into problems every once in a while. Listen to their complaints, and try to detect warning signs as early as possible.

Gee, that new team member is so stupid!

Well, maybe the new team member is really stupid. Unlikely, but it’s not unheard of. Sooner or later you’ll meet someone who’s not up to their job. But in general, it pays to assume it’s your fault as a teacher. Be patient. Find a different angle to explain things. Don’t show your annoyance to your mentee. Adding to the mentee’s stress level only reduces their capability to learn.

By the way, the Bible calls this behavior an original sin, and it has a point. There’s a fine line between getting frustrated by lazy pupils and arrogance. Being arrogant is tackling the challenge from a completely wrong angle. Mind you: of course you have to teach the new team member even the most basic things. The established team had a lot of time to find a common consensus. The new team member doesn’t know any of the team history. That’s the definition of “new”. But usually, they are eager to help you. If you fall into the trap of arrogance, you’ll ruin exactly this eagerness. Just keep in mind you’re the ace by definition. You know everything about your project. The new team member does not. Come to think of it, it’s no surprise they act stupid. Increasing the team is not so much about you, but about embracing a new team member. On the long run, you’ll benefit from it. But you’d better prepared for a marathon than a short sprint.

Demanding too little

One of the most spectacular failures in my vocational life was when I wasn’t challenged enough. The job was simple, stupid and boring. My brain reacted by switching off altogether. So I wasn’t even up to such simple tasks like copying a pile of papers in a certain order.

In general, developing software is a demanding task, so I doubt this problem occurs very often. But even so, it may happen. If somebody fails at their job, it may be both because of demanding too much and boredom.

I can’t afford to spend time on the new team member!

Oh, yes, you can. If you really can’t, don’t hire them in the first place. Onboarding a new team member requires a lot of time. As a rule of thumb, it takes more time than expected. If you consider them as a distraction to your daily chores, you should either change your mind or communicate it to your boss early. Not everybody is interested in teaching other people. That’s OK as long as everybody knows it. But if someone chooses you as a mentor, the worst thing you can do is to chase away your mentee if they need help. If you really don’t have time to spare, politely tell them and promise to come back later.

Learn from your mentee

Teaching is one of the best opportunities to verify your ideas. If your mentee has difficulties to understand the architecture of your program, you’ve probably chosen the wrong architecture. More generally speaking, your mentee’s difficulties are always a good indicator that something’s fishy.

External consultants

External consultants are a special case. On the one hand, they are usually very experience and have seen a lot of different approaches to solving problems. On the other hand, that makes them fond of standard approaches. If a consultant tells you “it’s non-standard,” that doesn’t necessarily mean your approach is wrong. Sometimes it’s simply different. But beware: being different makes it difficult to add new team members. So this may be a good reason to listen to the consultant.

Another common mistake is to exclude the external consultant from the team. That’s just stupid. Many teams employ external consultants for months and even years. In this case, they are just another team member. Treat them as equals. If you don’t, you’ll probably ruin the consultant’s motivation and their productivity.

Anything else?

I guess there’s a lot to be added, but I’ve already stated the bottom lines:

  • Teaching a new team member is not about you. It’s about them. You’ll benefit indirectly, on the long run.
  • Teaching always takes more time than expected. Be patient.
  • Never get angry, arrogant, or something like that. Keep in mind that the new team member wants to help you. And that it’s easy to destroy their motivation.
  • Be prepared for nasty surprises. It’s always possible someone excels in one situation and fails in another. If they fail, analyze the situation and find a solution everyone’s happy with. This may include assigning that job to somebody else. This is a valid solution, but keep in mind that’s only one of several solutions.

Wrapping it up

Onboarding new team members is a complex process, involving a lot of social interaction. Don’t concentrate on the technical aspect alone. The blogosphere is full of technical discussions, but in reality, projects almost never fail because of technical issues. They always fail because people don’t collaborate.

I’m sure I’ve barely scratched the problem. What’s your experience? Feel free to leave a comment. I’m looking forward to hearing from you!

UI Survey 2017: Java vs. JavaScript

Recently, I’ve seen a number of surveys covering the popularity of Java and Java UI frameworks. Most surveys show that either Spring or Java EE is more popular. However, they don’t answer two important questions: is Java becoming more or less important? Currently, I’m mostly interested in UI frameworks, so the next logical question is: what is the market share of Java UI frameworks compared to JavaScript UI frameworks?

To my disappointment, I didn’t find a clear answer, neither by researching the internet nor by asking the question on Twitter. So I’ve started to gather information myself. That wasn’t easy, so most of the article is based on indirect hints and educated guesses.


My first surprise was when I learned about ng2-bootstrap in December 2016. At the time, Angular2 itself was still brand-new. So it won’t surprise anyone that the third-party libraries had a hard time catching up. In other words: At the time, ng2-bootstrap was a promising library, but it still had a long way to go. Compared to BootsFaces, it’s still a tiny library. In early April 2017, it consists of merely 17 components, as opposed to the 74 components of BootsFaces.

Nonetheless, ng2-bootstrap had been downloaded 70.000 times in December, give or take a few. In early April 2017, the download counter even shows 204.000 downloads per month. Compare this to 2.000+ downloads of BootsFaces per month. Oops! Such an unfinished library is 100 times more popular than the fire-proven BootsFaces?

Of course, BootsFaces is one of the smaller JSF frameworks, but even the so, ng2-bootstrap seems to be more popular than all JSF component libraries together. My curiosity was piqued.


Another indicator of the popularity of a framework is Google Trends. I’ve compared the number of search requests of JSF and Spring MVC:

Comparing the Google Trends of JSF and Spring MVC
Datasource: Google Trends (

Both frameworks seem to be roughly equally popular. JSF used to be much more popular in the past, but it has lost a lot of popularity in recent years.

Actually, the dwindling number of search requests may have a different reason. In 2004, there were three times as many search requests to JavaScript than today. But it’s unlikely JavaScript is used less today. It’s much more likely that developers ask other questions today. Or maybe they simply ask less question because they’ve learned how to work with JavaScript. The same may hold true for JSF. I’m even told JSF is gaining traction again.

Adding Angular and React to the equation

However, adding AngularJS and React.js to the trends analysis changes the image radically. There are 10 times as many search requests for React.js and 20 times as many search requests for AngularJS:

Comparing the Google Trends of Angular, React.js, JSF, and Spring MVC
Datasource: Google Trends (

Again, that might simply mean that there are twenty times as many problems with Angular than with JSF. Plus, the search may be biased by my selection of search keywords. For instance, both Angular and JSF are “topics” of Google Trends, while React.js is categorized as a “JavaScript library”. Spring MVC is merely a search term. So it’s hard to say whether “Spring” or “Spring MVC” is the better keyword to find out about the UI framework of Spring.

Be that as it may, the trends are impressive. Plus, I’m working with Angular2+ on a daily basis. It’s a good framework, not a source of problems. Still, the huge quantity of Google searches may simply mean the developers are still learning how to use Angular. But I believe the trend also indicates that Angular and React.js are more popular than Spring MVC and JSF.

What about other frameworks?

I know that there are countless other UI frameworks, both in the Java realm and the JavaScript universe. I’ve limited my research to these four frameworks because they seem to be the most popular ones. I’ve entered quite a few other frameworks in the search bar. That didn’t change the results significantly, so I didn’t include them in the charts.

Trends of programming languages

Another indicator is the popularity of JavaScript and TypeScript. In many rankings, JavaScript, Java, and C are the most popular languages. Even if the Tiobe index indicates that JavaScript and TypeScript are much less popular than Java: Java is a general purpose language, while JavaScript and TypeScript are still being used almost exclusively in the browser. It’s possible to write server or desktop applications using JavaScript, but if I’m not mistaken, that’s still a small niche.

The last indicator is the strategy of PrimeFaces. Recently, they spend a lot of time developing the JavaScript offsprings of their JSF framework. I gather that has something to do with market shares.

Wrapping it up

For some reason, it’s hard to find information about the market share of Java and JavaScript UI libraries. Such surveys are sparse, and most of them concentrate either on Java or JavaScript. So much of this article is speculation. Nonetheless, I’m under the impression that the JavaScript UI market is five to ten times larger than the Java UI market.

Come to think of it, that’s not surprising. Java UIs are almost always used with Java back-ends. Client-side web application can be used with any back-end. That includes .NET, SAP, databases with REST APIs and even PHP. Plus, JavaScript is the language of choice for web designers.

However, I’m surprised that Angular seems to be so popular in the JavaScript world. Angular specifically targets enterprise applications, and that’s only a small fraction of the JavaScript applications. I reckon much of the rise of Angular and – to a lesser extent – React.js is at the expense of traditional server-side web frameworks.

By the way, that doesn’t affect my commitment for BootsFaces. Even if the estimated community of roughly 10.000 developers is small in comparison, that’s still the population of the village I’m living in. And it’s a lot of fun to help so many developers!

Dig deeper

Java Web Frameworks Index February 2017 by RebelLabs
Spring MVC vs. JSF
Spring MVC vs. JSF vs. Angular vs. React
License of the Google Trends screenshots

What’s New in BootsFaces 0.9.0?

Fork me on GitHubAfter seven weeks of hard work, we’ve published BootsFaces 0.9.0. It’s a major improvement over BootsFaces 0.8.6. Unfortunately, a little error slipped through our QA gate: It seems we’ve involuntarily published a Java 8 version. If you are using Java 6 or 7, you’ll have to wait until 0.9.1 comes out in a few weeks, or you may use the developer snapshot on Maven Central. It was a small bug, easy enough to fix it within a day.

While BootsFaces 0.9.0 is more than a bug-fix version, it clearly concentrates on polishing BootsFaces, removing bugs and finishing things we had started in previous versions. That’s not a small achievement: Fork me on GitHub the number of commits on GitHub went from 856 (BootsFaces 0.8.6) to 1028. And that’s only the base library. The showcase has improved a lot, too. And we’ve managed to finish a component many developers desperately need: <b:dataTable />. What makes this component unique in the JSF world is that it is rendered on the client. That makes it feel a lot faster and much more responsive than traditional server-side data tables. We’ve already received a lot of bug reports and enhancement requests, even during the development phase. Thus I’m sure the data table will remain in our focus during the new few updates of BootsFaces.

A more liberal license

Probably the most important point of BootsFaces 0.9.0 is the license. Now, BootsFaces is available under an Apache V2 license being a lot more liberal than the old GPL V3 license. For example, you can use BootsFaces in commercial products without further ado.

Continue reading

Running the Atom Editor Behind a Firewall

Granted, this is a minor topic, much less sophisticated than most of my blog’s posts. But it took me a couple of hours to find out how to run the Atom editor behind a firewall, so it me be worth a short article.

If you’re running Atom behind a firewall, you won’t be able to install plugins not updates until you configure the proxy settings. Basically, all you have to do is to set two user-defined variables: http-proxy and https-proxy. However, it’s not that obvious where to configure these variables.

The easiest way find or create the configuration file is to open the settings dialog (“File” –> “Settings”). On bottom of the left hand side, there’s a button called “Open config folder”. Clicking it opens a new project (.atom). That’s the settings folder in your user profile. The root folder should contain a file called .apmrc. If it doesn’t, create it.

Next you add these lines to the file (replacing username, password, proxyserver and the port number with the settings you use in your internet browser):


Don’t add the variable proxy, nor try to write the variables in capital letters. Sometimes people suggest these things, but Atom ignores these variables.

Not that you have to prefix the proxy server name with http://. If you omit it, you’ll get a “parse exception”. In my case I had to use http:// for both the http and the https protocol – but that may be a peculiarity of my company’s network.


JSF vs. PrimeFaces vs. BootsFaces Search Expressions

It’s a bit inconvenient and error-prone to define an ID for each input field, each label and each message of a JSF view. You can make your like easier using the advanced search expressions. Used wisely, advanced search expressions enable you to move input fields on the screen or between JSF views without having to update zillions of ids. In fact, search expressions are possibly the most compelling reason to use PrimeFaces or – since version 0.8.0 – BootsFaces. Their search expression engines go far beyond the JSF standard.

Why are there different search expression engines?

Traditionally, JSF relies heavily on ids. Standard JSF 2.x adds a few generic search expression that allow you to get rid of the ids in many cases. The PrimeFaces team – and Thomas Andraschko in particular – took the idea to another level. They implemented a variety of new search expressions such as @next and @previous. Unfortunately, these search expressions can only be used with PrimeFaces widgets. There’s an open ticket offering to implement the PrimeFaces search expressions in the Mojarra framework. Last time I looked the ticket was still dormant, laid aside due to performance considerations.
Continue reading


These days it’s kind of official: AngularJS implements the Model-View-Whatever paradigm. That’s a nice solution to a series of fruitless discussions about whether AngularJS implements MVVM, MVC or something else.

However, one of these days I stumbled upon a couple of slides claiming AngularJS implements the MVC pattern during my research for another article. I knew from various tutorials that this isn’t exactly true. My curiosity was piqued. What exactly is the difference between MVC, MVVM and MVP? Are there other useful design patterns? And while we’re at it: do JSF and AngularJS implement one of these design patterns?

Model-View-Whatever 🙂

Actually, I already knew there are different design patterns you can use successfully. When I implemented my former company’s framework, I got the idea of MVC wrong. So I implemented something slightly different. That earned me a lot of trouble with external consultants. You know, every once in a while we invited a consultant to look over our architecture. Inevitably, they would complain about our non-standard implementation. But our implementation worked, and it worked well, so what?

That’s an important thing to keep in mind: don’t waste your time on this nonsense. It’s like talking about politics: it’s a lot of fun to discuss about the advantages of MVP over MVC and whether your program following on paradigm or the other. But at the end of the days, it’ll change little. It’s more important to chose a clean, sustainable architecture and stick to it. If you need a name, call it Model-View-Whatever. Whatever works for you.

But today I’m not going to listen to the voice of reason. Today I want to have fun. Let’s dissect the design patterns, and let’s see how JSF and Angular fit into the pattern.

At a glance

Look at these pictures. They cover three of the most popular patterns: MVP, MVC and MVVM. Don’t soak yourself in the details – that’s what the rest of the article is about. Just look at the general picture. Do you notice anything?
Continue reading

Comparing JavaScript to ECMAScript 6

Not long ago, the specification ECMAScript 6 – the successor of (guess what) ECMAScript 5, more commonly know as current JavaScript – has been finalized. Already browser developers are busily implementing ECMAScript 6 features into their browsers. So it’s interesting to compare the two versions of the language. As to my impression, ES6 is much more concise, legible and accessible to developers coming from classical object oriented languages.

Ralf Engelschall compiled a nice comparison of typical snippets of the two languages.

There’s also a comprehensive compatibility matrix. It’s interesting that at the time of writing even the best transpilers don’t exceed 59% (Traceur) or 71% (Babel+core.js) compatiblity (according to the compatibility matrix). On the other hand, the most popular desktop browsers – which are targeted at the mass market and can’t afford to implement features speculatively, only to remove them later – support ES6 already remarkably well, most of them exceeding the 50% mark.

Should You Avoid or Embrace “Static”?

More often than not, the keyword static confuses Java programmers. As a consequence, Ken Fogel asks his students never to use static in Java unless explicitely told to do so. While that’s a good hint for starters, it’s only part of the story.

Funny thing is, I recommend to use static as often as possible. There’s a twist: Never use static variables, but always use static methods.
Continue reading

BootsFaces 0.6.6, Easter Edition

Fork me on GitHubStop looking for our Easter egg: you’ve found it. The BootsFaces team celebrate Easter with a new version of their responsive JSF framework. By now, BootsFaces is available on Maven Central, and in a couple of days it’ll arrive on the jCenter repository.

Basically, BootsFaces 0.6.6 is a bug fix release. There are also a number of minor improvements, such as adding the style attribute to a number of components that ignored in in the previous version.
Continue reading

Happy New Year 2015 – the Year of the Palindrome!

You readers rock!

In 2014, BeyondJava has been read more than 400.000 times. That’s 400.000 reasons to carry on.

What’s in score for you in 2015? Time will tell… but there are a few articles I’ve already prepared, so I can pique your curiosity. BootsFaces 0.6 has just been released, so it deserves an article or two. Soon I’ll release AngularFaces 2.1. That’s the first version of AngularFaces that has extensions specifically for BootsFaces. JSF will remain a hot topic, as well as AngularJS and AngularDart. I’d like to write a couple of philosophical articles. “How to Abuse a Framework” is the working title of one of those articles.

I’m also preparing a series of articles dealing with how the JVM works. Did you know your Java program is compiled to machine code – sometimes, that is? Did you know how to read and analyze this assembler code? Did you know which optimizations the JVM performs? Stay tuned!

Maybe I’ll also include articles about WordPress. That’s the platform of this website, so I’ve learned a lot how to do thing and how not to do things. During the last couple of days I’ve started to make the website faster again. Chances are I’ll write an article about how to optimize WordPress performance.

Oh, just in case you didn’t read the geeky part of Twitter: 2015 is a palindrome. Written as a binary number, it’s 11111011111.

Welcome to the year of the palindrome!

Newsflash: Java, UTF-8 Surprises and Character Encodings

Did you know characters don’t always fit into chars?
Did you know String::length() does not always return the number of letters of the String?
Did you know you can’t reliably read a text using a ByteArrayInputStreamReader?
Did you know many characters have more than one Unicode encoding?

The latter you should know, at least if you’re concerned about writing a secure web application. Hackers sometimes hide their malicious code by using ambiguous UTF-8 encodings. If the request is interpreted correctly, it simply contains an odd character. But if your application interprets the request as simple ASCII code, it contains executable Javascript code. The “<” sign can be hidden as a modifier to a unicode character, so a (careless?) firewall doesn’t recognize it as the start of malicious code.

Before leading you to McDowells great “guide to character encoding”, I’d like to show a couple of interesting characters to you:

  • The letter A is encoded in UTF-8 as 0x41. That’s simply good old 7-bit ASCII code.
  • The french letter é (as in écouter) is part of many 8-bit extensions of ASCII. In UTF-8 it’s encoded as C3 A9.
  • However, it also can be constructed as a combination of “e” and the accent “´”. That amounts to 0x65CC81 in Unicode. That’s the first example of the three byte representation of a character.
  • Characters can become as complicated as क्तु. That’s a 12 byte encoding in UTF-8: E0A495 E0A58D E0A4A4 E0A581. As far as I can tell, that’s a base character followed by three modifiers.

The last character doesn’t fit into a Java char, and "क्तु".length() yields 4 – albeit it’s considered a single Devenagari letter.

There’s a lot more information on Java character encoding on McDowells “exhausting, but not exhaustive” article Java: a rough guide to character encoding.

Using Local Libraries With Maven

Maven’s central idea is to use libraries stored at a trusted central repository, such as Maven Central. However, sometimes you need to use a library that’s not stored in such a repository. This applies to legacy libraries as well as to developer versions. In my case I needed the developers’ build of PrimeFaces containing the latest changes, so I had to build my own snapshot.

A co-worker of mine found a nice decription how to make Maven use such a local library.

JavaOne 2013 Talks and Slides on

There’s good news to all those who hadn’t the opportunity to visit this years JavaOne: Quite a few talks have been published on At the time of writing roughly 60 talks are available for you. Most of the videos are just the sliders with the audio track underlaid, so don’t be surprised if you don’t see the speaker waving her or his hands.

From’s point of view it’s interesting only seven talk deal with languages other than Java. The languages covered are Scala and Groovy, and of course the inevitable lingua franca of the internet: Javascript. Maybe – just maybe – Scala and Groovy are slowly making it into the mainstream development. The news I’ve read lately indicate dynamically typed languages such as Ruby are slowly declining, while there’s growing interest in the Scala language.

Further reading:

The JavaOne home page
JavaOne 2013 talks at
Google trends on Scala, Groovy and JRuby

When Political Decisions Raise Java Exceptions

Preparing another example for the AngularFaces showcase I just noticed a funny thing: the current period of low interest rates is a challenge to programmers!

Decades of banking apprentices learned how to calculate the monthly payment rate of a loan like so:

(see Wikipedia)

or translated to Javascript code:

var q = 1 + (interestRate / 100);
var annuity = amount * Math.pow(q, loanTerm) * (q - 1) 
             (Math.pow(q, loanTerm) - 1);

These days many interest rates are very close to zero per cent. Sometimes they even reach the 0 per cent mark, and that’s where the problem arises: traditional formulas fail because of the singularity. A DivisionByZeroExcetion is raised.

Of course it’s pretty simple to solve the bug. But I guess hardly anybody thought of crashing computer programs when the Bank of Japan lowered it’s interest rates to zero. That’s more than a decade ago, but still, the story might repeat now that both US fund rates and ECB refinancing interest rate are close to zero:

Source: Wikipedia

As I mentioned, it’s not a big deal to solve the problem. The bottom line it has to be solved by someone (computer programmers, to be precisely) – and it’s a nice example of unexpected side effects of decision done by politician and managers. I suppose many people aren’t aware of those side effects, and they’d be pretty surprise to learn how much money many decisions they consider harmless cost. Mind you, every financial institute has to correct their software to be able to cope with a zero interest rate!

Actually that’s not a new phenomenon. Many programmers become very busy when new laws are passed or important treaties are changed. For instance, my companies work is based on a collected labor agreement, and most changes of the treaty have to be mapped by our software.

But of course I’m not one to complain. I’m making my living solving those problems :).

Starting External Programs Without the Pain

Today, I’ve found a nice description why Java’s RunTime.exec() method feels to clumsy. Since Java 5 there’s a major improvement – the ProcessBuilder class – but still, it could be done better. AdiGuba offers an library to do so (see Runtime.ecec() n’est pas de plus simple). If you’re able to read an article written in french, you will find a nice API.

A problem that hasn’t been solved by this API is that you can’t influence a process you didn’t start. Sometimes it happens that your Java applications starts an external process, crashing before the external process stops. You can restart your Java application, but it cannot kill the process its predecessor called into life. If you want to to things like that, you have to use JNI and to do some native C coding.