Tag Archives: java

Jasper kompilierte Programme beschleunigen.

Posted on by

Jasper hat eine unschöne Seite. Benutzt man in einer JSP eine Direktausgabe von HTML Code, was sehr praktisch ist, kommt es zu einer unschönen Situation. Kleines Beispiel:

<%
<div class=olddefect>
 <table border="0">
      ...
 </table>
 </div>
%>

Je mehr Code man in den <% %> Block hat, desto mehr Zeilen hiervon werden erzeugt :

 out.write("\n");
 out.write("<div class=olddefect>\n");
 out.write("\t<table border=\"0\">\n");
 ...
 out.write("\t</table>\n");
 out.write("</div\n");
 out.write("\n");

Und wie man sehen kann, ist das höllisch inperformant. Zeit es zu optimieren.

Will man nun eine WebApp schneller bekommen, bleiben einem nur zwei Wege:

a) Mehr IO investieren z.b. in Form eines Ladevorgangs. Der kann natürlich im RAM gecacht worden sein, aber je nach Umfang der Webanwendung kann das vielleicht nicht funktionieren.
daher b) man verzichtet auf Zeilenumbrüche im HTML Code, so erzeugt Jasper genau eine Zeile out.write(„…“). Die ist zwar unschön, aber performanter.

Diverse Codeverkürzungstools könnte man dafür einsetzen.

Fall jemand rein zufällig einen Jasper Entwickler kennt, schlagt b) mal zur automatischen Optimierung vor. Danke.

Servlet und JSP verbinden

Posted on by

Kleine Exkursion in die Welt von JavaServerPages und Servlets und wie man dazwischen Daten austauschen kann. Zunächst mal die einfache Seite, die JSP :

<%@ page import="java.net.IDN,misc.*,web.*,java.util.*,rsi.*,hash.*,sendmail.Sendmail,java.io.*,server.*,org.json.JSONArray,org.json.JSONObject,ordb.Pandora_server" pageEncoding="UTF-8"
%><%@ include file="cookies.jsp"
%><jsp:useBean id="daten" scope="session" class="hash.StringHash"
/>

Der JSP:useBean Tag ermöglicht u.a. sessionbasierte Objekte in einer JSP zu verarbeiten. Überall wo man den Tag angibt, ist das Objekt verfügbar. Da kann man dann ganz normal drauf zugreifen und mit arbeiten.

if ( daten.checkContent() ) out.write("Daten wurden geprüft und für OK befunden");

Wenn nun ein zweiter Teil der Anwendung in einem Servlet geschrieben wurde,  möchte man ggf. Daten zwischen beiden Teilen der Anwendung austauschen. Ein Servlet ist nichts anderes als eine Klasse, deren vordefinierte Methoden das Request- und Responseobjekt des Webaufrufes bekommen.

Ein kleines, stark vereinfachtes Beispiel:

