In our example we’ll want to unmarshall a Cookie object from it’s string representation, a pretty typical task. In order to do that (for example with JAX-B), we’ll need a Class object we can pass to the deserializer – so it can work all the field mappings etc. Obviously the second example in Java just isn’t enough – we need the Class object, and just using <Cookie> isn’t enough to retain this type information. Scala obviously suffers from the exact same problem as it’s a JVM issue (type erasure, grrr!).

But even so, the above Scala code will work fine if we do some tricks in the method definition. We’ll resort to using:

• a second (implicit) argument list
• Manifest[T]

That’s a bunch of scary looking terms, but it’s actually quite easy. Let’s take a look at the definition of the Scala version of unmarshall.

First, let’s analyze the signature of this method. Obviously it’s parameterized method, thus we need the [T] in front of it. Next is the argument list, with just one argument – str, the string representation we want to unmarshall – easy. Now for the more fun part – the second argument list. Yeah, you can have multiple argument lists in Scala. “Why?”, you ask? For example in our case the second list is implicit – this means that the compiler will figure out and try to fill in these arguments with matching types it finds in scope. In the case of supplying a Manifest[T] it’s fairly easy – it will just create the manifest based on the T type, during runtime at the call site of the method, and pass it into unmarshall.

A Manifest[T] can be thought of like a “better” a Class[_] which contains full type information – so for example we wouldn’t loose the information contained in a List<Cookie> like we would with plain Java (where we would have to hack around this JVM issue via a TypeToken). Anyway, thanks to the Manifest we’re able to get the Class we need to get our unmarshalling done! Manifest.erasure contains the type we need. If you want to read more about Manifest, the ScalaDoc about it does a really nice job explaining how to use it.

— EXTRA for Scala Geeks —

You may have noticed the word “implicitly” appearing from time to time in Scala discussions. It’s a shorthand for accessing shorthand passed implicits. Let me explain this on our example – so instead of the code above we could do the following (which does the same thing):

So instead of creating a second argument list we say that the Type parameter T will be used as a Manifest. And then we can access it via the implicitly magic method. This approach has been made possible since Scala 2.8, due to how often the above pattern was discovered in real life code.
Anyway – it’s up to you which version you like the most.

Now, we all remember how painful it it to write good equals and hashCode methods, yet we really should implement them to make our collections work the way they should work (HashAnythings, Lists, Sets). So we sometimes use Apache Commons to implement these, or just leave the coding to IntelliJ or NetBeans. The problem with the second, code generating, solution is that it’s a hell of a mess. Don’t believe me…? Just a quick reminder then…

Now that we’ve remembered how painful it looks, let’s dive into JDK7: The full code would look like this (this time equals is also accepting subclasses of Test, the above example didn’t):

Note the Objects.hash() method, wich is really a lifesaver and also the Objects.equals() method which makes our code NullPointerException safe, which the previous version had to tackle by using ?:… And it read’s much nicer, Of course, you could skip the result variable, but I decided to do it like this for the sake of easy reading.

And here is it’s test:

Now that was nice wasn’t it? :-) Objects probably isn’t “the” killer feature that JDK7 has, but it’s a really nice addition, so let’s get to using it :-) The other utility methods in this class are:

• static <T> int compare(T a, T b, Comparator < ? super T> c)
  Returns 0 if the arguments are identical and c.compare(a, b) otherwise.
• static boolean deepEquals(Object a, Object b)
  Returns true if the arguments are deeply equal to each other and false otherwise.
• static boolean equals(Object a, Object b)
  Returns true if the arguments are equal to each other and false otherwise.
• static int hash(Object… values)
  Generates a hash code for a sequence of input values.
• static int hashCode(Object o)
  Returns the hash code of a non-null argument and 0 for a null argument.
• static <T> T requireNonNull(T obj)
  Checks that the specified object reference is not null.
• static <T> T requireNonNull(T obj, String message)
  Checks that the specified object reference is not null and throws a customized NullPointerException if it is.
• static String toString(Object o)
  Returns the result of calling toString for a non-null argument and “null” for a null argument.
• static String toString(Object o, String nullDefault)
  Returns the result of calling toString on the first argument if the first argument is not null and returns the second argument otherwise.

Hooray for small litle improvements :-) This class officialy get’s Duke’s thumbs up image:

