Eine gesonderte Methode gibt es nicht, aber man kann die Mail-Teile ja ablaufen und dann zählen:

int nrOfAttachements = 0;

Multipart mp = (Multipart) message.getContent();

for (int i=0, n=multipart.getCount(); i<n; i++) {
  Part part = multipart.getBodyPart(i));

  String disposition = part.getDisposition();

  if ((disposition != null) && 
      ((disposition.equals(Part.ATTACHMENT) || 
       (disposition.equals(Part.INLINE)))
    nrOfAttachements++;
}

Hierzu gibt es viele Möglichkeiten, eine davon mit JAMon: http://jamonapi.sourceforge.net/.

Mit PHP als Sprache gibt es einiges, im Java-Umfeld sieht es da mau aus. Eine Lösung ist die Google App Engine. Sie ist frei (für normale Quotas), es laufen normale Web-Apps drauf (Jetty), es gibt einen NoSQL-Datastore, und noch mehr. Deployment ist auch sehr einfach, über die IDE.

Ein Konstruktor wird nicht wie Methoden vererbt und überschrieben. Wo also @inheritDoc für sichtbare Methoden der Oberklasse funktioniert, ist das bei Konstruktoren nicht möglich. Eine Lösung wäre, mit @see die Verbindung im Javadoc herzustellen.

Siehe auch http://stackoverflow.com/questions/13327534/details-of-difference-between-see-and-inheritdoc.

Dafür gibt es verschiedene Werkzeuge, die auch erst einmal nichts mit Java zu tun haben. Wenn man das jedoch programmieren möchte, so hilft dbUnit, siehe auch http://www.dbunit.org/howto.html.

Math.sin(double) ist eine native Implementierung, aber wie hier genau optimiert wird, kommt auf die JVM-Implementierung an. Trigonometrische Berechnungen sind echt ein Problem, insbesondere, weil sie alle strictfp durchgeführt werden (siehe Quellcode). Die Berechnung ist zwar native doch muss der Fließkommaprozessor mitunter den IEEE 754 Standard nachbilden, um auf ein exaktes reproduzierbares (eben strictfp) Ergebnis zu kommen auf allen Rechnern zu kommen. Eine oft diskutierte Lösung ist eine native C-Funktion zu nutzen, die direkt SIN vom Fließkommaprozessor nutzt, ohne die in IEEE 754 beschriebene Lösung zu berechnen. (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005861) Das Problem ist in Java 6 angegangen worden aber nicht abschließend gelöst. Vielleicht gehen auch Sin-Tabellen, aber dass muss man dann ganz genau messen, ob sich das lohnt.

Bei der Client-Server-Kommunikation meines Spiels harkt es und das auch nur bei einem Spieler, was kann man tun?

Es gibt kaum Möglichkeiten zur Optimierung im Java-Umfeld. Die Netzwerkverbindung sollte auf bleiben, sodass keine (große) Zeit für den Neuaufbau anfällt. Serialisierung ist nicht so teuer, GZippen wird auch nicht viel bringen. Im lokalen Netz ist time(UDP) = time(TCP) und bei UDP muss man zu viel selbst machen, da bringt auch ein Protokollwechsel im Grunde nichts. NIO wäre mit Kanonen auf Spatzen und lohnt sich nur bei vielen Verbindungen. Eventuell bringt Nagle noch was: http://www.davidreilly.com/java/java_network_programming/#3.3.