public class HTMLDispatcher extends HttpServlet {

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doPut(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doDelete(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doPost(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

...
}

Das Servlet kann man dann im Tomcat ( WebApplicationServer ) als Ziel für verschiedene Webaufrüfe definieren (siehe unten). In meinem Fall habe ich gesagt, daß mein Servlet für HTML Aufrüfe zuständig ist. Mein Servlet wertet dann die URL aus und macht mit dem HTML File noch einiges, bevor es ausgegeben wird.

public void doRequest(HttpServletRequest request, HttpServletResponse res)
throws IOException {

res.setContentType("text/html");
Writer out = new BufferedWriter(new OutputStreamWriter(res.getOutputStream(), "UTF-8"));

String method = request.getMethod();
String uri = request.getRequestURI();
String[] args = uri.split("/",-1); // Alles splitten, auch wenn es leer ist

StringHash daten = (StringHash) request.getSession().getAttribute("daten");
if ( daten == null ) daten = new StringHash();

Um an die Daten aus der JSP zu kommen, setze ich „request.getSession().getAttribute(„daten“)“ ein. Das geht aber nur mit Sessionobjekten so. Da die Methode getAttribute() ein klassenloses Objekt zurück gibt, muß selbst den TypeCast machen. Wenn noch keine Session aufgebaut wurde, kann es auch noch kein Bean geben, das wir uns krallen könnten. Damit die Anwendung dann nicht abschmiert, lege ich hier ein Objekt an. Natürlich kann man an der Stelle auch eine Fehlermeldung oder einen Redirect auslösen. Das ist situationsabhängig.

O== Warum überhaupt Servlet und JSP mischen ?

Servlets müssen kompiliert und der WAS Server üblicherweise neu gestartet werden, um die Änderungen anzunehmen. Wenn man JSP Seiten benutzt kümmert sich Jasper darum. Das spart im Einzelfall eine Menge Zeit und man verliert dabei auch keine Sessionobjekte, d.h. kleinere Fehler kann man direkt beheben und weitermachen. Zweifelsfrei eine zeitsparende Methode seine Webseiten zu bauen.

O== Wofür setzt man ein Servlet ein ?

Servlets können auf spezielle Webanfragen eingestellt werden, d.b. bspw. alle Files die auf .jos enden, könnten eine serialisierte Repräsentation des JavaObjekts einer Seite ausgeben, statt HTML Code. Das bekommt man mit reinen JSP Seiten nicht hin.

O== Wie aktiviert man ein Servlet ?

Im WEB-INF Verzeichnis der Anwendung liegt die web.xml Datei. In dieser Datei kann man ein Servlet ganz leicht hinzufügen:

    <servlet>
        <servlet-name>HTMLDispatcher</servlet-name>
        <servlet-class>servlet.HTMLDispatcher</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>HTMLDispatcher</servlet-name>
        <url-pattern>*.html</url-pattern>
    </servlet-mapping>

Die nötigen Klassen müssen dann im dortigen classes Verzeichnis hinterlegt sein.

Java Swing und das Repainten von Komponenten

Posted on by

Von Zeit zu Zeit muß man Dinge tun, welche die Entwickler von Swing nicht vorgesehen hatten. Da wäre z.B. das Updaten einer JTextArea, während das Programm läuft.

Kleines Beispiel:

        for(int i=0;i<names.length;i++ ) {
            infotext = "Uploading file ... "+names[i];
            if ( infotext.length()> 55 ) 
                    infotext = infotext.substring(0, 55);
            updateInfo( infotext );
            String link = p.uploadFile(names[i].trim(),"/");
            result += "File: "+names[i].trim()+"\nShare: "+link+"\n";
        }
    JTextArea text = new JTextArea("");

    public void updateInfo(String text) {
            this.text.setText(text);
    }

Jetzt sollte man annehmen, daß die JTextArea jeweil nach dem setText() den neuen Text anzeigt. Tut sie aber nicht und das betrifft nicht nur JTextArea, sondern so ziemlich alle Komponenten von Swing.

Warum ist das so ?

Swing cacht quasi die ganzen Änderungen und führt diese erst durch, wenn Ruhe eingekehrt ist, d.b. wenn das Programm wartet. Das passiert z.b. wenn eine Dialogbox angezeigt wird. Die Verarbeitung des Programms ist dann eingestellt und es wartet z.B. auf das Drücken des OK Buttons in einem InfoRequester.

Solange das Programm aktiv läuft, gibt es keine Updates, weil das Rechenleistung kostet und sich mit der Zeit einige Inhalteänderungen ergeben haben können, die man dann gemeinsam durchführen kann. So spart das Guisystem Zeit und Resourcen.

Nun ist das Delay einer solchen Sparmaßnahme natürlich kontraproduktiv, wenn es um die kontinuierliche Anzeige neuer Inhalte geht, wie z.b. einem Progressbar oder eben einem textlichen Infofeld wie einer JTextArea.

Die Swing API bietet für Komponenten nun eine Methode repaint() an, die Swing mitteilt, daß die Komponente sich geändert hat und neu gezeichnet werden muß. Soweit, so gut. Leider wird der Rendercall wie schon erwähnt irgendwann gemacht und damit kann man repaint() solange aufrufen, bis man schwarz wird.

Dies Problem haben viele Javaentwickler. Auf den diversen Hilfeseiten findet man die wildesten und vor allem komplett falschen Lösungen für das Problem, in dem Mantraähnlich repaint() oder validate() empfohlen wird.

Alles falsch Leute, die Lösung sieht so aus:

	
        public void updateInfo(String text) {
			this.text.setText(text);
			this.paintComponents( this.getGraphics() );
	}

this bezieht sich dabei auf den eigentlichen Frame z.B. das Panel in dem die Komponente untergebracht ist. paintComponents(g) zeichnet alles neu und damit auch den aktualisierten Text der Area. Der Grund wieso Swing mit Delays arbeitet zeigt sich deutlich, wenn man mehrfach pro Sekunde paintComponents(g) aufruft. Nicht nur daß man die Updates im Viewport sehen kann, es dauert auch so lange, daß man tatsächlich Performanceeinbrüche haben kann. Damit wäre geklärt, wieso es normalerweise delayed ist.

Fazit: Swing ist eindeutig zu langsam konstruiert.