The code comes from http://arnorehn.de/cgi-bin/weblog_basic/index.php?p=34 so big kudos too him :-)

Cheers and happy hacking!

PS: I’m waiting for my T-shirt and stickers (for training participants) to arrive from github. I’d love they make it in time for SFI but I’m not sure if it’s even possible hmmm…

UPDATE
The plugin is now available from Sonatype Nexus!

    
        sonatype-releases
        Sonatype Releases
        https://oss.sonatype.org/content/repositories/releases/
    

END OF UPDATE

Now I’ll be a bit lazy and just paste the README I’ve prepared for maven-git-commit-id-plugin on github.

  git clone git://github.com/ktoso/maven-git-commit-id-plugin.git maven-git-commit-id-plugin
  cd maven-git-commit-id-plugin
  mvn install

   <?xml version="1.0" encoding="UTF-8"?>
   <project xmlns="http://maven.apache.org/POM/4.0.0"
            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <modelVersion>4.0.0</modelVersion>

       <groupId>pl.project13.maven</groupId>
       <artifactId>my-git-plugin-sample-app</artifactId>
       <packaging>war</packaging>
       <version>0.1</version>
       <name>my-git-plugin-sample-app</name>
       <url>http://www.blog.project13.pl</url>

       <parent/>

       <dependencies />

       <build>
           <!-- GIT COMMIT ID PLUGIN CONFIGURATION -->
           <resources>
               <resource>
                   <directory>src/main/resources</directory>
                   <filtering>true</filtering>
                   <includes>
                       <include>**/*.properties</include>
                       <include>**/*.xml</include>
                   </includes>
               </resource>
           </resources>

           <plugins>
               <plugin>
                   <groupId>pl.project13.maven</groupId>
                   <artifactId>git-commit-id-plugin</artifactId>
                   <version>1.0-SNAPSHOT</version>
                   <executions>
                       <execution>
                           <goals>
                               <goal>revision</goal>
                           </goals>
                       </execution>
                   </executions>
                   <configuration>
                       <prefix>git</prefix> <!-- that's the default value -->
                       <dateFormat>dd.MM.yyyy '@' HH:mm:ss z</dateFormat> <!-- that's the default value -->
                       <verbose>true</verbose> <!-- false is default for this -->
                       <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory> <!-- required, you have to specify this path -->
                   </configuration>
               </plugin>
               <!-- END OF GIT COMMIT ID PLUGIN CONFIGURATION -->

               <!-- other plugins -->
           </plugins>
       </build>
   </project>

 git.branch=${git.branch}

 git.build.user.name=${git.build.user.name}
 git.build.user.email=${git.build.user.email}
 git.build.time=${git.build.time}

 git.commit.id=${git.commit.id}
 git.commit.user.name=${git.commit.user.name}
 git.commit.user.email=${git.commit.user.email}
 git.commit.message.full=${git.commit.message.full}
 git.commit.message.short=${git.commit.message.short}
 git.commit.time=${git.commit.time}

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean name="gitRepositoryInformation">
        <property name="branch" value="${git.branch}"/>
        <property name="commitId" value="${git.commit.id}"/>
        <property name="commitTime" value="${git.commit.time}"/>
        <property name="buildUserName" value="${git.build.user.name}"/>
        <property name="buildUserEmail" value="${git.build.user.email}"/>
        <property name="commitMessageFull" value="${git.commit.message.full}"/>
        <property name="commitMessageShort" value="${git.commit.message.short}"/>
        <property name="commitUserName" value="${git.commit.user.name}"/>
        <property name="commitUserEmail" value="${git.commit.user.email}"/>
    </bean>

</beans>

package pl.project13.maven.example.git;

import org.codehaus.jackson.annotate.JsonWriteNullProperties;

/**
 * A spring controlled bean that will be injected
 * with properties about the repository state at build time.
 * This information is supplied by my plugin - <b>pl.project13.maven.git-commit-id-plugin</b>
 *
 * @author Konrad Malawski
 */
