flashpixx

Ja, da Postgres z.B. Namespaces und komplexe Stored Procedures, Operatoren, etc enthält, die mySQL nicht beherrscht.

Automatisch gar nicht, Du musst jedes Statement aus dem Dump per Hand anpassen

Das hat mit Java nichts zu tun, deshalb verschoben

Um einen Timer zu entwickeln, was letztendlich eine Stopuhr ist, brauchst Du Threads. Zeitgesteuert wäre das ganze via TimerTask zu erreichen https://rz-static.uni-hohenheim.de/anw/programme/prg/java/tutorials/javainsel4/javainsel_09_012.htm#Rxx365java09012040002D91F04A100 d.h. Dein Counter der Uhr wird jede Sekunde aktualisiert. Natürlich kann man das auch vereinfacht wie lilith2k3 schrieb machen, aber sobald während die Uhr läuft andere Prozesse aktiv sind und das System belasten, wird Deine Stoppuhr nicht korrekt arbeiten. Dies lässt sich eben nur durch Nebenläufigkeit lösen. Ich würde eine Stopuhrklasse von TimeTask ableiten und dort eben passende Methoden implementieren.

Schau Dir Deine Logs des Servers und dort den Referrer an

Die Fehlermeldung gibt Dir an, was falsch ist.

Shadow-Passwort Kryptologische Hashfunktion Salt (Kryptologie)

Collection (Java 2 Platform SE v1.4.2)

@Schlitzauge: Was willst Du damit eigentlich bezwecken? Es gibt für Gleitkommadaten eine Norm IEEE 754 Runden kann man in C++ mit ceil - C++ Reference und floor - C++ Reference (zusätzlich kann man auch noch fmod - C++ Reference und modf - C++ Reference verwenden), Zusätzlich gibt es für Gleitkommadaten limits - C++ Reference womit man eben korrekt die Epsilonumgebung prüfen / erzeugen kann (siehe dazu numeric_limits - C++ Reference ) Eine Umwandlung von einem String in einen Gleitkommadatentyp lässt sich z.B. mit lexical_cast - Boost 1.46.1 oder mit stringstream - C++ Reference realisieren Dein ganzer Code bezüglich des Rundens kann ich mit den Standardfunktionen weitgehend korrekt abbilden

Diesen Ausdruck muss ich mir merken *scnr*

Ohne, dass ich jetzt die Spezifikation im Kopf habe (und getestet habe), müsste bei (*) wenn die Exception auftritt das Programm terminieren, denn da die Exception nicht gefangen wurde, geht sie an die höchste Instanz, d.h. das Hauptprogramm und das müsste dann terminieren. siehe terminate - C++ Reference Das abort generiert ein SIGABRT und ruft nicht den Destruktor der Objekte auf, d.h. in dem Fall bricht es ab. unter abort - C++ Reference D.h. das OS übernimmt hier. Heap bleibt meine Sache, aber entsprechende Stackbereiche müssten durch das OS entsprechend bereinigt werden. Das geht nicht immer. Bei sehr großen Objekten z.B. Matrizen kann ich das nicht mehr machen, wenn ich z.B. eine Matrix elementweise ablege und nun bei jedem Elementzugriff entsprechend prüfen muss, dann geht das unglaublich auf die Performance (bitte mal von 10^6, 10^10 oder 10^12 oder noch mehr Elementen ausgehen). Nein, das sehe ich gar nicht so. Wenn ich eine Klasse konzipiere, dann hat diese definierte Zustände. Bekannte Fehler kann ich durch das Werfen von Exception entsprechend dem Benutzer mitteilen, d.h. aber, wenn dieser eben kein Fehlerhandling implementiert, ist das nicht Sache meiner Klasse das für ihn zu machen. Theoretisch könnte man ja in den Speicherbereich des Objektes irgendwelche Daten schreiben, d.h. ich müsste bei jedem Aufruf einer Methode prüfen, ob die Daten des Objektes konsistent sind, worunter die Performance leidet. Fehlerhandling ist immer Sache der übergeordneten Struktur.

