How I Came to Hate Orbit

29. February, 2012

Orbit is an Eclipse project which contains IP clean OSS code to be used in Eclipse projects.

Why is that important? Well, IP clean means that big companies who consume Eclipse code, can use it safely (their lawyers have to check the EPL once and after that, their developers can use any code they can find on eclipse.org).

Now, Eclipse writes a lot of source code but not everything. commons-io, for example, contains a lot of code which would be really cool to have for Eclipse projects.

Orbit was created to have just that: Copies of OSS code from all kinds of places relicensed under the EPL. Sweet.

Enter stage: maven.eclipse.org

The idea behind maven.eclipse.org is to provide projects outside of the Eclipse foundation a place where they can find Eclipse’s OSGi bundles as Maven artifacts (which are easier to consume when you build your projects with Maven). Sweet 2.

To make the Eclipse bundles available on maven.eclipse.org, I need to convert them. Part of that process is to assign each Eclipse bundle (which has bundle ID and a version) a Maven coordinate (which consists of group ID, artifact ID and version). That’s not always simple but I’ve found a rule that works pretty well.

If it wasn’t for Orbit.

Orbit contains bundles which you can also find on Maven central. One example is commons-io.

And Orbit didn’t simply copy the JAR from Maven Central – they changed it. In this case, the changes are purely for legal reasons (EPL license, moved a couple of files around). Not a big problem here. I could map the two to the same coordinate – except that you would sometimes build software which contains code licensed by Apache and sometimes code which is licensed by EPL. Worse, some other code might be under the viral GPL on Maven Central – linking that could turn your project into open source! Not a problem for most developers but it could be a problem for your legal department and guess which head is going to roll?

But there is more.

Let’s have a look at … org.apache.batik.pdf. This is a fragment of the Batik’s rasterizer JAR from Maven Central. In this case, we have several issues:

  • Orbit has split a single artifact from Maven Central into several Orbit bundles. Which bundle should get the same coordinate as the original Maven Artifact?
  • The Orbit bundle also contains code from commons-io and commons-logging. So it pollutes your classpath with classes that you don’t expect. Worse, someone (not the Eclipse guys) removed “unnecessary” methods from some classes copied from commons-io. So if the compiler sees this JAR on the classpath, you will get errors for many methods in the class IOUtils. Bad.
  • Some Orbit bundles have bugs fixed but the version hasn’t been changed – only the qualifier changed which works if you use OSGi to build your classpath but Maven doesn’t. A couple of bundles from org.apache.batik are among them (bug 329376).

While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.

Leave a Comment » | Software | Tagged: , , , , , | Permalink
Posted by digulla

Open Source As Good As Proprietary Software

28. February, 2012

The Coverity Scan 2011 Open Source Integrity Report (registration necessary) says: “Open source quality is on par with proprietary code quality, particularly in cases where codebases are of similar size.”

Which isn’t that surprising considering that it’s the same people who write both.

But there are a couple of hard number in the report which are interesting:

Linux 2.6 has about 0.62 defects per 1000 lines of code (KLOC) which Coverity says “is roughly identical to that of its proprietary codebase counterparts.” They can’t tell names but I guess the counterparts are Windows and Mac OS X. They have 0.64 defects per KLOC.

The industry average is 1.0 defects per KLOC which matches well with my (more anecdotal) knowledge that the best software developers make about 3-4 mistakes per KLOC of which 75% are found during development.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

I See You And Jesus, Too

27. February, 2012

A burglar breaks into a house. As he combs the rooms for loot, a strange voice calls out: “I See You And Jesus, too”

He jumps and flashes around with his torchlight but there is no one except him. Thinking it might be some kind of device to scare people off, he continues to search valuables.

“I See You And Jesus, too”

Again this really odd voice. The thief starts to relax.

“I See You And Jesus, too”

This time, the thief is quick enough to see where the sound is coming from: There is a parrot in a cage hanging from the ceiling. Not really expecting an answer, he says: “You freaked the hell out of me! Who are you?”

“My name,” the parrot replied proudly, “is Nebuchadnezzar.”

The thief starts to laugh: “Nebuchadnezzar! What kind of fool calls his parrot Nebuchadnezzar!”

“The same fool who calls his pit bull Jesus.”

1 Comment | Fun | Tagged: | Permalink
Posted by digulla

How Would a Sentient Robot Respond to an Invitation to a Board Game?

24. February, 2012

“Physical game pieces? … Well, I guess we’ll play like savages, then.” (from Ctrl+Alt+Del)

The next page is great, too. I like his first move: “I win” 😉

Leave a Comment » | Fun | Tagged: | Permalink
Posted by digulla

EFF Tries To Sanitize Patent Law

23. February, 2012

The EFF has started a new campaign to clean the patent system.

I’ve blogged about the many problems of the parent system when it comes to software. If you care as well, at least spread the word. If you want to do more, check out the EFF site or maybe  help with the Patent Busting Project.

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla

Code Is Design

22. February, 2012

If you look for reasons why software development is often such a mess, here is an interesting, new angle: Code Is Design by Ryan Brush.

Leave a Comment » | Software | Tagged: | Permalink
Posted by digulla

Trying to Hide is Futile

18. February, 2012

There have been many good arguments to avoid all contact with any extraterrestrial life form (“aliens”): Stephen Hawking warns over making contact with aliens