@JsonWriteNullProperties(true)
public class GitRepositoryState {
  String branch;                  // =${git.branch}
  String commitId;                // =${git.commit.id}
  String buildUserName;           // =${git.build.user.name}
  String buildUserEmail;          // =${git.build.user.email}
  String buildTime;               // =${git.build.time}
  String commitUserName;          // =${git.commit.user.name}
  String commitUserEmail;         // =${git.commit.user.email}
  String commitMessageFull;       // =${git.commit.message.full}
  String commitMessageShort;      // =${git.commit.message.short}
  String commitTime;              // =${git.commit.time}

  public GitRepositoryState() {
  }

  /* Generate setters and getters here */
}

<context:property-placeholder location="classpath:*.properties" />
<import resource="classpath:/git-bean.xml"/>

 @Controller
 @RequestMapping("/git")
 public class GitService extends BaseWebService {

     @Autowired
     GitRepositoryState gitRepoState;

     @RequestMapping("/status")
     public ModelAndView checkGitRevision() throws WebServiceAuthenticationException {
       ServerResponse<GitRepositoryState> response = new ServerResponse<GitRepositoryState>(gitRepoState);
       return createMAV(response);
     }
 }

 {
     "branch" : "testing-maven-git-plugin",
     "commitTime" : "06.01.1970 @ 16:16:26 CET",
     "commitId" : "787e39f61f99110e74deed68ab9093088d64b969",
     "commitUserName" : "Konrad Malawski",
     "commitUserEmail" : "konrad.malawski@java.pl",
     "commitMessageFull" : "releasing my fun plugin :-)
                            + fixed some typos
                            + cleaned up directory structure
                            + added license etc",
     "commitMessageShort" : "releasing my fun plugin :-)",
     "buildTime" : "06.01.1970 @ 16:17:53 CET",
     "buildUserName" : "Konrad Malawski",
     "buildUserEmail" : "konrad.malawski@java.pl"
 }

Dzisiejszy wpis będzie o znanej i generalnie dość znanej i mającej wiele zalet metodyce Design By Contract. Temat “wypłynął” ponownie dla wielu javovców tym razem dzięki wydaniu biblioteki  CoFoJa (o którym właśnie będzie ten post) przez dwóch pracowników Google przy ścisłej współpracy z autorem pierwowzoru tego projektu. Dlaczego jednak nietypowy tytuł posta – “trzeźwe spojrzenie”? Ponieważ w odróżnieniu od niektórych nie oceniam technologii na podstawie “wow factor” a realnej używalności. Gotowi mini review tego toola? No to lecimy… :-)

Contracts For Java

Na początek warto rzucić okiem na googlowy blog gdzie ogłoszono premierę tego narzędzia oraz oczywiście samą stronę domową projektu CoFoJa. Oczywiście na samym przekierowaniu nie poprzestanę więc zaczniemy od mini definicji od strony użytkownika metodyki design by contract. Jak możemy przeczytać chociażby w pragmatycznym programiście metodyka ta ma dość spory potencjał i ciekawe możliwości – generalnie chodzi o określanie “kontraktów” na naszych metodach. Zakładanie kontraktów ma pewną wyższość nad pisanie testów jednostkowych ponieważ możemy kontrakt założyć na interfejsie a wszystkie implementujące go klasy będą z nim związane

Kontrakt może na przykład zapewnić:

• wykonanie danej metody tylko i wyłącznie wtedy gdy przekazane jej argumenty spełniają pewne kryteria (w kontekście CoFoJa byłoby to @Requires)
• zagwarantowanie spełnienia pewnych warunków po opuszczeniu metody (w kontekście CoFoJa byłoby to @Ensures ewentualnie @ThrowEnsures jeśli chcemy mieć kontrakt na rzucenie wyjątku)
• zagwarantowanie ogólnych warunków na konkretnej np. klasie (@Invariant)

Ok, skoro znamy podstawowe building blocks (zaczerpnięte skądżeby inąd niż z Eiffla oczywiście) zobaczmy jakieś przykładowe poadnotowane nimi API:

A teraz praktycznie