Das sehe ich unter Umständen anders. Z.B. kann java.lang.String bei der Übergabe eines null Objektes eine NullPointerException werfen, d.h. in diesem Fall wirft der Konstruktor die Exception. Was würde dagegen sprechen, dass der Konstruktor die übergebenen Parameter prüft und wenn diese nicht korrekt sind eine Exception wirft. Wenn sie korrekt sind, geht die Initialisierung weiter so dass der Konstruktor terminieren kann. Wird die Exception geworfen, dann sind die Membervariablen auch nicht initialisiert, entweder das Programm terminiert, d.h. bei einer Referenz auf den Stack hat der Compiler entsprechend den Code generiert, so dass der Speicher freigegeben wird oder ich fange die Exception ab und anhand der entsprechenden Objektvariablen wird auch der Speicher des Stacks beim Verlassen des Blocks frei gegeben. Wenn man mit Zeigern arbeitet, dann muss man natürlich im catch-Block entsprechend selbst aufräumen. Das genannte bezieht sich letztendlich auf den genannten Besitzer. Objekte die auf dem Stack platziert werden, darum kümmert sich der Compiler, bei Objekten auf dem Heap muss ich mich selbst darum kümmern. Durch die entsprechende Blockstruktur kann der Compiler erkennen, wann ein Objekt out-of-scope geht und daher wird er dann den Destruktor des Objektes aufrufen. D.h. wenn ich meine Variable innerhalb des try-Blocks deklariere wird dort auch der Konstruktor aufgerufen, d.h. sobald der try-Block verlassen wird, wurde das Objekt vom Stack entfernt. Natürlich muss man darauf achten, dass man eben im Konstruktor die richtige Reihenfolge achten, wenn ich natürlich erst eine Heapreferenz im Konstruktor erzeuge und dann die Exception werfe, dann muss ich mir Gedanken machen, wie ich die Referenz entfernt bekomme. Das Problem bezügl. der Asserts ist, dass man mit Exception anders arbeitet. Man kann als Benutzer der Klasse die Exception fangen und verarbeiten. Letztendlich ist ein Objekt ein Automat, der immer in einem definierten Zustand sein soll. Eine Exception kann man als Fehlerzustand auffassen, rein formal gibt es Pre- und Postconditions, d.h. Anforderungen, die vor bzw nach der Methodenausführung gelten müssen, d.h. in diesem Fall muss als Precondition gelten, dass Nenner != 0 sein muss, d.h. der Konstruktor darf erst gar nicht durchlaufen werden, denn sonst wäre das Objekt in einem Zustand. Nachdem der Konstruktor terminiert würde als Postcondition der Nenner != 0 gelten. Was während der Ausführung geschieht ist nicht relevant (analog zur Schleifeninvarianten). Das ist der oben genannte Punkt. Wie man diesen erreicht muss man problemspezifisch überlegen. In manchen Fällen ist es sinnvoller den Konstruktor terminieren zu lassen und durch eine entsprechende Membervariable den Zustand kenntlich zu machen, führt aber natürlich dazu, dass man dieses als Speicherplatz berücksichtigen muss und ggf. wenn eine Methode mehrfach aufgerufen wird, bei jedem Methodenaufruf geprüft werden muss, was letztendlich Aufwand bedeutet. Andernfalls kann man mit Asserts manche Probleme abfangen oder eben, wenn es sich um dynamische Daten handelt eine Exception benutzen

Das Problem ist doch mit einer einfachen Exception und eines try-catch Blocks gelöst. Wenn der Konstruktor die Daten bekommt und eben bei fehlerhaften Daten eine Exception wirft, dann kann man diese mit try-catch abfangen. Entweder mache ich das mit einer lokalen Variablen, sobald der Block verlassen wird, ist die Variable vom Stack verschwunden (bzw. wenn man sie überschreibt). Andernfalls kann ich das Objekt auf den Heap legen und eben im try-catch Block feststellen, ob es korrekt initialisiert wurde. Wenn man es richtig macht, prüft man im Konstruktor bevor Speicher allokiert wird ob alle Daten korrekt sind, d.h. tritt die Exception aus, sind alle lokalen Stackvariablen des Objektes auch vernichtet, da das Objekt out-of-scope geht. Innerhalb des try-catch Blocks weise ich einer Zeigervariablen den Zeiger des Objektes zu, so dass man prüfen kann, ob der Zeiger null ist, wenn ja, wurde das Objekt nicht richtig erzeugt. Bei Ablage auf dem Heap muss man natürlich von der übergeordneten Struktur dafür Sorge tragen, dass der Speicher des Objektes auch wieder frei gegeben wird

Eine Möglichkeit wäre das ganze via Zeiger und Platzierung auf dem Heap durchzuführen, als andere übergebe das ganze als Zeigerreferenz.

1) löst eine Exception in Deinem Objekt im Konstruktor aus 2) Asserte es, mit einem statischen Assert sollte der Kompiler das finden können

Ich drück mal die Daumen

