Zero Bug Tolerance Intolerance

12. July, 2011

Jim Bird has written a great post about reasons to fix bugs and reasons to leave bugs alone: Zero Bug Tolerance Intolerance


Restarting a Java App

9. July, 2011

Leo Lewis posted some code to restart a Java app.


Boo

8. July, 2011

It seems a dream of mine has come true: A language like Python, compiled into something that can be executed as fast as Java or C++ and which allows to extend the compiler at compile time.

Ladies and gentlemen, please a warm welcome for Boo.

Guess I’ve found a reason to install Mono.


TNBT – Avoiding Common Errors

7. July, 2011

Writing secure code is ever more important. There are lots of examples: HBGary, Sony, Google.

Even if you’re not one of the biggest companies out there, security starts to become important as soon as your code can be accessed from the Internet. And frankly, which code today can’t?

What’s worse, the problems are always the same: SQL injections, not validating input, using code from somewhere else which is vulnerable. These problems are neither hard to find nor hard to fix. It’s only too much effort to add the necessary checking and warning code to the existing compilers.

So here is my assumption for my “The Next Best Thing” series of articles: The programming language will allow to define patterns like FindBugs and PMD that the compiler will check at compile time and which the VM checks at runtime to fix or at least warn about such security problems.

With tools like MoDisco and Moose, it’s possible to go one step further: It could analyze and display the code in ways that you haven’t seen before (think Code City) to find patterns in the code automatically and warn you about something that you might not have realized, yet.

For example, if you use a certain call sequence everywhere in your code but one place, it’s probably worth a look.

Of course, this begs for a way to add lots of additional information to source code. As I said before, we probably want better editors than the plain text editors we have today. It should be possible to include images and formulas in code. Wiki documentation. And things like “yeah, I know, this is different from the 365 other places!”

Sounds a bit like annotations but frankly, Java source code can just get you so far. DSLs come to mind but they don’t allow to extend them with arbitrary extra bits of information. It should be possible to overlay a DSL with another DSL so you can mix various information in one place.

Related Articles:

  • The Next Best Thing – Series in my blog where I dream about the future of software development

Java Finalizer Exploit

6. July, 2011

Did you know that your Java code may be vulnerable to an exploit based on finalization? I didn’t.

This article from IBM’s developerWorks explains how it works.

Basically, you can safe a reference to an object in the finalize() method. At this time, the object may even be in an inconsistent state (the finalizer will be called when the constructor threw an exception).

As for the solution: I don’t like it very much. It adds even more clutter to the existing code and doesn’t relay its purpose very well. Someone refactoring the code might feel tempted to remove the “useless additional constructor.” Worse, you need to do this in all your classes which check their parameters.

I would prefer a solution where the compiler or some other tool fixes these issues by generating the necessary code. Especially if you look at more complex cases: What happens if an exception is thrown at a later stage of object creation? Your code is still vulnerable but it seems to be safe. How would you know?

Maybe a better solution would be to check the heap for references to any finalized objects and throw an error “finalization failed”. But that’s probably impossible without breaking backwards compatibility.

Or Oracle could invent a better solution for the finalization problem (which is basically garbage collection for non-memory-resources) so we would not need finalizers anymore.


Xtext2: Missing NAMED_BUILDER_SCOPE

29. June, 2011

The constant NAMED_BUILDER_SCOPE has been moved from org.eclipse.xtext.scoping.impl.AbstractGlobalScopeProvider to org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider.


Software Patents – More Harm Than Help

28. June, 2011

James Bessen did another study which shows again that software patents harm more than they help. Abstract:

This report examines changes in the patenting behavior of the software industry since the 1990s. It finds that most software firms still do not patent, most software patents are obtained by a few large firms in the software industry or in other industries, and the risk of litigation from software patents continues to increase dramatically. Given these findings, it is hard to conclude that software patents have provided a net social benefit in the software industry.

“A Generation of Software Patents” by James E. Bessen

Links:


Missing m2e?

28. June, 2011

If you downloaded the JEE edition of Eclipse 3.7, you’ll find that m2eclipse is missing.

Don’t worry, it’s part of the Indigo release train. Just install it manually from the Indigo p2 repository: http://download.eclipse.org/releases/indigo

Links: Oh my god, but where is m2e?

 

 


UI Editor With Preview

28. June, 2011

One of the big problems with WYSIWYG editors is that they don’t really cut it. They look good in the beginning but as your experience grows, the editor tends to get in your way of getting things done.

Stackoverflow used an interesting solution: There is a wiki markup editor and a preview which is updated as you type. So you get the best of both worlds: You can see your intention and the result at the same time.

Riena is now following along the same path: They created a preview which updates when you save your UI code. That way, you can quickly see the effect of your changes without stumbling over tedious property editors all the time.


What’s Wrong With XA/Two Phase Commit

27. June, 2011

To recap, two phase commit (XA) means that you have two or more systems which take part in a single transaction. The first phase ask all system “are you 100% sure that you can commit?” (prepare) and the second phase is the actual commit.

Of course, the answer to the first question can be a lie. You can never be 100% sure that a commit will go through. The system might crash in the middle of the actual commit or the network my break between prepare and commit. Doom.

So XA doesn’t when it should. How can you solve this?

By using a less brittle protocol. Imagine you want to copy data from database A to B. You could use XA and clean up the mess every once in a while.

Or you could add a field to A which says “this has been copied to B” and when inserting data into B, you must ignore data that is already there. Here is the pseudo code:

  1. Create the connections
  2. Find all rows in A that don’t have the flag set
  3. Read all the rows and insert them into B. If a row already exists, skip it.
  4. Set the flags for all copied rows in A.

Note: You can’t use MAX(ID) or MAX(TIMESTAMP) here. Why not? Imagine:

  1. TX1 is created in A and a row is inserted. MAX(ID) == 2
  2. TX2 is created in A and a row is inserted. MAX(ID) == 3! At this time, you can’t read WHERE ID == 2 but you can conclude from the gap in the ID values that it will soon exist.
  3. TX2 is committed.
  4. TX3 is created to copy the data to B. TX1 is still running! MAX(ID) == 3 but row 2 will not be copied!
  5. TX3 ends without row 2. Since MAX(ID) is now 3, it won’t ever be copied.

If you’d rather avoid a “to copy” or “has been copied” flag in each row, create a “to transfer” table which contains IDs of the rows to copy. In step #4, delete the rows that have to be copied.

Advantages:

  1. Resilient. If the transfer fails in the middle for any reason, it can pick up where it left of. In the worst case, a lot of data will be copied again but data will never be lost. In the usual case, no data will be copied twice.
  2. If you make a mistake, chances are that it won’t have matter much. Say you forget to set the “has been copied” flag. Well, for every transfer, too much data will be copied but it will still work. Slower than expected but you won’t lose data. The database will always be consistent!
  3. Say something goes wrong in B and you need to transfer the data again. With my approach, you just reset the flags. It doesn’t matter if you can’t say for sure which flags to reset. If in doubt, reset all of them. The algorithm will heal itself.
  4. You can copy the data in chunk sizes of your choice. It doesn’t matter if you copy everything in one go or in blocks of 1’000 rows or row by row.
  5. It’s a simple algorithm, so it will be quick to implement and there is only a small chance for bugs. Even if there is a bug, in most cases, you will be able to resolve the situation with one or two simple SQL queries.

Disadvantages:  The XA sales guy won’t make a buck from it. Expect some resistance.