Das Überall-Java: Write once run anywhere mit DukeScript

Anton Epple

© Shutterstock.com / Valeri Potapova

Java löst sein WORA (Write Once, Run Everywhere)-Versprechen schon lange nicht mehr ein. DukeScript will das ändern, indem es eine saubere Trennung von View und Logik bei Cross-Plattform-Anwendungen ermöglicht. Anhand einer einfach strukturierten Anwendung werden die Grundlagen von DukeScript vorgestellt.

Vor einigen Jahren war es möglich, mit Swing eine Anwendung zu entwickeln, die auf allen relevanten Betriebssystemplattformen lief. Dann kamen Smartphones, Tablets und Embedded-Computer und plötzlich ging nichts mehr. Im Enterprise-Bereich dominierte zwar für eine Weile erstmal weiterhin nur der Desktop, inzwischen wird jedoch fast bei jedem UI-Projekt die zukünftige Portierung auf mobile Plattformen mit eingeplant. Native Anwendungen für alle Plattformen zu bauen, erfordert aber zusätzliche Skills und ist teuer in Wartung und Entwicklung. Was also tun?

Mit DukeScript gibt es wieder eine Java-basierte Lösung, mit der sich Cross-Plattform-Anwendungen entwickeln lassen. DukeScript setzt dabei auf eine saubere Trennung von View und Logik, die es ermöglicht, das UI-Design an Profis auszulagern, und perfekt testbaren UI-Code zu schreiben.

Das Beste zweier Welten

Die Grundidee von DukeScript ist einfach. Praktisch jede existierende OS-Plattform bietet die Möglichkeit, einfache Java-Programme laufen zu lassen. Auf Android geht das nativ mit der Dalvik Runtime und ART, für iOS gibt es RoboVM und auf vielen weiteren Plattformen läuft OpenJDK oder Oracles Java SE Embedded. Selbst für den Browser gibt es inzwischen eine Reihe von virtuellen Maschinen (TeaVM, Doppio, Bck2Brwsr), die ohne Browser-Plug-in auskommen. Was hier jedoch fehlt, ist eine einheitliche UI-Technologie. Gleichzeitig gibt es auf nahezu allen Plattformen eine moderne HTML-Renderer-Komponente. Kombiniert man beides miteinander, ergibt sich das perfekte Framework.

Dabei können die Vorteile beider Technologien uneingeschränkt genutzt werden. Java hat von allen Programmiersprachen die wohl beste IDE-Unterstützung und ermöglicht es durch statische Typisierung, wartbaren Code zu entwickeln, der einfach refaktoriert werden kann. Anders als JavaScript ist es damit auch für größere Projekte geeignet. Auf der UI-Seite gibt es für HTML und CSS ein riesiges Arsenal an freien und kostenpflichtigen Werkzeugen und Services. Wenn UI und Businesslogik sauber voneinander entkoppelt sind, können wir dieses Arsenal auch uneingeschränkt nutzen. Um das zu zeigen, werden wir jetzt eine To-do-Liste entwickeln und stylen.

Das ViewModel

DukeScript verwendet das Design-Pattern Model View ViewModel (MVVM) zur Trennung von Darstellung und Logik. Die View ist dabei in einer Markup-Sprache definiert und bindet aktive Elemente deklarativ an Properties des ViewModels. Durch diesen Aufbau braucht das ViewModel keinerlei Kenntnis von der View. Die View kann daher ohne Änderung am ViewModel ausgetauscht werden. Die gesamte View-Logik liegt im ViewModel. Als „Model“ betrachtet man bei MVVM den Rest der Anwendung; wie es auszusehen hat, ist nicht näher definiert (Abb. 1).

Abb. 1: Model View ViewModel in DukeScript

Abb. 1: Model View ViewModel in DukeScript

Beginnen wir mit dem ViewModel. Listing 1 zeigt, wie das ViewModel einer Anwendung erzeugt wird. Die Annotation @Model sorgt dafür, dass eine Klasse mit dem Namen Task generiert wird. Setter und Getter für die Properties title und complete werden dabei automatisch mit erzeugt. Das erspart dem Entwickler das Schreiben von einer Menge Code und der Aufbau der ViewModel-Klasse ist kompakt auf einen Blick erkennbar. Die Erzeugung erfolgt automatisch im Hintergrund, sodass die Klasse sofort in der IDE zur Verfügung steht.

Listing 1
@Model(className = "Task", properties = {
  @Property(name = "title", type = String.class),
  @Property(name = "complete", type = boolean.class)
})
public static class TaskModel {}

