Upsource: New Repository Browsing and Code Review Tool by JetBrains

JetBrains, the company behind the popular IntelliJ IDEA, recently has released a new productivity tool into the wild. JetBrains Upsource is a browser-based repository browsing and code review tool. Freshly released in version 1.0, it boasts a number of very interesting and useful features already now. In this article, I’d like to give you a short overview of the goodness you’ll find in this tool.

Continue reading

Posted in Agile Methods and development, Did you know? | Tagged , , , | 2 Comments

Ist ATScript die Zukunft von JavaScript?

Seit geraumer Zeit versucht Google die Script Sprache JavaScript voran zu bringen. Dabei ist die neuste Errungenschaft von Google nach Dart, die Programmiersprache ATScript. Um ATScript als ECMAScript Standard zu forcieren, wird Angular JS 2.0 in ATScript geschrieben. ATScript stellt nicht nur ein typisierte Superset von ECMAScript 5 und der bald erscheinenden ECMAScript Version 6 dar, sondern ist auch ein Superset von TypeScript (Microsoft’s JavaScript basierte Programmiersprache).

Nach der Meinung der ATScript Entwickler, soll ATScript nicht als eine eigene Sprache angesehen werden, sondern als eine Erweiterung von JavaScript betrachtet werden. Dabei stellt uns ATScript TypisierungField AnnotationsMetadata Annotations und Type Introspection mit Annotations Unterstützung als Erweiterung bereit. Um diese Eigenschaften reibungslos in JavaScript zu verwenden, wird der ATScript Code in JavaScript Code kompiliert. Der kompilierte Code ist syntaktisch nach dem ECMAScript 5/6 Standard aufgebaut.

Typisierung für Variablen, Parameter und für Methoden gibt es schon in TypeScript, folglich erfindet ATScript in diesem Bereich nichts neues. Aus diesem Grund ist die Type Annotations Syntax von ATScript vergleichbar mit der Type Annotation Syntax von TypeScript. Der ATScript Code kann durch den traceur compiler auf JavaScript und auf der Dart Plattform zum Laufen gebracht werden.

Typisierungs Beispiel in ATScript:

 class MyClass {
        methodA(name : string) : int {
            var length : int = name.length;
            return length;
        }
    }

Der kompilierte Code in JavaScript (ECMAScript 6)

 import * as rtts from 'rtts';
    class MyClass {
        methodA(name) {
            rtts.types(name, rtts.string);
            var length = tts.type(name.length, rtts.int);
            return rtts.returnType(length, rtts.int);
        }
    }

Durch diese Eigenschaft, kann man den Code schon zur Laufzeit auf Typsicherheit überprüfen.
Eine zusätzliche Erweiterung in ATScript sind Meta-data annotations. Diese Eigenschaft wird in anderen Programmiersprachen schon Jahre lang erfolgreich praktiziert. Wie zum Beispiel in Java (durch “annotations”) oder in Python (durch “decorators”) nur in JavaScript sucht man diese Eigenschaft vergeblich. Diese Lücke will nun ATScript in JavaScript schließen.

Meta-data annotations Beispiel in ATScript:

 
class Inject {}

class Component {
  selector:string;
  constructor({selector:string}) {
    this.selector = selector;
  }
}

class Server {}

@Component({selector: 'foo'})
class MyComponent {
  @Inject()
  constructor(server:Server) {}
}

Der kompilierte Code in JavaScript (ECMAScript 6)

import * as rtts from 'rtts';

class Inject {}

class Component {
  selector;
  constructor({selector}) {
    this.selector = selector;
  }
}

class Server {}

class MyComponent {
  constructor(server) {}
}

MyComponent.parameters = [{is:Server}];
MyComponent.annotate = [
  new Component({selector: 'foo'}),
  new Inject()
];

Bei genauer Betrachtung von ATScript kommt man zum Ergebnis, dass ATScript gute durchdachte Lösungsansätze bietet, wie sich JavaScript in der Zukunft weiter entwickeln kann. Ob JavaScript diesen Weg ein schlägt, hängt von zwei Faktoren ab: Ein Faktor ist der Erfolg von Angular.js 2.0 (Release 2015) und der andere Faktor ist, wie sich allgemein die Softwareentwicklung ausrichtet. Aber durch das Aufbauen auf den Vorarbeiten von TypScript, hat ATScript aktuell den richtigen Weg eingeschlagen.

Posted in Web as a Platform | Tagged , , , , , | Leave a comment

Customizing GWT’s browser detection

In a recent project, we experienced the phenomenon that the GWT application was broken when started in Internet Explorer 11 embedded in a specific rich client application. It turned out that the user agent string sent by the browser was set to that of IE 7 while the rendering engine ran in IE 11 mode. As GWT detects browsers based on their user agent string, the IE6/IE7 permutation was chosen which resulted in a completely broken and unusable rendering of the application, and multiple JavaScript exceptions were thrown.

As the mentioned rich client could not be changed by us, we had to make GWT choose the right permutation. The solution for this was to overwrite the browser detection code bundled with GWT. The post shows how …

Continue reading

Posted in Java Web Frameworks | Tagged , , | Leave a comment

JSR – 310: Die Java 8 Date API auf dem Performance-Prüfstand

