There are others that tell you the language doesn’t matter at least not between languages like Scala and Java. I think they are wrong as well. The reason is: Although I don’t actually use Scala during my day job it does affect my Java Coding. Here are some of the things I noticed.

• I appreciate immutability. I was aware for a long time of the benefits of immutability. But in Java using immutable data structures is so clumsy that I only used this approach in small areas, like rather simple value objects. But now I find my self more often tempted to use an immutable data structure even for relatively complex things.
• Lots of small classes. Classes in Scala are unbelievable small. It’s easy to write a single page of code with half a dozen classes in it if you count the ‘class’, ‘object’ and ‘trait’ keywords and even more when you look at what the Scala compiler creates from closures and similar. Although creating a class is much more work in Java I find myself thinking much strict about the single responsibility principle, resulting in more smaller classes, which are easier to test.
• Thinking more in DSLs. Scala is great for creating internal DSLs. Lots of libraries use that approach for designing their APIs and I do it in my little projects as well. Java is pretty useless for DSLs. But there are things you can do. Even if it is simple stuff like method chaining. I use that a lot lately, especially when testing is concerned, because here readability of code is even more important then with normal code.
• I pretty much gave up on Java Generics. After seeing what is possible with a good type system, even when the compiled code runs on the same JVM as Java, made me also see the severe limitations of Java Generics. Before that I tended to think its just me who is to stupid. While this assumption is often true. Many things I tried to do in the past with Java Generics just can’t work, because Java is lacking the necessary power (e.g. covariance and contravariance). So I drop generics from my code as soon as more then one type parameter gets involved.

So go ahead and learn a new language. Even if you can’t use it in your normal job. You still will learn useful stuff. But be warned. I might as well make you hate parts of your day job:

I really, really hate semicolons, primitives, arrays and collection APIs without higher order functions. And switching on Strings is a joke.

I think this view ia a little to simplistic. Java developers like fast results and progress just as all the other developers. But if you have a look at the environments in which java is used, you’ll often find large corporations and that is causing problems. If you are lucky enough not to have worked in a large company let me describe this wonderful experience.

In the typical large company you can’t just talk to the future users, ask them about their problems and solve those using software. You also have to adhere to all kinds of rules. Rules about how to implement the login. Rules about how to talk to other systems. Rules how to format your code. Rules about how to blow your nose. All those rules easily amount to one or two thousand pages.

While the amount of rules certainly is a problem rule alone aren’t a problem. I’m an absolute fan of rules in order to steer software developments. The problem with those “Large Company Rules” (LCR) is they are based from the largest most complex (or complicated) system the company ever encountered. Thus they dictate an architecture fit for a system consisting of 20 subsystems doing some thousand transactions per minute.

But surprisingly most of the systems are really quite simple with only few users. Yet they have to use everything IBM sells.

So all the java developers get used to EJBs, SOAP, Messaging and what not and many think this is the only way to write systems.

And that is the thing I blame many developers for: To many ignore what happens outside their current project. They don’t read, they don’t learn. And while I think the companies are guilty of making everybody think development in java is slow and complicated every single developer is guilty when at some day in the future his current project ends and he realizes there is no more demand for his skill set.

• I want to as much Scala development as possible. I really like that language and it offers tons of inspirations while still allowing me to build on my Java experience.
• I want to learn a little Clojure. Just because I like making knots in my brain.
• I will do some web development. My skills in that area are a little rusty and I don’t need much of them in my current main project, but I sure don’t want to do Swing development for ever.
• And of course I will continue to read as much as possible about a wide range of topics.

I’m doing this because I actually think it is time to say good bye to Java. The development of Java stagnated in the past and I don’t see any sign that its new owner is going to change that. So I need an alternative. For me that’s Scala.

On the other hand I’m kind of confident, that the JVM will survive for quite some time in a state that makes it a strong, interesting platform.

Of course I’m no prophet. Maybe Google buys Java and within two years it is the coolest language on the planet … if so, some Scala experience won’t hurt, because a cool Java will certainly contain lots of features from Scala.

