Die Webseite http://www.25hoursaday.com/CsharpVsJava.html widmet sich sehr detailiert den Unterschieden (und natürlich Gemeinsamkeiten) der beiden Sprachen Java und C#.  Die Diskussion ist auf der Basis von Java 6 und C# 2.0, wobei der Autor Dare Obasanjo in seiner Zusammenfassung auch Bezüge zu C# 3.0 herstellt.

Die JSR 308 (Annotations on Java Types) hat unter anderem das Ziel, Annotationen an weiteren Dingen festzumachen:

• for generic type arguments to parameterized classes:

      Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;
  

• for generic type arguments in a generic method or constructor invocation:

      o.<@NonNull String>m("...");
  

• for type parameter bounds and wildcards:

      class Folder<F extends @Existing File> { ... }
      Collection<? super @Existing File>
  

• for class inheritance:

      class UnmodifiableList<T> implements @Readonly List<@Readonly T> { ... }
  

• for throws clauses:

      void monitorTemperature() throws @Critical TemperatureException { ... }
  

• for typecasts:

      myString = (@NonNull String) myObject;
  

• for type tests:

      boolean isNonNull = myString instanceof @NonNull String;
  

• for object creation:

      new @NonEmpty @Readonly List<String>(myNonEmptyStringSet)
  

  For generic constructors (JLS section 8.8.4), the annotation follows the explicit type arguments (JLS section 15.9):

      new <String> @Interned MyObject()
  

• for method receivers:

      public int size() @Readonly { ... }
  

• for class literals:

      Class<@NonNull String> c = @NonNull String.class;
  

• for arrays:

      Document[@Readonly][] docs4 = new Document[@Readonly 2][12];
      Document[][@Readonly] docs5 = new Document[2][@Readonly 12];
  

  This syntax permits independent annotations for each distinct level of array, and for the elements; see Section 3.4 for alternative syntaxes.

Die Beispiele stammen aus dem working document von Michael D. Ernst. Auf seiner Homepage lässt sich die Compilererweiterung herunterladen und alles über die JSR 308 nachlesen.

FreeCol ist ein Open-Source (GPL) Spiel in Java und ist stark angelehnt an Sid Meier’s Colonization.

Die Grafiken sind ausgezeichnet: http://www.freecol.org/index.php?section=5.

Eigentlich ganz cool und flott in der Darstellung. Es gibt eine JNLP-Datei für Web-Start, mit der man das gleich ausprobieren kann. Interessant ist auch folgende Aussage:

With this SDK, developers can embed World Wind technology in their own applications. The API documentation will be made available later.

Mit „Place Name“ würde ich mir jetzt irgendwie Ortsnamen wünschen, die kommen aber nicht. Der Server könnte auch schneller sein und für feine Auflösungen sind nicht immer Kacheln dabei. Sehr merkwürdig, dass beim Zoom mal Kacheln kommen und dann wieder verschwinden.

Eine erste Programmieranleitung habe ich hier gefunden.

This little example will show you how to bind a JTextField to a name property of a Person with Beans Binding (JSR-295). First the Person:

package com.tutego.binding;

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Person
{
 private PropertyChangeSupport pcs = new PropertyChangeSupport( this );

 private String name = "";

 public void addPropertyChangeListener( PropertyChangeListener x )
 {
   pcs.addPropertyChangeListener( x );
 }

 public void removePropertyChangeListener( PropertyChangeListener x )
 {
   pcs.removePropertyChangeListener( x );
 }

 public String getName()
 {
   return name;
 }

 public void setName( String name )
 {
   String old = getName();
   this.name = name;
   pcs.firePropertyChange( "name", old, getName() );
  
   System.out.println( "Changed name!" );
 }
}

The code for the JavaBean Person is a litte bit cumbersome because of the PropertyChangeListener who will notify the Binding Framework if the model change.

package com.tutego.binding;

import javax.beans.binding.BindingContext;
import javax.swing.JFrame;
import javax.swing.JTextField;

public class BindingDemo
{
 public static void main( String[] args )
 {
   Person p = new Person();

   JTextField tf = new JTextField();

    BindingContext bindingContext = new BindingContext();
   bindingContext.addBinding( p, "${name}", tf, "text" );
   bindingContext.bind();
  
   JFrame f = new JFrame();
   f.add( tf );
   f.pack();
   f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
   f.setVisible( true );

   p.setName( "Christian Ullenboom" );
 }
}