Für komplexere Aufgaben können wir unser Model schachteln. Listing 2 erzeugt ein TaskListViewModel, das eine Liste von Tasks verwaltet und weitere Properties hat. Mit @Function werden Methoden markiert, die von der View aus aufgerufen werden sollen.

Listing 2
@Model(className = "TaskListViewModel", properties = {
  @Property(name = "input", type = String.class),
  @Property(name = "tasks", type = Task.class, array = true),
  @Property(name = "editing", type = Task.class)
}, targetId = "body")
final class TaskListViewModelDefinition {

  @Function
  public static void editTask(TaskListViewModel list, Task data) {
    list.setEditing(data);
  }

  @Function
  public static void stopEditing(TaskListViewModel list) {
    list.setEditing(null);
  }

  @Function
  @ModelOperation
  public static void deleteTask(TaskListViewModel model, Task data) {
    model.getTasks().remove(data);
  }

  @Function
  @ModelOperation
  public static void addTask(TaskListViewModel model) {
    if (null == model.getInput() || model.getInput().length() == 0) {
      return;
    }
    Task task = new Task(model.getInput(), false);
    model.setInput(""); 
    model.getTasks().add(task);
  }
}

Unit Tests mit DukeScript

Zwei Methoden sind zusätzlich als @ModelOperation gekennzeichnet. Das macht man bei Methoden, die auch von außerhalb der View aus aufgerufen werden, in unserem Beispiel durch einen Unit Test (Listing 3). Der Test zeigt, wie das generierte ViewModel verwendet werden kann. Im ersten Testfall simulieren wir die Eingabe einer neuen Task durch den Benutzer, der zunächst Text eingibt (setInput) und danach die Eingabe bestätigt, zum Beispiel mit einem Button oder der Enter-Taste (addTask). Obwohl es noch keine View gibt, können wir schon die Methoden unseres ViewModels testen. Das zeigt ganz gut die saubere Entkopplung der Komponenten.

Listing 3
public class TodoListTest {

  @Test
  public void testAddTask() {
    TaskListViewModel taskList = new TaskListViewModel();
    Assert.assertEquals(taskList.getTasks().size(), 0);
    taskList.setInput("Buy milk!");
    taskList.addTask();
    Assert.assertEquals(taskList.getTasks().size(), 1);
    Task task = taskList.getTasks().get(0);
    Assert.assertEquals(task.getTitle(), "Buy milk!");
  }

  @Test
  public void testDeleteTask() {
    TaskListViewModel taskList = new TaskListViewModel();
    taskList.getTasks().add(new Task("Buy milk!", false));
    Assert.assertEquals(taskList.getTasks().size(), 1);
    Task task = taskList.getTasks().get(0);
    taskList.deleteTask(task);
    Assert.assertEquals(taskList.getTasks().size(), 0);
  }
}

Serialisierung mit JSON

Wenn man sich die Annotationen ansieht, mit denen die ViewModel-Klassen definiert sind, fällt auf, dass sie fast wie JSON-Messages aussehen. Das ist kein Zufall, denn tatsächlich wird großer Wert auf die einfache Integration mit JSON gelegt. Die toString-Methode einer ViewModel-Klasse gibt einen JSON-String zurück. Ebenso einfach lässt sich aus einem JSON-String wieder ein ViewModel-Objekt erzeugen. Listing 4 illustriert, wie das ViewModel serialisiert und wieder deserialisiert werden kann. Wenn es nur darum geht, eine Kopie des Objekts zu erzeugen, sollte man allerdings stattdessen die clone-Methode wählen. Models.parse ist vor allem dafür gedacht, Nachrichten vom Server oder lokal persistierte Daten zu deserialisieren.

Listing 4
TaskListViewModel copy;
String json = original.toString();
InputStream inputStream = new ByteArrayInputStream( 
  json.getBytes(StandardCharsets.UTF_8));
try {
  copy = Models.parse(BrwsrCtx.findDefault(TaskListViewModel.class),
  TaskListViewModel.class, inputStream);
} catch (IOException ex) {
  Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}

Die View

Bei DukeScript wird standardmäßig HTML für die View verwendet, durch die Trennung von View und ViewModel kann jedoch auch ein anderes Format verwendet werden. Das Projekt dukeScript-javafx demonstriert, wie das geht. Mit diesem Projekt können DukeScript ViewModels ganz einfach auch in JavaFX-Anwendungen verwendet werden. Als Sprache für die Definition von Views wird dabei reguläres FXML verwendet. Auch Controls.js verwendet ein alternatives Format für die Definition der Views, dazu später mehr.