Najlepiej jest chwilkę się w niego wgryźć, powinien być stosunkowo zrozumiały. Nie chcemy nigdy mieć ujemnej ilości bananów – spowodowałoby to złamanie kontraktu. Podobne przykładowe kontrakty wejściowe/wyjściowe widzimy na metodach oraz jeden mały tip: metoda old() jest dostarczana automagicznie i oznacza “starą wartość tego wywołania” czyli przed wykonaniem metody na którą zakładamy ten kontrakt. Poza tym mamy tutaj do czynienia w sumie z zwyczajnym kodem Java który niestety jest wewnątrz stringa… Świadomy programista zapewne już ma zapaloną lampkę alarmową, że to będzie nie refaktorowalne i bez sensu… Na pocieszenie dodam iż kod Java zawarty w tych stringach faktycznie jest “kompilowany”i jak coś popsujemy składniowo, kontrakty się nie skompilują i dostaniemy normalne informacje jakby to się nam nie kompilował normalny “nasz kod”. Co do wygody refaktoringu… Na szczęscie korzystam z porządnego IDE (IntelliJ IDEA) i takie “problemy” mnie nie dotyczą ;-). Wybrałem inject języka Groovy do tych stringów aby parser składniowy nie dziwił się pojawienia się metody old() “z nikąd”: Problem z “nie podpowiadaniem metod” jak i “nie da się refaktorować” jak widać został od razu wyeliminowany :-) Hooray for JetBrains. Poszukajmy jednak kolejnego problemu z tym API… Tak jest, @ThrowEnsures jest trochę brzydki a nie koniecznie musi być cały w stringu. Jak działa obecnie? Przekazujemy mu listę stringów gdzie parami występują “wyjątek” + “warunek kiedy ma zostać rzucony”. Chętniej zobaczył bym to w formie podobnej do poniższej (tylko szybki szkic taki), a wy?

Ok czas na uruchomienie kodu z “włączonymi kontraktami”… I… niestety nie okazało się to takie trywialne na obecnym etapie projektu. Niestety trzeba sobie ręcznie poustawiać processowanie adnotacji (norma, tutaj się niewiele zmieni) jednak trochę problemów nastarcza mi obecnie widoczność klas/pól dla CoFoJa w intellij. Classpath (dla procesora) zdaje się być ustawiony poprawny oraz jego klasa jak i inne opcje też jednak nie dochodzi do poprawnego przeparsowania wszystkich reguł. No cóż, może jutro się uda – tymczasem odsyłam do poradnika dla użytkowników Eclipse gdzie to członek społeczności sprawnie poradził sobie z tym problemem :-)

Trzeźwe spojrzenie: “Czy obecnie warto?”

Pozostaje pytanie… Czy warto się zainteresować CoFoJa jak i samym DBC? Pytanie jest chyba równie ogólne jak “czy warto meta-programować?” także wprost odpowiedzi nie udzielę. Miejmy jednak na uwadze że jak na razie używanie CoFoJa nie jest zbyt wygodne a adnotacje można by jeszcze trochę poszlifować. Trzeba by jeszcze rzucić okiem jak stoimy z integracją tego z Maven – aby normalnie testując bądź klikając sobie po projekcie te kontrakty mogły się przydawać. Sama idea jest ciekawa i jakby integracja z narzędziami była wygodniejsza – a może od razu pluginy do IDE – można by się nad tym porządniej zastanawiać. Jak na razie projekcik odkładamy ten projekt spokojnie na półkę “worth watching” i liczymy na rychłe wydanie 2.0. :-)

PS: Jeżeli interesują Cię takie jak i inne ciekawe metodyki i sposoby tworzenia pięknego, czystego kodu, zapraszam serdecznie na co 2 tygodniowe spotkania SCKRK gdzie obecnie dyskutujemy w formie “reading club” nad Domain Driven Design :-)

[ktoso@protos somerepo-v2]$ git remote \
                            add origin \
                            git@github.com:ktoso/somerepo.git
[ktoso@protos somerepo-v2]$ git pull
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 9 (delta 2), reused 9 (delta 2)
Unpacking objects: 100% (9/9), done.
From github.com:ktoso/somerepo
0b59dd3..87b0c22  master     -> origin/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').

See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:

[branch "master"]
remote = <nickname>
merge = <remote-ref>

[remote "<nickname>"]
url = <url>
fetch = <refspec>

See git-config(1) for details.

Well, git has actually already told us what we might want to do. But can’t this be done easier? Of course~!

[ktoso@protos somerepo-v2]$ git branch --set-upstream \
                                         master \
                                         origin/master
Branch master set up to track remote branch master from origin.
[ktoso@protos somerepo-v2]$ git pull
Updating 0b59dd3..87b0c22
Fast-forward
.......