Swing on the other side will although notify the model if the user type text in the text field and press Return. This will change the model.

format() from String or printf() from e.g. PrintWriter will use the default language except you give a Local object as the first argument:

String s1 = String.format( Locale.ENGLISH, "%,.2f", 1000234234.56772345 );
String s2 = String.format( Locale.FRANCE, "%,.2f", 1000234234.56772345 );
System.out.println( s1 );                               // 1,000,234,234.57
System.out.println( s2 );                               // 1 000 234 234,57

And the class Scanner offers nextDouble() that uses the default language too except you use useLocale().

double s1p = new Scanner( s1 ).useLocale( Locale.ENGLISH ).nextDouble();
double s2p = new Scanner( s2 ).useLocale( Locale.FRENCH ).nextDouble();

The methods format()/printf() and the class Scanner are very handy and easy to use.

Die Standardbibliothek enthält 200 Pakete, die Java in der Version 6 deklariert. Sie beschreiben zusammen 3777 Typen, davon 2457 Klassen, 972 Schnittstellen, 49 Aufzählungen, 473 Ausnahmeklassen und 32 Errorklassen. Insgesamt gibt es 1482 Objektvariablen, 4408 statische Variablen/Konstanten, 21881 Objektmethoden in Klassen und 5226 aus Schnittstellen, 3039 Klassenmethoden sowie 4973 Konstruktoren. (In Java 1.0 verteilten sich 212 Klassen auf 8 Pakete.)

Veraltetes hat sich im Laufe der Zeit einiges angesammelt. In Java 6 sind über 334 Methoden, 20 Konstruktoren, 54 Variablen/Konstanten, 21 Klassen (zuzüglich 4 Exceptions), 17 Schnittstellen (viele aus CORBA), 3 Annotationstypen und ein Annotationselement veraltet. Dennoch ist das in Relation zur Gesamtheit klein:

Setzen wir beides in Relation (# Elemente/#deprecated davon)

Klassen: 2457/21 = 0,85%

Schnittstellen: 972/17=1,75%

Exceptions: 473/4=0,85%

Methoden: 21881/334=1,53%

Konstruktoren: 4973/20=0,40%

Variablen/Konstanten: 4408/54=1,22%

Objekte von Klassen, die eine finalize()-Methode besitzen, kann Suns JVM nicht so schnell erzeugen und entfernen, wie Klassen ohne finalize(). Das liegt auch daran, dass der GC vielleicht mehrmals laufen muss, um das Objekt zu löschen. Es gilt zwar, dass der GC aus dem Grund finalize() aufruft, weil das Objekt nicht mehr benötigt wird, es kann aber sein, dass aus der finalize()-Funktion die this-Referenz nach außen gegeben wurde, sodass das Objekt wegen einer bestehenden Referenz nicht gelöscht werden kann. Das Objekt wird zwar irgendwann entfernt, aber der Finalizer läuft nur einmal und nicht immer pro GC-Versuch. Einige Hintergründe erfährt der Leser unter http://www.iecc.com/gclist/GC-lang.html#Finalization.

Löst eine Anweisung in finalize() eine Ausnahme aus, so wird diese ignoriert. Das heißt aber, dass die Finalizierung des Objekts stehen bleibt. Den GC beeinflusst das in seiner Arbeit aber nicht.

Entwickler eigener Swing-Komponenten werden fürs Zeichnen auf getWidth() und getHeight() zurückgreifen. Wegen möglichen Insets sollte man jedoch beim Zeichen die Größenveränderungen betrachten.

@Override
protected void paintComponent( Graphics g )
{
  Insets insets = getInsets();
  int x = insets.left;
  int y = insets.top;
  int width = getWidth() - insets.left - insets.right;
  int height = getHeight() - insets.top - insets.bottom;

  ...

A range is a very handy feature of programing languages like Python.

• range( 10 ) -> 0 1 2 3 4 5 6 7 8 9
• range( 5, 10 ) -> 5 6 7 8 9
• range( 0, 10, 3 ) -> 0 3 6 9
• range( ‚0‘, ‚9‘ ) -> 012345678

 

package com.tutego;

import static com.tutego.Range.range;

public class RangeDemo
{
  public static void main( String[] args )
  {
    for ( int i : range( 10 ) )
      System.out.print( i + " " );

    System.out.println();

    for ( int i : range( 5, 10 ) )
      System.out.print( i + " " );

    System.out.println();

    for ( int i : range( 0, 10, 3 ) )
      System.out.print( i + " " );

    System.out.println();

    for ( int i : range( '0', '9' ) )
      System.out.print( (char) i  );

    System.out.println();

    String[] a = { "Mary", "had", "a", "little", "lamb" };
    for ( int i : range(a.length ) )
      System.out.printf( "%d %s%n", i, a[i] );
  }
}

And the main class Range

/*
 * This project is made available under the terms of the BSD license, more information can be found at
 * http://www.opensource.org/licenses/bsd-license.html
 *
 * Copyright (c) 2007. Christian Ullenboom (http://www.tutego.com/) and contributors. All rights reserved.
 */
package com.tutego;

import java.util.Iterator;

/**
 * Class that generates immutable sequences (ranges) as Iterable<Integer>
 * objects. A range represents a start (0 if not given), an stop (mandatory) and
 * an optional step (1 by default). The start value is included in the range,
 * the stop value is exclusive. Every range is handled by an Iterable<Integer>
 * which can by used in an extended for loop.
 * 
 * <pre>
 * for ( int i : range( 0, 10, 3 ) )
 *   System.out.print( i + " " ); // 0 3 6 9
 * </pre>
 * 
 * @author Christian Ullenboom (tutego)
 * @version 1.0
 */
public class Range
{
  public static Iterable<Integer> range( final int start, final int stop, final int step )
  {
    if ( step <= 0 )
      throw new IllegalArgumentException( "step > 0 isrequired!" );

    return new Iterable<Integer>()
    {
      public Iterator<Integer> iterator()
      {
        return new Iterator<Integer>()
        {
          private int counter = start;

          public boolean hasNext()
          {
            return counter < stop;
          }

          public Integer next()
          {
            try
            {
              return counter;
            }
            finally { counter += step; }
          }

          public void remove() { }
        };
      }
    };
  }

  public static Iterable<Integer> range( final int start, final int stop )
  {
    return range( start, stop, 1 );
  }

  public static Iterable<Integer> range( final int stop )
  {
    return range( 0, stop, 1 );
  }
}

Dinge, die aktuell diskutiert werden und ich interessanter finde:

• The act of writing JSF applications and components „by hand“ will be made much easier by this JSR.
• Allow for „zero configuration“ web applications. No faces-config.xml, no web.xml. If necessary, annotations will be used to supplement the configuration data.
• Leverage annotations to declare JSF artifacts (components, managed beans, navigation rules, etc) to the runtime.
• Eliminate the need to author a JSP tag handler when writing JSF components.
• Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification
• All the artifacts that comprise a JSF application can be modified while the application is running.
• Expand the request processing lifecycle to be aware of Ajax.
• Decent client side, inter-component and form-level validation (leveraging JSR-303 validation if possible).
• Strategic additions to the Standard HTML RenderKit: Date Picker, Tree, Tab View, File Upload components.
• Provide a mechanism to minimize the „Lost Update“ and „Duplicate Button Press“ problems.
• Page actions: The ability to say, „when this page loads, invoke this action (via Ajax if necessary).“
• Allow JSF application resources to be accessed via REST. Add support for REST (JSR 311)
• „Skinning“, or „Themeing“ of components.
• WebBeans (JSR-299)

Die Dinge (und mehr) könnten Teil von Java EE 6 werden.

Links zu dem Thema:

• https://javaserverfaces-spec-public.dev.java.net/proposals/JSF-2_0-draft.html
• http://weblogs.java.net/blog/edburns/archive/2007/03/prejcpfiled_dra_1.html
• http://www.jsfcentral.com/editorial/jsf2_wishlist_1.html
• http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad
• http://www.theserverside.com/news/thread.tss?thread_id=44836

Neue String-Objekte als Kopie von existierende Strings aufzubauen ist ganz schön übel. Aus javax.sql.rowset.RowSetMetaDataImpl:

public void setColumnLabel(int columnIndex, String label) throws SQLException
{
 checkColRange(columnIndex);
 if (label != null) {
  colInfo[columnIndex].columnLabel = new String(label);
 } else {
  colInfo[columnIndex].columnLabel = new String("");
 }
}

Wie die API-Doku zum Konsturktor so schön schreibt:

Unless an explicit copy of {@code original} is needed, use of this constructor is unnecessary since Strings are immutable.

Hans Mueller schrieb schon für JavaOne 2007 eine kleine Einführung in das vielleicht zukünftige Swing-Framework (JSR 296) in Java 7: http://weblogs.java.net/blog/hansmuller/archive/ts-3399-final.pdf. Neben https://appframework.dev.java.net/intro/index.html ist nun unter http://weblogs.java.net/blog/diverson/archive/2007/04/swing_applicati.html ist nun eine weitere keine Beschreibung dazugekommen.

Um die Aufgaben kurz zusammenzufassen: Das Swing-Framwork soll eine (sehr?) leichtgewichtige Alternative zu Eclipse RPC und dem NetBeans Framework werden, um Actions, Properties und Voreinstellungen komfortabel zusammenzubringen. Zentral ist die Klasse Application, die den Lebenszyklus einer Swing-Applikation definiert.

Von https://appframework.dev.java.net/intro/index.html

Im Allgemeinen werden eigene Klassen dann von Application abgeleitet.

public class MySwingApp extends Application {
    JFrame mainFrame = null;
    @Override protected void startup( String[] args ) {
        mainFrame = new JFrame();
        mainFrame.setDefaultCloseOperation( JFrame.DO_NOTHING_ON_CLOSE );
        mainFrame.pack();
        mainFrame.setVisible( true );
    }
    public static void main( String[] args ) {
        launch( MySwingApp.class, args );
    }
}

In startup() werden nun die Komponenten aufgebaut. Dabei können Elemente wie das JLabel auf Eigenschaften aus Property-Dateien zurückgreifen:

JLabel l = new JLabel();
l.setName( "myLabel" );

Unter dem Namen myLabel gibt es einen Property-Eintrag:

myLabel.text=Text vom Label.

Auch der Name des Fensters lässt sich so setzen:

Application.title=Hallo Welt!

Um einem JButton eine Action zuzuweisen (Listener sind nicht mehr nötig), bekommt jede Aktion einen Namen, die in einer Map eingetragen ist.

ApplicationActionMap aMap = ApplicationContext.getInstance().getActionMap( getClass(), this );
JButton btn = new JButton();
b.setName( "myButton" ); 
b.setAction( aMap.get( "los" ) );

Die Aktionen selbst kommen von Methoden, die mit @Action annotiert sind.  Standardmäßig bestimmt der Methodenname den Namen der Action, doch das kann mit name überschrieben werden.

@Action( name = "los" );
public void myAction( ActionEvent e ) {
  System.out.println( "Es hat klick gemacht." );
}

Properties der Schaltflächen lassen weitere Eigenschaften zu:

myButton.Action.text = &Klick mich...
myButton.Action.accelerator = control K
myButton.Action.shortDescription = klicke und du wirst was erleben

Weitere Links:

• http://www.javalobby.org/java/forums/t71186.html
• http://www.artima.com/lejava/articles/swingframework.html
• https://appframework.dev.java.net/

try { ... }
catch ( NumberFormatException ó_ò ) { ... }

Um mit value % 2 == 1 zu testen, ob value eine ungereade Zahl ist, muss value positiv sein, denn -3 % 2 wertete Java zu -1 aus. Der Test auf ungereade Zahlen wird erst wieder korrekt mit value % 2 != 0.

Werden Exemplare einer nicht statischen inneren Klasse serialisiert, die äußere Klasse implementiert aber nicht Serializable, gibt es einen Fehler, denn intern hält ein Objekt der inneren Klasse einen Verweis auf das Exemplar der äußeren Klasse. Statische innere Klassen machen das nicht, was das Problem mit der Serialisierung lösen kann. Das Datenvolumen kann natürlich groß werden, wenn schlanke nicht-statische innere Serializable-Klassen in einer äußeren Serializable-Klassen liegen, die sehr viele Eigenschaften besitzt.

Zwar wird Java 7 höchst wahrscheinlich Closures bekommen, aber nicht jeder wird wissen, dass im Moment ganz unterschiedliche Varianten diskutiert werden:

– Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé (BGGA)
– Bob Lee, Doug Lea, and Josh Bloch (CICE)
– Stefan Schulz (FCM)

Der Blog-Eintragt http://www.jroller.com/page/scolebourne?entry=java_7_comparing_closure_proposals vergleicht Szenarien mit den drei bisherigen Vorschlägen.

FileChannel     fc = new FileInputStream( "c:/a.html" ).getChannel();
ByteBuffer byteBuf = fc.map( FileChannel.MapMode.READ_ONLY, 0, fc.size() );
CharBuffer charBuf = Charset.defaultCharset().newDecoder().decode( byteBuf );
Pattern    pattern = Pattern.compile( "<a.*?href=[\"']([^\"]*?)[\"'].*?>", Pattern.CASE_INSENSITIVE );
Matcher          m = pattern.matcher( charBuf );

while ( m.find() )
  System.out.println( m.group( 1 ) );

fc.close();

RPC-Style oder Document-Style

RPC-Syle (Remote Procedure Style)
Web-Services werden im Sinne von entfernten Methodenaufrufen genutzt.
Eine Web-Service-Methode kann Übergabeparameter und Rückgaben besitzen.
Die Übergabewerte müssen umkodiert werden. XML selbst zum Beispiel wird als umkodierter String übertragen.

Document-Style
Eine Web-Service-Methode hat nur ein Argument.
Das Argument geht als echtes XML-kodiertes Objekt auf den Weg und wird nicht umkodiert.
Da sich jedes beliebige XML-Dokument schicken lässt, ist das flexibler bei Anpassungen, denn Änderungen am WSDL für die Argumente sind nicht nötig.

SOAP-Encoding/Literal-Encoding

SOAP nutzt XML um Daten zu übertragen.
Im Fall von Methoden müssen Argumente und Rückgabewerte wie Zahlen, Strings aber auch Arrays der Datentypen in XML kodiert werden.

Zwei Kodierungen gibt es:

• Literal-Encoding. Literal Encoding nutzt ein XML Schema zum Validieren der SOAP-Daten.
• SOAP-Encoding, auch Section 5 Encoding genannt. Das 5. Kapitel der W3C-Spezifiaktion für SOAP schreibt vor, wie Argumente verpackt werden.

Mit den Varianten RPC- oder Document-Style zu versenden und Daten über SOAP-Encoding oder Literal zu kodieren gibt es theoretisch vier Möglichkeiten.

• RPC/SOAP-Encoding wird nach WS-I Basic Profile nicht empfohlen. (Kann XFire etwa auch nicht.)
• Document/SOAP ergibt keinen Sinn.

Document/Wrapped

Die Variante über Document/Literal, auch Document/Bare genannt, ist in der Praxis üblich. Sie bietet auch die beste Performance http://www-128.ibm.com/developerworks/webservices/library/ws-soapenc/.

Zwar nimmt Document/Literal nur exakt ein Argument, es lässt sich aber tricksen, in dem mehrere Argumente zu einem neuen komplexen Typ werden. Das nennt man Document/Wrapped. Damit ist auch addPerson(int id, String name) möglich.
Die Paramter id und name werden in einen eigenen Complex-Type gepackt.

Der normale GZIPOutputStream nutzt einen Standardkompressionswert. Um diesen zu ändern, ruft man beim Deflator, der eigentlich hinter der Kompresssion steckt, setLevel() auf, um den Kompressionslevel setzen. Die folgende Unterklasse regelt das für uns:

import java.io.IOException;
import java.io.OutputStream;
import java.util.zip.GZIPOutputStream;

public class LevelGZIPOutputStream extends GZIPOutputStream
{
/**
 * Creates a new output stream with a default buffer size and
 * sets the current compression level to the specified value.
 *
 * @param out the output stream.
 * @param level the new compression level (0-9).
 * @exception IOException If an I/O error has occurred.
 * @exception IllegalArgumentException if the compression level is invalid.
 */
public LevelGZIPOutputStream( OutputStream out, int compressionLevel )
    throws IOException
{
  super( out );
  def.setLevel( compressionLevel );
}
}