Für unsere Anwendung verwenden wir jedoch normales HTML (Listing 5). Elemente, die vom ViewModel abhängen, bekommen dabei data-bind-Attribute. Damit werden Sie deklarativ an die Properties und Methoden des ViewModel gebunden. Auch foreach-Schleifen und konditionale Statements können so definiert werden.

Meistens genügen die data-bind-Attribute. Manchmal müsste man dafür aber extra ein Element anlegen, das sonst für die View nicht notwendig ist. Für diesen Fall gibt es alternativ spezielle Kommentare. Im Beispiel wird mit <!– ko foreach: tasks –> über die Liste der Tasks iteriert, mit <!– /ko –> die Schleife geschlossen. Mehr zur Binding-Syntax finden Sie in den Kommentaren des Listings und auf der DukeScript-Webseite. Abbildung 2 zeigt den so erzeugten funktionstüchtigen Prototypen. Visuell ist das Ganze eher bescheiden – aber das ändern wir jetzt!

Listing 5
<!DOCTYPE html>
<head>
  <title>TODO</title>
  <meta charset="utf-8">
</head>

<body >
  <ul>
    <!--iteriere über die Liste der Tasks des TaskListViewModel-->
    <!-- ko foreach: tasks --> 
    <li>
      <!--Wenn diese Task nicht gerade editiert wird... -->
      <!-- ko ifnot: $root.editing()===$data -->
      <!—… binde den Zustand der Checkbox an die Task-Property "complete"-->
      <input type="checkbox" name="" data-bind="checked: complete"/>
      <!--Binde den Text der Span an die Task-Property "title"-->
      <span data-bind="text: title"></span>
      <span class="btns">
        <!--Bei Klick rufe die Methode editTask auf-->
        <button  data-bind="click: $root.editTask"  >Ändern</button>
        <!--Bei Klick rufe die Methode deleteTask auf-->
        <button  data-bind="click: $root.deleteTask" >Löschen</button>
      </span>
      <!-- /ko -->
      <!--Wenn diese Task gerade editiert wird, zeige ein Text Input an -->
      <!-- ko if: $root.editing()===$data -->
      <!-- Bei submit (Enter) rufe die Methode stopEditing auf-->
      <form data-bind="submit: $root.stopEditing">
        <!--Binde den Eingabetext an die Property title-->
        <input type="text" data-bind="textInput: title"/>
      </form>
      <!-- /ko -->
    </li>
    <!-- /ko -->
    <li>
      <!-- Bei submit (Enter) rufe die Methode addTask auf-->
      <form data-bind="submit: addTask">
        <!--Binde den Eingabetext bidirektional an die Property "input"-->
        <input type="text" data-bind="textInput: input"/>
      </form>
    </li>
  </ul>

</body>
</html>
Abb. 2: Der funktionsfähige Prototyp

Abb. 2: Der funktionsfähige Prototyp

Das Designer-Developer-Experiment

Auch vor DukeScript sind bereits viele Plattformen mit dem Versprechen angetreten, Design und Entwicklung konsequent zu entkoppeln. Meistens bleibt in der Praxis allerdings von solchen Versprechen nur wenig übrig. Das Design erfordert proprietäre Tools, die einem Designer nur ein müdes Lächeln entlocken können. Ein Beispiel dafür ist JavaFX. Der SceneBuilder ist nicht einmal in der Lage, ein Polygon zu bearbeiten. Inzwischen ist nicht einmal mehr klar, wie die Zukunft des Tools aussieht. Also bleibt die Aufgabe, das Design zu entwickeln, meist an einem Entwickler hängen, der sich die nötigen Fähigkeiten erst einmal aneignen muss und dabei zu allem Überfluss auf unzulängliche Tools angewiesen ist.

Um zu testen, ob das mit DukeScript besser funktioniert, habe ich mir ein kleines Experiment überlegt. Zunächst habe ich mir ein fertiges Design für meine To-do-Liste ausgesucht und gekauft (Abb. 3). Dann habe ich einen Anbieter für die Umwandlung der PSD-Datei nach HTML gesucht (man findet diese Dienste zu Hunderten im Web, wenn man „PSD to HTML“ eingibt). Ich habe mich für RapidxHTML entschieden, weil dieser Dienst günstig ist und trotzdem positive Reviews aufzuweisen hat.