*g* stimmt Das stimmt, man muss im Grunde erst mal alle Referenzen auf die Klasse aus dem Speicher entfernen, bevor der GC dann wirklich aufräumen kann. Da der GC letztendlich zyklische via Mark & Sweep / Compact durch alle Objektreferenzen durchgeht, muss man bevor man eine Klasse entfernt eben erst einmal alle Objekte als "not-used" markieren, damit der GC sie entfernen kann. Erst wenn das geschehen ist, kann man die Klasse entladen. @Topic: Nein Eclipse durchsucht nicht, sondern die Klasse wird während der Codings immer wieder kompiliert, denn z.B. korrekte Einrückung kann nur dadurch korrektes Parsen & Compilieren fest gestellt werden (Blockbildung Dyck-Sprache ist nur mit einer Kontextfreie Grammatik verarbeitbar). Die Klasse wird nicht geparst sondern wirklich instanziiert und dann zur Laufzeit verarbeitet.

bekannt ist Home of The Webalizer evtl auch AWStats - Free log file analyzer for advanced statistics (GNU GPL).

Genau das macht das Hot Deplayment doch eben nicht. Beim Hot Deployment existiert ein eigener Classloader, der auch dafür sorge trägt, dass dann Klassen aus unterschiedlichen Pfaden geladen / entladen werden. Beim Entladen läuft dann der GC drüber und entfernt die Objekte aus dem Speicher. Der Classloader koordiniert die Zugriffe auf der Dateiebene und sorgt für das Instantiieren. Formal wird nicht der Classpath erweitert, sondern der Classloader lädt anhand der Struktur die passenden Klassen (ggf. auch mehrfach).

Wenn Du jetzt nur die Daten aus der XML anhand des Schemas verarbeiten willst, würde ich zu Jax greifen und via Mashalling die Daten aus der Klasse parsen. Jax kann anhand der Schemadatei Java Klassen erstellen, die Du direkt verwenden kannst. Ansonsten kannst Du eben mit jedem XML Parser nun Deine Datenstruktur auch händisch verarbeiten

Möglich ist das schon. Aber Du musst eben entweder die Spezifikation von XML Strict einhalten und eben kein halbes HTML Dokument verarbeiten, dann ist es normal, dass der Parser eben Fehler produziert. Oder Du definierst Dir Dein eigenes Format (ich würde zu einem XML Schema raten) und transformierst es z.B. via XSLT in das gewünschte Ausgabeformat.

Also wenn Du versuchst die Code als HTML und als XML zu verarbeiten, dann wird das in diese Form fehlschlagen, denn es ist kein HTML und ein XML entsprechend der Spezifikation, die Du via DTD angibst ist es auch nicht.

Es es völlig egal, was Du darüber denken magst, sondern es interessiert wie die Rechtsprechung den Fall beurteilt. Sofern die Lizenzbedingungen von Apple juristisch das klar untersagen und es nach deutschem Recht Gültigkeit hat, verstößt Du gegen den Lizenzvertrag.

Ja. Soweit ich das im Kopf habe, geht das nicht, dass man dynamisch den Classpath erweitern kann. Zur Laufzeit ist meines Wissens keine Änderung möglich. Ein Jar ist kein Dateistream im eigentlichen Sinne. Ein Jar ist ein Zip-Archiv, wobei man eben dort eine ganze Reihe an einzelnen Klassen hat, die aber durch Packages organisiert sein können. D.h. wenn Du die Klassen aus einem Jar einbinden willst, dann musst Du einen eigenen Classloader schreiben und damit ggf den Standard-Classloader ersetzen, denn Wenn z.B. eine Klasse aus dem Jar instantiiert wird und eine Klasse, die ebenfalls innerhalb des Jars liegt, instantiiert würde der Standard-Classloader eine Exception werfen, da er diese weitere Klasse nicht erreichen kann. Das ganze halte ich aber für extrem unhandlich und im Sinne, dass Du eine externe Komponente nutzen willst, auch für nicht sinnvoll. Bei externen Komponenten wird man via Class.forName, die entsprechende Klasse laden, wobei man davon ausgeht, dass die Klasse/en im Classpath liegen, z.B. bei JDBC verfährt man so. Liegt der JDBC Treiber nicht im Classpath erhält man eine Exception und der User muss dann eben die fehlenden Daten ergänzen

OSx86 - Wikipedia, the free encyclopedia Das als Motivation für eine Ausbildung finde ich extrem dünn. Ich betreibe auch ein Gigabit und habe keine Probleme mit der Performance.