Maybe Scala dies or something bad happens to the JVM. In that case  the broad range of programming concepts will make it easy to switch to any language of interest. So I’m feeling confident that my future as a software developer stays safe and interesting.

If I’d stayed with Java as my main language I still would feel safe … but I’d be not so sure about the ‘interesting’ part.

The trick is simple to provide data points for every parameter type of the test method. The JUnit Theories Runner will call the test method with every possible combination of datapoints. If you think a little about it you will soon realize some of the limitations of this approach:

• You’ll soon end up with lots of data point fields cluttering your code
• Parameters of the same type will receive the same set of parameters, even when the usable range of inputs is completely different.

Fortunately the developers of JUnit provided really nice solutions to these problems.

Instead of specifying single data points, you can provide a full array of datapoints using the @Datapoints annotation, like so (add imports for good measure):

This of course is much less verbose. Instead of an array you may provide a method returning an array, or at least it looks like this should be possible. But when I tried it JUnit seemed unable to handle the types correctly resulting in IllegalArgumentExceptions. Guess I’ll have to file a bug when finished with this article …

But we still need to take care of parameters which have the same type, but very different meaning and therefore different useful values. The clean OO way of doing things would be to get rid of the generic types like String and use stronger types like CreditCardNumber or Name instead. But then in a perfect world we wouldn’t need tests, because our programs wouldn’t contain any bugs to begin with. So lets try this instead (Again imports omitted):

Wow, thats a lot of code. Just look at the last piece and see what appears in the console when we run it:

just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Amex / Alf tested.
consider Amex / Willie tested.
consider Amex / Tanner tested.
consider Amex / Cat tested.
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Master / Alf tested.
consider Master / Willie tested.
consider Master / Tanner tested.
consider Master / Cat tested.
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
consider Visa / Alf tested.
consider Visa / Willie tested.
consider Visa / Tanner tested.
consider Visa / Cat tested.
2
3
4
7
13
23
42

Have a look at the row beginning with: “consider”. Obviously the Theory imagineThisIsATest gets fed with the values from the CreditCardSupplier and NameSupplier. The parameters and the ‘Suppliers’ are connected by the two annotations @AllNames and AllCreditCards. So whenever you have a parameter to a theory where the type alone is not sufficient for identifying the kind of values that should get used, you can simple create an annotation, which itself is annotated with a reference to a ParameterSupplier class and you are all set. You might think this is a lot of code for supplying a handful of parameters. You are right, but remember, that you can reuse your suppliers wherever you need names or credit card values in your tests.