Abb. 3: Das umzusetzende Design

Abb. 3: Das umzusetzende Design

Für ein „richtiges“ Projekt würde ich auf jeden Fall die Zusammenarbeit mit einem Designer vorziehen, da ist die Kommunikation einfach besser. Aber für unser Experiment ist es ein Vorteil, dass die Kommunikation über Kreditkarte und Webformular erfolgte. Denn so ist sichergestellt, dass der Designer nichts von Spezialanforderungen unseres Frameworks weiß.

Über die Webseite des Diensts lädt man die PSD-Datei hoch und gibt per Formular an, was und wie gestylt werden soll. Checkboxen und Scroll Bars kosten zum Beispiel extra, da das Styling hier aufwändiger ist. Deshalb habe ich in unserem Beispiel darauf verzichtet. Unterm Strich ist das Ganze glücklicherweise nicht teuer. Die Konvertierung kostete pro Seite inklusive aller gewählten Extras (Resizing in der Breite, HTML5 mit CSS3 etc.) etwa 170 US-Dollar. Bezahlt wird im Voraus und geliefert wird in der Regel innerhalb von 24 Stunden. Klingt gut, ich war gespannt.

Bereits nach sechs Stunden erreichte mich eine E-Mail mit einem Link auf das Design. Nicht schlecht. Auf den ersten Blick sah das Ergebnis auch ganz gut aus, nur das Resizing in der Breite klappte nicht. Nach einer Reklamation hatte ich zwei Stunden später eine neue Version mit funktionierendem Resizing, Abbildung 4 zeigt das Ergebnis.

Abb. 4: Die Lieferung vom „PSD to HTML“-Dienstleister

Abb. 4: Die Lieferung vom „PSD to HTML“-Dienstleister

Weitere Reklamationen kleiner Ungenauigkeiten wurden dann aber nicht mehr beantwortet. Für ein „richtiges“ Projekt ist also ein Premiumanbieter oder ein Designbüro mit entsprechendem Angebot sicher die bessere Wahl. Listing 6 zeigt den gelieferten HTML-Code.

Listing 6
<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<head>
  <title>TODO</title>
  <meta name="robots" content="index, follow">
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
  <meta name="author" content="RapidxHTML" />
  <link rel="stylesheet" href="css/normalize.css">
  <link rel="stylesheet" href="css/style.css">
</head>

<body>

  <!--[if lt IE 7]>
  <p class="chromeframe">You are using an outdated browser. <a href="http://browsehappy.com/">Upgrade your browser today</a> or <a href="http://www.google.com/chromeframe/?redirect=true">install Google Chrome Frame</a> to better experience this site.</p>
  <![endif]-->

  <!-- box -->
  <div id="box">
    <div class="box-cont">
      <header class="box-header">
        <div class="box-title">My tasks for today</div>
        <div class="box-links"><a href=""><img src="images/btn-cal.png" alt="" /></a><a href=""><img src="images/btn-settings.png" alt="" /></a></div>
      </header>
      <section class="todo">
        <section class="todo-bg">
          <ul class="todo-list">
            <li class="done"><input type="checkbox" name="" class="toggle" checked="checked" /> Design a to-do list <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
            <li><input type="checkbox" name="" class="toggle" /> Design a super task<br />with 2 lines <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
            <li><input type="checkbox" name="" class="toggle" /> fix the dog toy <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
            <li><input type="checkbox" name="" class="toggle" /> buy coffee <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
            <li><input type="checkbox" name="" class="toggle" /> feed the dog <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
            <li><input type="checkbox" name="" class="toggle" /> take a walk with the dog 🙂 <span class="btns"><a href=""><img src="images/icon-edit.png" alt="" /></a><a href=""><img src="images/icon-delete.png" alt="" /></a></span></li>
          </ul>
        </section>
      </section>
    </div>
  </div>
  <!-- / box -->

  <script type="text/javascript" src="js/jquery.js"></script>
  <script type="text/javascript" src="js/modernizr-2.6.2.min.js"></script>

</body>
</html>

Als Nächstes musste ich das UI mit Leben füllen. Die Bindings dafür kennen wir ja schon aus dem Prototypen. Listing 7 zeigt den überarbeiteten Code.

Listing 7
<!DOCTYPE html>
<head>
  <title>TODO</title>
  <meta charset="utf-8">
    <link rel="stylesheet" href="css/normalize.css">
    <link rel="stylesheet" href="css/style.css">
</head>

