Natürlich bieten moderne Portalsysteme von Haus aus schon mitgelieferte Caching Möglichkeiten an, jedoch hat mit JSR-268 der Entwickler selbst schon einen ersten Angriffspunkt für Optimierungen.

Links:

• Introducing Java Portlet Specifications: JSR 168 and JSR 286
• http://blogs.sun.com/karthikks/entry/caching_in_jsr_286

Abhilfe schafft das kommerzielle Tool JavaRebel, welches als JAR-File in den Application Server (z.B. Tomcat) deployed wird. Der Clou: Änderungen am Quellcode werden so in der laufenden Anwendung sofort und ohne Neustarten des Application Servers aktiv. Dies spart viel Zeit, Nerven und Geld beim Entwicklen von JAVA Anwendungen.

JavaRebel ist ab Java 5 einsetzbar, da das Tool die Instrumentation API (java.lang.instrument) verwendet, um kompilierten JAVA Klassen zu überwachen.

Links:

• http://www.zeroturnaround.com/javarebel/

Nähere Informationen gibt es unter http://at.sun.com/sunnews/events/2008/jun/javadeus08/

See more:

• Download the g4j-0.3.19 stable revision

Befindet sich leider noch in Refactoring Phase, Plugin ist im Moment nur für Eclipse 2.x verfügbar, für Version 3.x wird daran gearbeitet.

StrutsIDE
Project URL: http://amateras.sourceforge.jp/cgi-bin/fswiki_en/wiki.cgi?page=StrutsIDE 

SysDEO Plugin
Project URL: http://www.eclipsetotale.com/tomcatPlugin.html

For MySQL 4.1.X users, we recommend that you use the J/Connector 3.0.X JDBC drivers instead of the newer 3.1.X series. If you must use J/Connector/J 3.1.X then please read Installation FAQ page item #13 on the Roller wiki.

Help! I’m seeing “You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘?’ at line 1″ [#13]

This appears to be due to a MySQL and Connector/J bug that occurs if you use the MySQL 4.1.X server with Connector/J 3.1.X drivers. We recommend that you use the Connector/J 3.0.16 (or later 3.0.X series) drivers with MySQL 4.1.X to avoid this. You can download them from the MySQL site. Drop the jar in your CATALINA_HOME/common/lib and remove any 3.1.X drivers that you have there.

An alternate workaround that will allow you to keep the Connector/J 3.1.X drivers is to disable use of server-side prepared statements by setting the additional property useServerPrepStmts=false in both of the MySQL JDBC URLs in the context configuration.

Roller user Lee Gwun Wai has reported on the roller-user mailing list that this can also occur in the typical ISP-hosted situation where one’s database is using UTF-8 but the overall server character set is something other than UTF-8. He suggests dropping the useUnicode=true from all JDBC URLs. There is additional information on hosted database configuration on our MySQL i18n Configuration Page. We have still only seen this reported with the Connector/J 3.1.X drivers.

• OO for Java – Basic
• Java SE – Basic

JAVA-Code:

	public class Test3 {
		public static void main(String [] args)
		{
			int i = 0;

			Point pnt = new Point(1, 1);
			System.out.println("X: " + pnt.getX());
			System.out.println("Y: " + pnt.getY());
			System.out.println("i: " + i);
			changeValues(pnt);
			changeInt(i);
			System.out.println("X: " + pnt.getX());
			System.out.println("Y: " + pnt.getY());
			System.out.println("i: " + i);
		}

		private static void changeValues(Point pnt) {
			pnt.setX(5);
			pnt.setY(5);
		}

		private static void changeInt(int i) {

			i = 666;

		}
	}

Ausgabe:

	X: 1
	Y: 1
	i: 0
	X: 5
	Y: 5
	i: 0

Wird in JAVA ein neues Objekt erstellt, dann wird das Objekt an und für sich im HEAP abgelegt, die Referenz auf dieses Objekt wird dabei im Stack erstellt und zeigt auf das Objekt im HEAP.

z.B.

	Point pnt = new Point(1, 1);

“pnt” wäre dann die Referenz auf das Objekt.

Wenn nun “pnt” einer Methode übergeben wird, wird intern in JAVA “Call-by-value” angewendet, das bedeutet aber nicht, dass hier das komplette Objekt “kopiert” wird, sondern nur(!) die Referenz auf das Objekt. Im ersten Eindruck könnte man glauben, dass es sich hierbei um “Call-by-Reference” handelt, stimmt aber nicht, da ja die Referenz auf das Objekt “kopiert” wird und die alte Referenz (also jene außerhalb der Methode) erhalten bleibt. Somit gibt es nach dem Methodenaufruf 2 unterschiedliche Referenzen auf ein und dasselbe Objekt. Die Referenzen werden im STACK-Speicher abgelegt und zeigen auf das Objekt, welches sich im HEAP-Speicher befindet.

Nun so gut, aber wie ist das mit primitiven Datentypen ála int, char, String, etc.?
Primitive Datentypen sind in JAVA an und für sich keine Objekte und werden dadurch direkt im STACK-Speicher der JVM abgelegt. Dadruch existieren auch keine Referenzen auf irgendein Objekt.

Was passiert nun bei Parameterübergabe einer Methode?
Hier wird wieder, wie überall in JAVA, “Call-by-value” angewendet. Da es bei den primitiven Datentypen keine Referenzen auf Objekte gibt, werden die Werte der Variablen direkt im Stack für die aufzurufende Methode kopiert. Dh. die neuen Werte sind nur innerhalb der Methode gültig.