And now we can easily pull and push changes again, without the hassle of specifying the obvious each time we’d want to get/share some changes. :-)

Anyway, this post will illustrate, very painfully, how much slower += is… Let’s do some (idiotic, yet good enough for this case) tests. First, the version everybody who _knows_ java uses:

Let’s run it…

[ktoso@homunculus ~]$ time `java BuilderTest`

real    0m0.209s
user    0m0.137s
sys     0m0.039s

Hmm… Quite all right I guess… And now back to the monstrous version some of my colleges keep writing:

compile and run…

[ktoso@homunculus ~]$ time `java StringTest`

real    2m14.694s
user    2m10.379s
sys     0m2.254s

I even managed to make me some coffee before it finished… Why is that? For any real Java programmer its obvious, but for some students it’s not… String is immutable. Every “string modification” is creating a new string, with all the fuss with object creation/allocation, it really takes some time. It’s a “feature” of the language, so how does it fight this kind of problem? Yup, the StringBuilder is mutable, thus he is really supreme if it comes down to modifying strings.

So, next time before you come to me panicking about java/speed or some other nonsense, please RTFM first ;-)

Update: Let’s look into the generated bytecode!

Yeah, why not? Since we’re talking about an really important feature here, let’s get more into it… You can use javap to display the bytecode from an class file. I’ve checked both examples above with it and the main difference are, of course, the lines used for appending those strings… First the StringBuilder version:

Nothing weird here, right? We expected StringBuilder to be used and simply the append method to be called, quite “normal”. By the way, it’s quite interesting to see how actually java does things inside :-) Ok, now for the String += version:

Oh! First thing you’d notice, it’s now 41 lines and not 28 as it was when we used StringBuilder directly… Let’s go on and examine the rest… What do we have here… StringBuilder?! That’s a little less expected, as I thought that the compiler wasn’t able to guess that we need a StringBuilder in such an situation. Well, it guessed right. Even though we use += StringBuilder’s append is being called… And then it’s being converted to a String… And each time in the loop there’s a new StringBuilder (line 16).

To summarize: Even though the javac compiler does use the StringBuilder if it thinks that’s a good idea, id does it quite stupid. And in the end, we still end up with super slow code! Bottom line is, that you should “by hand” use the StringBuilder in your code. Note that even thought you might use + in your code, javac will still make this StringBuilder code :-) Sometimes better, sometimes worse – as shown in the above examples.

Hope this post was interesting for even the more advanced users out there – that’s what for the second part was for :-) If you have any comments, feel free to post them – it really makes me happy to see people commenting my stuff ;-)

PS: Hmmm… I wonder how GStrings would do in such an dumb test… Guess I’ll have to check someday.

memused

Sample output:
VPS memory usage:
Used: 296 MB
Total: 256 MB
Burstable to: 512 MB

memfree

Sample output:
VPS Memory:
Total: 256 mb Used: 302 mb (100%) Free: -46 mb (0%)

memheld

Sample output:
VPS Memory Usage
Current Held: 160.832MB
Max Held: 294.605MB
Barrier: 256MB

memps

Sample output:
ps axo pmem,pcpu,comm | sort
0.0 0.0 script
0.0 0.0 script
0.1 0.0 init
#...
2.2 0.0 httpd
4.0 0.0 mysqld
7.3 0.0 httpd
8.0 0.0 httpd
%MEM %CPU COMMAND

memprivmpages

Sample output:
privvmpages usage: 296 MB (57% of 512)
For those wondering, yes I do have memory usage above “100%” in the output of some of these scripts, and it’s partially true. A VPS does usually have some guaranteed memory, and some “burstable” – so you can use more than just the guaranteed memory for some period of time. On the mashine I ran this I have 256 guaranteed and a “total” of 512MB – including the burstable memory.

If you like any of these, feel free to use them. I use them by creating a scripts directory and adding it to the PATH, so I can simply invoke them from anywhere.

PS: For more detailed memory usage information (as graphs etc), I’m using Munin and really recommend it. The graphs it draws are really nice, and it doesn’t inflict heavy load on the server, and it can monitor remote hosts if needed!

LIBGL_ALWAYS_SOFTWARE=1 blender

This will launch blender and render it’s interface in software mode – runs perfectly, and no slowdowns could be detected by me so far :-)