The consequences of an alien contact would probably be dire:

  • Mass panic of people whose religious beliefs, the very foundations of their sanity, are being questioned (they might take the aliens for demons or fallen angels or take their presence as an excuse to start Armageddon).
  • Implosion of the patent system (because aliens probably have prior art to anything we’ve been invented so far)
  • Transmission of germs (even though I believe that aliens would know about this problem, too, and they should have thought a solution – our germs are as much of a problem for them as theirs are for us)
  • Superior ideas (how long could mankind withstand the lure of, say, a system that allows you to do anything without leaving your bed?)
This blog toys with these ideas in some more detail.

But can we avoid them? The discussion often revolves around the idea that we should minimize our electromagnetic footprint and active signals to attract aliens should be avoided at all cost.

While I see the risks, I don’t see how avoiding to send radio signals is going to help us. It’s a good idea to tone down electromagnetic signals (because that ultimately means to waste less energy) but there is a signal that we’ve been broadcasting for hundreds of millions of years and which we can’t avoid: Breathing.

How’s that? Breathing changes the composition of our atmosphere. The composition is easy to detect using a spectral analysis, even over great distances. Astronomers use it since 1835. Exactly this method was used to find the first earth-like planet a few weeks ago.

So unless we stop breathing and kill all other life on our planet, we are constantly distributing a strong, telltale signal that we’re here.

Leave a Comment » | Philosophy | Tagged: , , , | Permalink
Posted by digulla

Excellent Argument Against Meeting Alien Lifeforms: The Metal Dilemma

16. February, 2012

Some metals are more rare than others; earth’s computer industry is lethally dependent in the so-called rare earth elements. They are rare because of how they are created: When a star dies violently. Each atom of gold, silver or copper was once created in an exploding star because the normal fusion process can only produce elements up to iron (fusing iron with anything else needs energy while fusing, say, hydrogen with itself produces a lot of energy). To see for yourself what is missing, check the elements beyond iron (Fe 26) in the periodic table.

In fact there are areas in the galaxy where metal is more rare on earth because there haven’t been many super novae around there: Maybe the stars are still too young, maybe they are too small to go nova. This is what you can find near the rim of the galaxy. Most metal can be found near the core of the galaxy where there are many massive, tightly packed stars. The problem here is that life is a tad difficult near the core because of the heavy radiation.

So there has to be a sweet spot between: Just enough metal but not too much radiation. This is where we life.

Does that mean life near the rim is impossible? No. Most elements to sustain life (carbon and oxygen, most prominently) are available everywhere in the galaxy (this is easy to prove by looking at the spectral lines of the stars in question). So there is life not no (or not much) metal there.

Now imagine a life without copper. No wires. No telephone. No computers. Maybe they could build wires with aluminium but for computers, you need semiconductors. For these, you need silicon (which they have) but also elements to “taint” the pure silicon – the rare earth elements. Germanium. Gallium. Arsenic. All beyond iron in the list of chemical elements. They could use silicon carbide but the material has a lot of problems.

Without all the elements beyond iron, it’s probably hard to build a complex civilization. Radio telescopes. Space ships.

They might exist but they probably can’t leave their planet. Or receive any of our signals.

Related articles:

Leave a Comment » | Philosophy | Tagged: | Permalink
Posted by digulla

Survival in Vacuum

16. February, 2012

Just for reference: “Clarke got it about right in 2001. You would survive about a ninety seconds, you wouldn’t explode, you would remain conscious for about ten seconds.”

From Human Exposure to Vacuum

Leave a Comment » | Philosophy | Tagged: , , | Permalink
Posted by digulla

AgileUnit – The Future Of Testing?

15. February, 2012

AgileUnit is a new testing framework which puts the testing code and all your assumptions into the business logic.

The main advantage is that you can make sure that your assumptions are met as the customer uses your product. To drive this home: The tests are running while the code is in production and while real customers use it.

At first glance, this sound reasonable but there are a few catches:

  1. Test code doesn’t stop early when you disable it. This means that the AgileUnit code makes your product slower at runtime. Each added test will make the situation worse. I have a feeling that each test will read the property file from disk – every time the method under test is run.
  2. User input isn’t tested, only the predefined test cases are run.
  3. Only primitive types plus some numeric types (Date, BigDecimal) can be tested. If your methods work with lists, maps or other complex data structures, then AgileUnit is not for you.
  4. Test failures will show you the result of a computation but not the arguments. In the “sum” example, you get an error that the “input” (which is actually the result of the sum() method) is less than 0 but the inputs of the sum() method are not listed so there is no way to know why it failed (just that it did).
  5. Tests are configured with huge property files (which you don’t have to edit by hand) but which are pretty unreadable. This also leads to cluttered test code. Things that I can do in a single line of code in JUnit take 20-30 lines of code and properties with AgileUnit.
  6. The documentation is confusing, outdated and riddled with spelling mistakes.
  7. Test code uses static variables which means you can’t use it in multi-threaded code.
  8. The configuration for the tests is not in the project but in the home directory of the user. All configurations for all projects are in the same folder which means you can’t work on two versions of the same project at the same time and you can’t put these files under version control.
  9. The sample project doesn’t work.

Conclusion: The idea to make sure expectations are met after a product has been deployed to production is intriguing but AgileUnit is not the solution. Some of the issues listed above could probably be fixed easily (lazy loading of properties, replacing the property files with a more powerful DSL) but the overall feeling isn’t promising. The code looks clean but for me, the project has too many problems which cry “this won’t get far.”

Leave a Comment » | Software | Tagged: , | Permalink
Posted by digulla

« Previous Entries
%d bloggers like this: