Vermisste Sprachfeatures in Java (german)

Sven Efftinge - itemis AG

Vermisste Sprachfeatures in Java


Vorab


Vorab

•Blick über den Tellerrand


Vorab


•Welche Probleme lösen wir auf welche Weise?


Vorab



•Wann und warum nutzen wir andere Lösungen (XML)?


Vorab




•Wie machen das andere Sprachen


Vorab




•Wie machen das andere Sprachen

•Rückwärtskompatibilität wird ignoriert

Properties

machen Code kürzer, prägnanter und damit besser wartbar


Kommt Ihnen das bekannt vor?



public class Customer { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; }}



public class Customer { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; }} Oder das?

Customer c = new Customer();c.setName(“foobar”);//...return c.getName();



public class Customer { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; }} Oder das?

Customer c = new Customer();c.setName(“foobar”);//...return c.getName();


Warum nicht einfach Felder benutzen?

public class Customer { public String name;}

... und ...

Customer c = new Customer();c.name = “foobar”;//...return c.name;


Warum nicht einfach Felder benutzen?

public class Customer { public String name;}

... und ...Customer c = new Customer();c.name = “foobar”;//...return c.name;

• Properties sind evtl. read-only• getter bzw. setter enthalten Logik


Mit “Properties”

• http://weblogs.java.net/blog/forax/archive/2007/01/property_reload.html

http://weblogs.java.net/blog/forax/archive/2007/01/property_reload.html




public class Customer { property String name;} ... und ...

Customer c = new Customer();c.name = “foobar”;//...return c.name;






public class Customer { property String name set { if (val!=null) this.name = val; };}

Beispiel für read-only Property mit speziellem Setter




Type Inference

macht den Code leserlicher, wartbarer und reduziert Komplexität


Ein typisches Stück Javacode

public List<Person> withoutEmil(List<Person> list) { List<Person> result = new ArrayList<Person>(); for(Person p : list) { if (!p.getName().equals(“Emil”)) result.add(p); } return result;}


Type Inference

public List<Person> withoutEmil(List<Person> list) { List<Person> result = new ArrayList<Person>(); for(Person p : list) { if (!p.getName().equals(“Emil”)) result.add(p); } return result;}

Typargument kann abgeleitet werden


Type Inference

public List<Person> withoutEmil(List<Person> list) { List<Person> result = new ArrayList(); for(Person p : list) { if (!p.getName().equals(“Emil”)) result.add(p); } return result;} Variablentyp kann abgeleitet werden


Type Inference

public List<Person> withoutEmil(List<Person> list) { List<Person> result = new ArrayList(); for(p : list) { if (!p.getName().equals(“Emil”)) result.add(p); } return result;}

Rückgabetyp kann abgeleitet werden


Type Inference

public withoutEmil(List<Person> list) { List<Person> result = new ArrayList(); for(p : list) { if (!p.getName().equals(“Emil”)) result.add(p); } return result;}


Type Inference in Java 7?



// Variablen Deklaration



// Variablen DeklarationMap<String, List<Person>> families = new HashMap<>();



// Variablen DeklarationMap<String, List<Person>> families = new HashMap<>(); var families = new HashMap<String, List<Person>>();



// Variablen DeklarationMap<String, List<Person>> families = new HashMap<>(); var families = new HashMap<String, List<Person>>();var families = createFamilies();




// Ableiten aus dem Methodenkontext




// Ableiten aus dem MethodenkontexttimeWaitsFor(new HashSet<>());




// Ableiten aus dem MethodenkontexttimeWaitsFor(new HashSet<>());// oder auch




// Ableiten aus dem MethodenkontexttimeWaitsFor(new HashSet<>());// oder auchtimeWaitsFor(Collections.emptySet());




// Ableiten aus dem MethodenkontexttimeWaitsFor(new HashSet<>());// oder auchtimeWaitsFor(Collections.emptySet()); // Mit Java 5 : // timeWaitsFor(Collections.<Man>emptySet());

Multiline Stringliterale

macht den Code leserlicher und wartbarer - ersetzt externe Lösungen


Neulich beim Testen....

public void testConfig() throws Exception { Configuration c = parse( "<config> " + " <bean class=\""+ Foobar.class.getName()+"\">"+ " <someProp value=\"foobar\"/>"+ " </bean>"+ "</config>"); assertEquals("foobar", c.getBeans().get(0).get("someProp"));}


Besser:

public void testConfig() throws Exception { Configuration c = parse( """<config> <bean class="${Foobar.class.getName()}"> <someProp value="foobar"/> </bean> </config>"""); assertEquals("foobar",c.getBeans().get(0).get("someProp"));}


Anwendungsfälle für Multiline Stringliterale



•Textuelle Testdaten




•Codegenerierung




•Codegenerierung

•HTML/XML Erzeugung (Servlets, etc.)




•Codegenerierung


•Serienbriefe




•Codegenerierung


•Serienbriefe

•Nachrichten an den User (Logging, Error Messages)

author - company

Multiline Stringliterale “selbstgebaut”

public void testConfig() throws Exception { Configuration c = parse( S(/*<config> <bean class="${Foobar.class.getName()}"> <someProp value="foobar"/> </bean> </config>*/)); assertEquals("foobar",c.getBeans().get(0).get("someProp"));}

author - company

Multiline Stringliterale “selbstgebaut”

public static String S() { StackTraceElement element = new RuntimeException().getStackTrace()[1]; String name = element.getClassName().replace('.', '/') + ".java"; InputStream in = getClassLoader().getResourceAsStream(name); String s = convertStreamToString(in, element.getLineNumber()); return s.substring(s.indexOf("/*")+2, s.indexOf("*/"));}

Initializer

macht strukturellen Code deklarativ und damit leserlicherersetzt externe Lösungen (z.B. XML)


Java ist objektorientiert, oder?


Java ist objektorientiert, oder?

Customer c = new Customer();c.setName("foobar");c.setId(4711); Address address = new Address();address.setStreet("Schauenburgerstr. 116");address.setZip("24118");address.setCity("Kiel"); c.setAddress(address); Order o1 = new Order();o1.setArticleId(0815);o1.setAmount(2);c.addOrder(o1);


Aktuell bevorzugter Weg

<Customer name="foobar" id=”4711”>

<address><Address

street=”Schauenburgerstr. 116”zip=”24118”city=”Kiel”/>

</address><orders>

<Order articleId=”0815”amount=”2”/>

</orders></Customer>


So könnte es aussehen...

Customer c = new Customer {name = "foobar";id = 4711;address = new Address {

street = "Schauenburgerstr. 116";zip = "24118";city = "Kiel";

};addOrder(new Order {

articleId = 0815;amount = 2;

});};


Initializer in anderen Sprachen

• Builder in Groovy

• Modelltransformationssprachen (ATL, QVT)

• In C# sieht’s so aus: Person person = new Person { FirstName = "Scott", LastName = "Guthrie", Age = 32, Address = new Address { Street = "One Microsoft Way", City = "Redmond", State = "WA", Zip = 98052 } };


Übrigens so geht es auch schon heute...

Customer c = new Customer() {{name = "foobar";id = 4711;address = new Address() {{


}};addOrder(new Order() {{


}});}};


Übrigens so geht es auch schon heute...

Customer c = new Customer() {{name = "foobar";id = 4711;address = new Address() {{


}};addOrder(new Order() {{


}});}};

Kombination aus Anonymen Klassen und den “alten” non-static initializers

Literale für Collections

macht strukturellen Code deklarativ und damit leserlicher


Collections sind allgegenwärtig



Map<String,Person> personByName = new HashMap<String,Person>();personByName.put(heinrich.getName(), heinrich);personByName.put(maria.getName(), maria);personByName.put(horst.getName(), horst);




Map<String,Person> personByName = new HashMap<String,Person>() {heinrich.getName() => heinrich,maria.getName() => maria,horst.getName() => horst};




// mit Typinferenz könnte es so aussehenvar personByName = new HashMap<>() {

heinrich.getName() => heinrich,maria.getName() => maria,horst.getName() => horst};


Collectionliteral in C#

Dictionary<int, StudentName> students = new Dictionary<int, StudentName>(){ { 111, new StudentName {FirstName="Sachin", LastName="Karnik", ID=211}}, { 112, new StudentName {FirstName="Dina", LastName="Salimzianova", ID=317}}, { 113, new StudentName {FirstName="Andy", LastName="Ruth", ID=198}}};


Collectionliteral in C#

Dictionary<int, StudentName> students = new Dictionary<int, StudentName>(){ { 111, new StudentName {FirstName="Sachin", LastName="Karnik", ID=211}}, { 112, new StudentName {FirstName="Dina", LastName="Salimzianova", ID=317}}, { 113, new StudentName {FirstName="Andy", LastName="Ruth", ID=198}}};

In Kombination mit den zuvor genannten Erweiterungen könnte es in Java so aussehen:

var students = new HashMap<>() { 111 => new StudentName {firstName="Sachin", lastName="Karnik", id=211}, 112 => new StudentName {firstName="Dina", lastName="Salimzianova", id=317}, 113 => new StudentName {firstName="Andy", lastName="Ruth", id=198}};


Collection-Literale in Java

import static java.util.Arrays.asList;

class Foo { List<String> createList() { return asList(“a”,”b”,”c”); }}

import static com.google.common.collect.Maps.*;

class Foo { List<String, int> createMap() { return immutableMap(“a”,2,”c”,3); }}



Eine Proposal für eine Spracherweiterung gibt es z.B. unter

http://jroller.com/scolebourne/entry/java_7_list_and_map





Anonymous Types

Strukturierte Sichten auf Datenbestände


Anonyme Datenstrukturen erzeugen

var students = new Map<>() { 111 => new {firstName="Sachin", lastName="Karnik", ID=211}, 112 => new {firstName="Dina", lastName="Salimzianova", ID=317}, 113 => new {firstName="Andy", lastName="Ruth", ID=1989} };


Anonyme Datenstrukturen erzeugen

var students = new Map<>() { 111 => new {firstName="Sachin", lastName="Karnik", ID=211}, 112 => new {firstName="Dina", lastName="Salimzianova", ID=317}, 113 => new {firstName="Andy", lastName="Ruth", ID=1989} };

Map<Int, AnonymousType<firstName::String,lastName::String,ID::Int>>

Typinferenz ist unbedingt erforderlich

Closures

Neue Kontrollstrukturen per Library


Typischer Javacode


Typischer Javacode

List<Person> filterByName(List<Person> persons, String name) { List<Person> result = new ArrayList<Person>(); for(Person person : persons) { if (person.getName().equals(name)) { result.add(person); } } return result;}


Das Selbe mit Closures

List<Person> filterByName(List<Person> persons, String name) { return persons.select({p => p.getName().equals(name)});}


Das Selbe mit Closures

List<T> select({T=>boolean} function) { List<T> result = new ArrayList<T>(); for(T e : this) { if (function.invoke(e)) { result.add(e); } } return result;}

List<Person> filterByName(List<Person> persons, String name) { return persons.select({p => p.getName().equals(name)});}


Closure: Anonyme Funktion



• Ein Literal für Funktionen




• Speichert den Umgebenden Kontext und greift bei der Ausführung darauf zu





{Person p=>p.getName().equals(“foo”)}






Declared Parameters






Declared Parameters

Block or expression to be executed


Typische Higher-Order Functions auf Mengen



• List<T> select({T => boolean} func)Gibt eine neue Liste, die nur die Werte enthält, für die die Funktion ‘true’ zurückgegeben hat.




• List<R> collect({T => R} func)Sammelt die Rückgabewerte und gibt sie als Liste zurück





• List<T> sort({T,T => int} func)Sortiert die Liste anhand einer Vergleichsfunktion (Comparator)





• List<T> sort({T,T => int} func)Sortiert die Liste anhand einer Vergleichsfunktion (Comparator)

• boolean exists({T => boolean} func)Prüft, ob die Funktion für mindestens ein Element ‘true’ zurück gibt


Resourcehandling


Resourcehandling

FileInputStream input = new FileInputStream(fileName);try { // use input} finally { try { input.close(); } catch (IOException ex) { logger.log(Level.SEVERE, ex.getMessage(), ex); }}


Resourcehandling mit Closures

with(new FileInputStream(fileName), { in => // use input});


Resourcehandling mit Closureswith(new FileInputStream(fileName), { in => // use input});void with(FileInputStream in, {=> FileInputStream} block) { try { block.invoke(in); } finally { try { input.close(); } catch (IOException ex) { logger.log(Level.SEVERE, ex.getMessage(), ex); } }}

Dynamic Dispatch / Multimethods

Visitors, switches, etc. adé


Polymorphismus in Java

class Foo { void doStuff() { System.out.println(“foo”); }} class SpecialFoo extends Foo { void doStuff() { System.out.println(“specialfoo”); }}

SpecialFoo

Foo



class Foo { void doStuff() { System.out.println(“foo”); }} class SpecialFoo extends Foo { void doStuff() { System.out.println(“specialfoo”); }}

new SpecialFoo().doStuff(); ((Foo) new SpecialFoo()).doStuff();

SpecialFoo

Foo



new SpecialFoo().doStuff(); ((Foo) new SpecialFoo()).doStuff();

SpecialFoo

Foooutput:specialfoospecialfoo


Polymorphismus in Java (2)

class Foo {} class SpecialFoo extends Foo {}static void doStuff(SpecialFoo arg) { System.out.println(“specialfoo”);}static void doStuff(Foo arg) { System.out.println(“foo”);}



class Foo {} class SpecialFoo extends Foo {}static void doStuff(SpecialFoo arg) { System.out.println(“specialfoo”);}static void doStuff(Foo arg) { System.out.println(“foo”);}

doStuff(new SpecialFoo()); doStuff((Foo) new SpecialFoo());



doStuff(new SpecialFoo()); doStuff((Foo) new SpecialFoo());

output:specialfoofoo


Mit Dynamic Dispatch in Java

doStuff(new SpecialFoo()); doStuff((Foo) new SpecialFoo();

output:specialfoospecialfoo


Dynamic Dispatch in Java (2)

class Foo { //.... public boolean equals(Object arg) { if (arg instanceof Foo) { Foo arg1 = (Foo) arg; return name.equals(arg.name); } return false; }}


Dynamic Dispatch in Java (2)

class Foo { //... public boolean equals(Foo arg) { return name.equals(arg.name); }}


Multimethod / Dynamic Dispatch



• Non-Invasive und polymorphe Erweiterung von Typhierarchien




• Ersetzt das Visitor-Pattern





• Ersetzt viele ‘instanceof’ Abfragen





• Ersetzt viele ‘instanceof’ Abfragen

• Auch sehr nett in Kombination mit “Extension Methods”

foo.staticMethod() statt staticMethod(foo)

Metaprogramming

Dynamischen Code in statische getypter Sprache?


Dynamische Programmierung



• Inspektion

•Reflection API



• Inspektion

•Reflection API

•Dynamisch Methoden aufrufen

•Reflection API -> Umständlich!



• Inspektion

•Reflection API



•Dynamisch Klassen und Methoden ändern



• Inspektion

•Reflection API



•Dynamisch Klassen und Methoden ändern

•Scripting


Dynamisch Methoden Aufrufen

public Object getName(Object myObj) { Class<?> myClass = myObj.getClass(); try { Method method = myClass.getMethod("getName"); return method.invoke(myObj); } catch (Exception e) { // handle exception } return null; }

In Java :


Dynamisch Methoden Aufrufen

public getName(Object myObj) { return myObj.getName(); }

In Groovy :


Statische Typisierung



•Grundsätzlich sehr nützlich (Feedback!)




•Die Werkzeugunterstützung basiert darauf





•Kein Widerspruch zu






•Kurzen Turn-Arounds






•Kurzen Turn-Arounds

•Interaktiver Entwicklung





•Kein Ersatz für Unittests




•Erhöhte Komplexität





•statische vs. dynamische Typen






•Generics






•Generics

•oft umständliche, generische Programmierung via Reflection


Warum nicht beides?


Warum nicht beides?

• Die allermeisten Codezeilen können sinnvoll statisch getypt werden


Warum nicht beides?


• Dynamische Programmierung eher in der Framework-Entwicklung


Warum nicht beides?



• z.B. durch explizite CompilerEscapes : foo.~unkownMethod()


Warum nicht beides?




• Casts nicht im ByteCode


Warum nicht beides?





• methodMissing() Methode auf java.lang.Object


Warum nicht beides?





• methodMissing() Methode auf java.lang.Object

• Zur Laufzeit Methoden und Klassen hinzufügen

Verschiedenes


Was nervt ...


Was nervt ...

•Checked Exceptions


Was nervt ...


•Native Datentypen


Was nervt ...



•Switch statement


Was nervt ...



•Switch statement

•Arrays


Was nervt ...



•Switch statement

•Arrays

•Built-in Operatoren


Java ist super!


Java ist super!

•Open-Source Community


Java ist super!


•Die Virtual Machine


Java ist super!



•Die Werkzeuge (insbesondere Eclipse)


Java ist super!




•Einfachheit


Java ist super!




•Einfachheit

•Statische Typisierung

Vielen Dank für Ihre Aufmerksamkeit

Noch Fragen?

Technology

Vermisste Sprachfeatures in Java (german)