Now let’s look at the first line of the output:
just wanted to show that I can access it @de.schauderhaft.junit.theories.AllNames()
It simply shows of that you get access to the annotation (and actually the signature of the compete test method. This can be very useful, when you want your supplier to behave differently for different theories. Have a look at the NameSupplier above to see how this works.

JUnit actually comes with an example where this is used, and I demonstrated it with the other theory in the demonstration code above. The @TestedOn annotation takes an array of values to be used as data points for the annotated parameter.

Thats it for today. I hope the power of theories became obvious, as well as the power you have as a developer to extend that mechanism. Again be warned: All this nice stuff is in a package named experimental for good reason. If you use it, you might find bugs, and thing will likely change at least in name in an upcoming version. Taking about versions, I am using junit4.8.1 for the examples.

For next week the conclusion of the little series about JUnit theories is planned, with a few thoughts on use and danger of this kind of testing.

Blender

A week ago I started learning Scala. One of the features I found pretty interesting are mixins and traits. That was just the point of time, when I read this little tweet of GeekyL:

“i am still not sure if mixins are super cool or dark magic.”

Of course I was instantly reminded of the time when the dinosaurs dominated the world and I was learning the first little bits of OO and C++. I thought inheritance and polymorphism was great and the solution for every possible programming problem there is. It turned out that was not the case. Actually inheritance can result in pretty ugly code.

So GeekyL’s tweet got me thinking: Do mixins have the same problem? What exactly are the problems with inheritance anyway? Time for a new blog post.

What are the problems of inheritance?

Inheritance for code reuse: It is tempting to have a class inherit from a superclass just because the superclass has some useful feature. Like this.

The problem with such code is that inheritance suggests a is-a-relationship, which in this case is just wrong. A UserEntity is not a PropertySupport, it just uses one.

Multiple inheritance: At least in java a class can only inherit from one superclass. But many classes are many things. For example, a Cat is a Carnivor, it is a FourLeggedAnimal and a FurryAnimal. Without multiple inheritance there is just no way how to model this with class inheritance. With multple inheritance you can extend all these classes at the same time, but now you inherit the top class Animal three times, which at least is ugly.

So the proper way to do this kind of stuff in java is to use delegation and interfaces:

Which works in the sense that you can pretty much express the kind of things you need to do, and which you might be tempted to solve with class inheritance. Of course the draw back is that you’ll have to create all theses trivial delegate methods.

In Scala you have the option to use Traits. Like so

Obviously this contains much less code duplication then the java version. Does it have drawbacks? You bet.

Mixins are firmly tied to the traits they use. Imagine a more complex trait, which itself uses many other clases and resources. Once you mix in such a trait you have a strong dependency. Therefor I suggest the following pattern for getting the reduction of code duplication from traits and the flexibility of delegates: Use Traits, which don’t have a real implementation, but use a delegate for doing all the real stuff, this way you can switch the implementation with touching just a single place:

Summary: Traits can be used to solve some of the problems of inheritance, but they might introduce strong coupling, which you can easily be avoided.

keys

Some days ago I was asked to set up a tomcat server for SSL. You’d think this is a no brainer. And it actually is when you proceed along the paved path. But if you deviate only a little, you are in big trouble. I solved the trouble I got in, and here is my story as a warning (and a helper for you).

Normally you would use the java keytool, to generate a certificate request, get that request signed by a certification authority (CA) and import it back into the the keystore. A little configuration in tomcat itself and you are done. Pretty easy.

But with the task at hand the problem was: The certificate was already there. Signed by a CA. Somewhere ‘in windows’. So the first question was: where the heck is this certificate stored in windows? It is in the certificate store, which I found under

Start\All programs\Administrative  tools\Public key management

Of course the exact location will vary, depending on your Windows version and language used. Once you find the certificate store, you’ll have to find the correct certificate. It should be under

Certificates (Local Computer) -> Personal -> Certificates

If you find more then one, you must identify the correct one. It should have the name of the domain you want to serve and it should have ‘Intended Purposes’ of ‘Server Authentication’.

Now that you have found and identified the certificate to use, the question is: how do you get it into the tomcat/java keystore? Well, first you have to export it into a file. In order to do that, select the certificate. Right click on it and select

All Taks -> Export ...

Most of the screens of the following wizard can be left as they are, with one important exception: You must ensure that the private key is exported along with the certificate. Of course you need to remember the location where you store the file, and the password you use for protection.

See the screenshot on the side. So all that is left to do is to load that certificate into the keystore, right? Well yes. The problem is: the Java keytool doesn’t support importing of private keys, and even for certificates without private key, the keytool doesn’t understand the pfx format which Microsoft uses.

Fortunatly other people had the same problem before and implemented a solution: The developers of Jetty. The Jetty download contains a jar File which we can use to load the certificate. You just need the Jetty jar, e.g.

jetty-6.1.3.jar

Which is contained in the normal download
and can issue the following command.

java -classpath jetty-6.1.3.jar org.mortbay.jetty.security.PKCS12Import <PFX-Datei> <keystorename>

obviously you’ll have to replaces the pointy brackets with the file name of the exported certifcate and the keystore. Warning: I don’t know what happens if the keystore already exists, I only tried it with a not existing one.

Voila your keystore is ready for use with Tomcat.

If you like this article you should also thank Chris Barber, who’s article was very helpful

card board box

I am always surprised how many unknown feature hide in a supposedly simple library. Todays example is JUnit. When inspecting the newest version (4.7) I noted an annotation I hadn’t noticed before: @Rule. WTF? I am looking at a testing framework and not at a rules engine, am I? So naturally I tried to find out what it is good for, and since not to much documentation is available my little research resulted in this blog post. Enjoy.

The purpose of the @Rule annotation is to mark public fields of a test class. These fields  must be of type MethodRule, or an implementing class. Such MethodRules behave similar to a AOP aspects, of course without use of any AOP library and specialized for Tests. They can execute code before, after or instead of a test method.  Example use cases listed in the release notes include:

• Notification on tests
• Setting up or tearing down resources, especially when they are used in multiple test classes
• Special checks performed after every test, possibly causing a test to fail.
• Making information about the test available inside the test

But ready made examples are boring, so I decided to try to implement something I was looking for all the time.

When writing acceptance tests with Fit or a similiar framework, you might end up with tons of failing tests, simply because the features aren’t implemented yet. But I don’t want this red lights hide a real red light, i.e. a test that worked before, but fails now. Therefore I’d like tests to get ignored just as if they where accordingly annotated, until they succeed for the first time. After that they should run (and possibly fail) just as a normal.

Let’s get started. First we need a little test case that can fail or succeed as we want. And this test case of course needs our annotated field:

Please note that I stripped all package and import statements for brevity. As you can see I already named my MethodRule implementation IgnoreLeadingFailure. It needs some way to track which tests ran successfully at least once. Since I am lazy, I stored this information in a property file.

The interesting part is the single method contained in the MethodRule interface:

public Statement apply(final Statement base, final FrameworkMethod method, final Object target)

base is the object that encapsulates the execution of the test method. The purpose of apply(..) is to provide a Statement. This Statement will get executed (or in the lingo of the interface ‘evaluated’). Typically you’ll return a Statement implementation, that wraps the Statement instance passed as a parameter.

method is the test method that will eventually get called and

target is the object containing that method. Note that you normally do not execute the method, but use it mainly to get more information about the test case the MethodRule is applied to.

With this information it should be easy to understand what my little class does: It checks if the test at hand was already executed successfully before. If this is the case, the same Statement is returned, that was passed as a parameter. Otherwise an anonymous implementation is returned which replaces any failure by a AssumptionViolatedException, and saves a successful test run in the property file. Note that the AssumptionViolatedException actually does not result in a ignored test, but gets displayed as a successful test, at least with the default runner, which doesn't really fit my needs, but one could easily fix that by a minor change in the runner but not without that change.

So here is my opinion about this new JUnit feature: It certainly can come in handy for (integration) tests, where one tends to need a lot of resources that need quite some setup and/or tear down. Implementation of a MethodRule is fairly easy, although not exactly straight forward. The biggest problem is that it is next to impossible for an average java developer who doesn't know this feature to understand what is going on. The annotated field is easily missed, since in many cases it isn't used at all in the test class. Once more all this could be straight forward when java would support natively things like aspect oriented programming or open classes.

If you want more information I suggest you drop by this blog post about 'Interceptors' which was the name for rules at the time of writing of that post.

So, what do you think of this feature? Any ideas for features that could be implemented using rules?

Mit dieser Aufgabe befinden sich wohl die allermeisten Entwickler auf ganz dünnem Eis. Wir sprechen von IT-Sicherheit und Verschlüsselung und damit von Dingen die schwer zu verstehen sind und die richtig unangenehm werden, wenn sie schief gehen.

Wie schwierig das zu sein scheint sieht man, wenn man danach googelt.

Denn dort ist zumindest zur Zeit fast nur Blödsinn zu finden, dabei ist eine sinnvolle Lösung oft einfacher, als das was da so vorgeschlagen wird:

1. jBCrypt herunterladen und mit in den Sourcepfad mit aufnehmen
2. Passwort hashen:

   String hashed = BCrypt.hashpw(password, BCrypt.gensalt());

   Das Ergebnis dieses Aufrufes kann dann entspannt in der Datenbank oder wo auch immer gespeichert werden.

3. Wenn ein Benutzer sich anmeldet, kann mit folgendem Aufruf, dass eingegebene Passwort überprüft werden:

   if (BCrypt.checkpw(candidate, hashed))
       System.out.println("It matches");
   else
       System.out.println("It does not match");

Viel einfacher geht es ja nun wirklich nicht. Bleibt noch die Frage:

Warum so und nicht anders?

Ich gehe einfach die Varianten durch, die ich bisher zu Gesicht bekommen habe:

• “Wir müssen die Passwörter nicht verschlüsseln, so wichtig sind die Daten nicht und da kommen ja eh nur interne Mitarbeiter dran.”

Na dann lasst die Passwortabfrage ganz weg. Wenn der Benutzer genötigt wird ein Passwort einzugeben, wird er mit großer Wahrscheinlichkeit ein Passwort verwenden, dass er auch wo anders verwendet. Und er wird es im Zweifelsfall nicht witzig finden, wenn der DBA das im Klartext in der Datenbank vor findet.

• Base64 Encoding, ROT13

Man denkt es ist ein Scherz, aber ist es aber leider nicht. Beides sind keine Verschlüsselungsverfahren, bzw. können von einem intelligenten Grundschüler mit Papier und Bleistift “entschlüsselt” werden.

• Echte Verschlüsselungsverfahren (DES, AES …)

Schon nicht schlecht. Aber haben diese Verfahren haben einen Nachteil: Man kann das Passwort wieder entschlüsseln. Das ist aber gar nicht notwendig, da es reicht beim Login, das eingegebene Passwort auch zu verschlüsseln und das Ergebnis mit dem gespeichertem verschlüsseltem Passwort zu vergleichen. Die Möglichkeit das Passwort wieder zu entschlüsseln stellt nur ein unnötiges Sicherheitsrisiko dar. Verfahren die nicht umkehrbar sind heißen Hash oder Digest.

• MD5

MD5 ist ein solcher Digest. Aber er hat mehrere Probleme. Erstens gilt er seit geraumer Zeit nicht mehr als sonderlich sicher, auch nicht für den Bereich für den er prinzipiell geeignet und gedacht ist, die Signatur von Dokumenten. Zweitens und das ist das Entscheidende: Er ist schnell. Das ist gut, für Server die Dokumente mit Hilfe von MD5 verarbeiten wollen, und es ist gut, für den Angreifer, der eine Liste von verschlüsselten Passworten per Brute Force angreifen will.

Was wir brauchen ist ein langsamer Algorithmus. Der einen solche Brute Force Angriff unmöglich macht. Um einen Algorithmus langsam zu machen gibt es ein einfaches Mittel: Man wendet ihn sehr oft hintereinander an. Es bleibt aber immer noch ein Problem: Sogenannte Rainbowtables. Der Angreifer berechnet einfach für alle möglichen Passwörter bis zu einer gewissen Maximallänge den entsprechenden Hashwert und speichert das Ergebnis in einer Tabelle. Um ein bestimmtes Passwort zu ermitteln muss er nur den Hashwert in der Tabelle nachschlagen. Um dies zu verhindern, muss das Passwort lang genug sein. Um dies sicherzustellen wird es vom Algorithmus zunächst umeine beachtliche Anzahl zusätzliche Zeichen verlängert, bevor es gehasht wird, dies nennt man “salzen”. Das Salz wir mit abgespeichert, da sein Wert an sich irrelevant ist und nur dazu dient, dass keine Standard Rainbowtables verwendet werden können, sondern dass jeder Angriffsversuch jedes Passwort einzeln angreifen muss.

Dies haben andere natürlich auch schon wesentlich genauer und auf englisch beschrieben.

Mann kann nun anfangen dies alles selbst zu implementieren. Das sollte nicht so schwierig sein, aber man kann auch einfach einen fertig implementierten Algorithmus nehmen.

Zu guter letzt noch eine Warnung: Ich bin kein Kryptologe oder dergleichen. Ich habe nur ein wenig Internetrecherche betrieben als ich den letzten Log On Dialog gebaut habe. Wenn ihr etwas baut, was wirklich sicherheitskritisch ist, konsultiert jemanden, der sich damit auskennt.