Eine der wichtigsten Neuerungen in Java 8 ist neben der Verwendung von Lambda-Ausdrücken die neue Date/Time API. Bisher kam häufig die Joda-Library bei Applikationen mit hohen Anforderungen an die Date/Time-Berechnung zum Einsatz. Die durch JSR-310 in Java 8 neu aufgenommene API soll diese Lücke nun im Standard JDK füllen. Die maßgeblichste Änderung neben der erneuerten API stellt die interne Datenrepräsentation dar. Die neuen Klassen folgen hierbei dem human time concept. Das bedeutet, dass die interne Repräsentation mit einzelnen Darstellungen für Tag, Monat, Jahr etc. implementiert wurde. Dies steht im Gegensatz zu dem bisherig verwendeten machine time concept (Darstellung über einen long-Wert) der Klassen des java.util Packages.

Was dies im Hinblick auf Performance bedeutet, wollen wir uns in einem kurzen ersten Test anschauen. Continue reading

Posted in Java Basics | Tagged , , , , | Leave a comment

GWT 2.7.0 ist da!

Die Liste mit den Neuerungen ist beachtlich, hier die kurze Übersicht:

  • neues SuperDevMode + inkrementelles Kompilieren
  • CSS3 und Closure Stylesheets
  • JS Interop annotations
  • Final Felder in GWT RPC
  • viele Fehlerbehebungen + Performanceverbesserungen

Endlich ist es raus, das 2.7er Release. Gerade in den letzten Wochen wurde das Bild rund um den neuen SuperDevMode (SDM) deutlicher, die Erleichterung in der Entwicklergemeinde fast spürbar. Der neue SDM funktioniert sehr gut, ist schnell und hat jetzt eine ordentliche Integration in die IDE.

Mit GWT Version 2.7 bekommen wir endlich ganz offiziell Unterstützung für CSS3/ closure stylesheets. Zwar muss es explizit aktiviert werden (ist nicht default) und wird einen gewissen Migrationsaufwand mit sich bringen – lohnen wird es sich allemal. Endlich können wir CSS3 in CSSResourcen einsetzen! Sogar CSS-Animationen!

Bisher musste man zur Integration von JavaScript in GWT zu JSNI (JavaScript Native Interface) greifen. Hierbei war es nötig in speziellen Kommentaren JavaScript Schnipsel in den Java Quellcode einzubetten.
Mit JS Interop ist es nun möglich, diesen Glue Code vom GWT Compiler aus Annotationen und Interfaces generieren zu lassen… Allerdings wird diese Funktion ganz offiziell als “experimentell” eingestuft.

Die neue Version kommt gerade einmal 10 Monate nach dem letzten Release (2.6) und bringt beeindruckende Neuerungen. Das erste Snapshot für 2.8.0 zeigt, dass das Team keine Pause einlegt, und die Java 8 Unterstützung nun ernsthaft angegangen wird.

Sowohl für Eclipse als auch für IntelliJ gab es bereits passende Updates für das GWT Tooling. Allerdings hat IntelliJ in Bezug auf die GWT Unterstützung immer noch die Nase deutlich vorn. Da macht sogar GWT mit maven Spass, kaum zu glauben.

Im Januar findet die zweite GWT Konferenz statt. Besonders interessant dürften die Vorträge rund um Webcomponents und auch das “wie” rund um das neue Gmail aka Inbox von Google sein.

Posted in Java Web Frameworks | Tagged , , , , , | 1 Comment

Handling JavaScript Dependencies with Gradle

In the Java world and with build tools like Maven or Gradle, you are used to declarative dependency management. Simply declare which libraries and versions you need, and let the build tool download and package these libs for you. The artifacts are typically stored in an artifact repository like Archiva, Artifactory or Nexus.
What is quite common for JAR dependencies seems to be quite uncommon for JavaScript dependencies. In my experience, a lot of Java projects that have a JavaScript front end still store the JavaScript libraries in a VCS.

I recently noticed (thanks to Steffen Schäfer) that Gradle, my current build tool of choice, is capable of handling JavaScript dependencies, too.
This is how it works:

Upload your required JavaScript library with a POM to your artifact repository.

  • inside the POM, use packaging js
  • to make it a valid POM, add the javascript-maven-plugin as an extension

Here is a full sample of such a POM:

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

  <modelVersion>4.0.0</modelVersion>

  <groupId>de.oio</groupId>
  <artifactId>mylib</artifactId>
  <version>1.0.0</version>
  <packaging>js</packaging>

  <name>Some name</name>
  <description>A really nice description</description>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <extensions>
      <extension>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>javascript-maven-plugin</artifactId>
        <version>2.0.0-alpha-1</version>
      </extension>
    </extensions>
  </build>

</project>

In your Gradle build script (build.gradle), add a new configuration js and declare your dependencies for this configuration.

configurations {
    js
}

dependencies {
    js 'de.oio:mylib:1.0.0'
}

Using configurations.js, you can access the JavaScript files as a fileset. A typical scenario is to include these JavaScript files into a WAR archive.
You can do this as follows.

apply plugin: 'war'

war {
    into('js'){
        from configurations.js
    }
}

Transitive dependencies are also supported. If mylib has a dependency to anotherlib, simply declare it in the POM of mylib:

<dependencies>
  <dependency>
    <groupId>de.oio</groupId>
    <artifactId>anotherlib</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

You could also define a POM that has no corresponding artifact itself, but it includes a lot of dependencies. A use case for this could be a POM that simply includes all the JavaScript libraries that you use in all of your projects. To do so, simply create a POM with packaging pom and a dependencies block.

Posted in Build, config and deploy, Web as a Platform | Tagged , , , , , | Leave a comment

TCP and HTTP for web developers

When developing web applications, you can do some mistakes related to basic peculiarities of TCP and HTTP. The post explains some of the pain points and shows approaches to avoid such problems.

Continue reading

Posted in Web as a Platform | Tagged , , , , , | Leave a comment