<body id="body">
  <!-- box -->
  <div id="box">
    <div class="box-cont">
      <header class="box-header">
        <div class="box-title">My tasks for today</div>
        <div class="box-links"><a href=""><img src="images/btn-cal.png" alt="" /></a><a href=""><img src="images/btn-settings.png" alt="" /></a></div>
      </header>
      <section class="todo">
        <section class="todo-bg">
          <ul class="todo-list" >
            <!-- ko foreach: tasks -->    
            <li>
              <!-- ko ifnot: $root.editing()===$data -->
              <input type="checkbox" name="" class="toggle" data-bind="checked: complete"/>
              <span data-bind="text: title">

              </span>
              <span class="btns">
                <img src="images/icon-edit.png" alt="" data-bind="click: $root.editTask"  />
                <img src="images/icon-delete.png" alt="" data-bind="click: $root.deleteTask" />
              </span>

              <!-- /ko -->

              <!-- ko if: $root.editing()===$data -->
              <form data-bind="submit: $root.stopEditing">
                <input type="text" data-bind="textInput: title"/>
              </form>
              <!-- /ko -->
            </li>
            <!-- /ko -->
            <li>
              <form data-bind="submit: addTask">
                <input type="text" data-bind="textInput: input"/>
              </form>
            </li>
          </ul>
        </section>
      </section>
    </div>
  </div>
  <!-- / box -->
</body>
</html>

In Abbildung 5 ist das Ergebnis zu sehen. Das UI sieht tatsächlich aus wie die Designvorgabe und funktioniert auf allen Plattformen. Damit war das Experiment ein voller Erfolg: Das Design konnte komplett ausgelagert werden. Ohne spezielle Anforderungen waren Designer und Konvertierungsdienst in der Lage, brauchbare Assets zu liefern, die mit minimalen Anpassungen in der Anwendung zum Einsatz kommen konnten. Der Entwickler kann sich so voll auf das Implementieren der eigentlichen Funktionen und der Businesslogik konzentrieren. Wer Erfahrungen mit der Entwicklung von Desktopanwendungen hat, der weiß, dass regelmäßig viel zu viel Entwicklungszeit für das Umsetzen des Designs benötigt wird. Mit DukeScript kann man das getrost den Designprofis überlassen, was wertvolle Zeit für die Implementierung der eigentlichen Funktionalität freisetzt.

Abb. 5: Die fertige Anwendung

Abb. 5: Die fertige Anwendung

Wie werden DukeScript-Apps entwickelt?

DukeScript unterstützt derzeit die üblichen Desktopplattformen und zusätzlich iOS, Android und Browser. Die verfügbaren Maven-Archetypen legen für jede unterstützte Plattform ein eigenes Subprojekt an. Je nach Plattform stehen dort unterschiedliche Tasks zur Verfügung, das Projekt zu verpacken und zu testen. Die Subprojekte für Android und iOS bieten zum Beispiel die Möglichkeit, die Anwendung im Gerätesimulator oder auf einem verbundenen Endgerät zu testen; das Webprojekt baut automatisch eine statische Webseite.

Für IoT-Anwendungen steht seit Kurzem auch die Unterstützung für Embedded-Plattformen zur Verfügung. Es gibt also auch nachdem Oracle die Unterstützung für JavaFX auf Embedded-Plattformen eingestellt hat weiterhin die Möglichkeit, hierfür ein professionelles GUI mit Java zu entwickeln. In den meisten Fällen reicht hier auch OpenJDK als JVM aus, sodass auch für kommerzielle Projekte keine kostenpflichtige Java-SE-Embedded-Lizenz nötig ist.

Mithilfe der Maven-Archetypen ist die Entwicklung mit den üblichen Java-IDEs problemlos möglich. Für NetBeans gibt es zusätzlich ein Plug-in mit einer Reihe von Zusatzfeatures, welche die Entwicklung noch komfortabler machen. So gibt es zum Beispiel im HTML-Editor-Code Completion für die data-bind-Direktiven. Mit dem DOM-Inspektor können UI-Elemente der laufenden Anwendung inspiziert werden, Änderungen an HTML und CSS werden automatisch in die laufende Anwendung übernommen. Seit Version 0.8 der Maven-Archetypen ist sogar Hot Swapping implementiert. Auch Änderungen im Java-Code werden automatisch in die laufende Anwendung deployt und können sofort getestet werden (Abb. 6). Selbst JavaScript-Entwickler können neidisch werden, denn anders als bei der JavaScript-Entwicklung bleibt der Zustand der Anwendung dabei erhalten, ganz ohne Reload.

Abb. 6: NetBeans unterstützt Liveinspektion, Debugging und Hot Swapping in DukeScript-Anwendungen

Abb. 6: NetBeans unterstützt Liveinspektion, Debugging und Hot Swapping in DukeScript-Anwendungen

Controls.js for Java – DukeScript ganz ohne HTML

DukeScript hat sich ja auf die Fahnen geschrieben Cross-Plattform-Entwicklung ohne JavaScript zu ermöglichen. Das Frontend wird normalerweise mithilfe von HTML und CSS entwickelt. Diese Entwicklung kann zwar, wie gezeigt, ausgelagert werden, erfordert jedoch immer noch Tests und Anpassungen für die unterschiedlichen Plattformen und das manuelle Editieren der HTML-Dateien. Das Projekt Controls.js for Java macht es jedoch auch möglich, ein UI komplett per Drag and Drop zu entwickeln. Auch hier gibt es Maven-Archetypen und ein Plug-in für NetBeans. Controls.js for Java verfügt über eine eigene Komponentenbibliothek. Die einzelnen Controls können mit Skins gestaltet werden, für eigene Skins gibt es einen freien Skin-Editor. Das ViewModel bleibt dabei gleich, das Binding erfolgt ebenfalls mithilfe des visuellen Editors.

Abb. 7: Rapid Application Development mit DukeScript und Controls.js for Java

Abb. 7: Rapid Application Development mit DukeScript und Controls.js for Java

Fazit

Zum Abschluss die Hammer-und-Nagel-Frage: Ist DukeScript das passende Werkzeug für mein Projekt? Die Vorteile sind offensichtlich: Mit einer gemeinsamen Codebase können Anwendungen für viele Plattformen gebaut werden. Der Workflow ist gut strukturiert, und es stehen hervorragende Tools zur Verfügung. Designaufgaben können ausgelagert werden, so wird der Wartungs- und Entwicklungsaufwand für eine Anwendung stark minimiert.

Dennoch ist DukeScript sicher nicht das richtige Tool für jede Anwendung. Wer Wert auf ein eigenes Branding legt und plattformübergreifend ein einheitliches Design möchte, ist mit DukeScript besser bedient als jemand, der ein möglichst natives Look and Feel der Anwendung erreichen möchte. Ich würde auch nicht versuchen, ein 3-D-Modellierungstool oder andere Anwendungen, die auf optimierte Rendering-Pipeline angewiesen sind, damit zu entwickeln.

Für Businessanwendungen ist DukeScript hingegen eine sehr gute Wahl. Für einfache Anwendungen lohnt es sich, Controls.js for Java in Betracht zu ziehen, das hierfür einen Rapid-Application-Development-Workflow möglich macht. Auch für die Anwendung an ein Server-Backend ist es durch die einfache Kommunikation eine geeignete Technologie. DukeScript bietet Java-Entwicklern einen bequemen Einstieg in die Cross-Plattform-Entwicklung, ohne dabei auf eine erprobte, statisch typisierte Programmiersprache mit der besten IDE-Unterstützung verzichten zu müssen.

Aufmacherbild: keyboard with two phones and tablet pc on wooden desk via Shutterstock.com / Urheberrecht: Valeri Potapova

Geschrieben von
Anton Epple
Anton Epple
Anton Epple hat mehr als zehn Jahre Erfahrung in der Leitung von Java-Projekten und veröffentlichte zahlreiche Artikel über das Thema. Er ist weltweit als Berater für eine Vielzahl von Unternehmen tätig, angefangen von Start-ups bis hin zu Fortune-500-Unternehmen, in vielen Bereichen einschließlich der Finanzinstitutionen und Aerospace. Sein derzeitiges Lieblingsthema ist die Entwicklung von Desktopanwendungen mit JavaFX. In seiner Freizeit ist Anton Community Leader für die Java Tools Community auf Java.net und ein Mitglied des NetBeans Dream Team and Governance Board. 2013 wurde er zum Java Champion ernannt.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Das Überall-Java: Write once run anywhere mit DukeScript"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Jörg Wille
Gast

Guter Artikel! Besonders den Hinweis auf das Projekt dukescript-javafx finde ich interessant.
Ganz kleine Anmerkung: Im Text sind 2 Links vertauscht:
„wie die Zukunft des Tools aussieht“ verlinkt auf „fertiges Design“ und vice versa.