PPCNUX / mcnix

Hallo,

Ich hab mal ein paar Fragen zur java-Programmierung. Ich muss möglichst bis Montag Mittag ein Program stehen haben. Das ganze sieht so aus:

- Da ist ein "Server", auf dem wir "Aufträge" abladen und ausführen wollen.
- Dieser Server kann nur über eine sog. "Workstation" angesprochen werde. Diese
ist in Java geschrieben und wird vom Betreiber des Servers gestellt. (Ohne Source)
- Es gibt ein Java-API mit dem man Client-Programme schreiben kann, mit denen man die
"Workstation" anspricht.
- Wir haben ein Programm, dass die Aufträge generiert. Dieses ist in C geschrieben.
- Nun brauchen wir ein Java-Program, das zwischen C-Program und "Workstation"
vermittelt. Und um dieses geht es. Ich möchte die Program mal im folegnden Gateway
nennen.

Pro Tag werden mehrfach "Aufträge" vom C-Prgramm generiert. Während dieser Zeit müssen Gateway und Workstation permanent laufen, da sie manuell gestartet werden müssen, der Rest aber automatisch gehen soll.

Die Fragen sind nun:

- Wie kann das C-Programm dem Gateway sigalisieren, dass es etwas zu tun gibt. Die "Aufträge" selbst werden wohl als Dateien übermittelt. Muss das Gateway nach diesen Dateien pollen oder gibtkann ich mit Java (wie bei C/C++) Signal abfangen und darauf reagieren (z.B. SIGUSR1 oder SIGHUP) .

- Das Gateway hat die meiste Zeit nichts zu tun (ausser ggfs zu pollen) . Wie kann ich es schlafenend stellen, analog zu sleep() unter C. Ich habe nur eine sleep Methode für Threads bei Multithreading gefunden. Das Gateway ist aber Singlethreaded.
Se;lbst beim pollen wäre ein sleep(5) nicht schlecht, dami das Gateway die CPU-Zeit nicht sinnlos verschwendet.

- Wie kann ich unter Java das aktuelle Datum herausfinden und ggfs als String im ISO-Format (YYYYMMDD) bekommen. ( Zu den beiden ersten Fragen habe ich schon die Dokus durchforstet, soweit ich soie gefunden habe. Leider ohen Erfolg. Diese Frage ist mir erst heute morgen beim Nachdenken darüber gekommen).

In der Hoffnung das hier ein paar Java-Coder helfen können.

Bis dann

R"udiger

Mal das Einfache zu Erst :

lad dir das Teil mal runter :
http://www.javabuch.de/download.html
dann gehst du auf Seite 355 ff., Kapitel Die Klassen Date, Calendar und GregrionCalender
du kannst die recht nett dann yyyymmdd zusammenbauen.

Die Datumsfunktionen sind denen in C nicht unaehnlich und komfortabel

Man kann recht komfortabel einen Prozess einrichten, der nur dann gestartet wird, wenn es tatsaechlich sein muss.
RMI , Ab Seite 1091, Kaptitel 46 Remote Method Invocation (RMI)
Allerdings laueft im Hintergrund eine Registry, an denen sich die Sachen anmelden. Das braucht aber nicht viele Resourcen.
Sockets geht auch. Kapitel 45, ab Seite 1059.
Signals und Co snd moeglich, schau mal bei der IBM bei den Developers, da findest du was.
Allerdings, ist das Systemnah und das will java nicht sein. Es will nah zu seiner Virtual Maschine sein....

Auch das "Main - Programm" ist ein Thread. this.sleep(DORNROESCHEN) ; geht .

C<->Java ist m[glich aber nicht leicht. Java -> C ist leicht via JNI (Java Native Interface).

Ich denke aber das Einfachste fuer euch ist eine Art Socket Komunikation, denn das kann Linux mit C/C++ gut und Java auch.

Du kannst das dann auch leicht erweitern. Ich werde jetzt nicht vorschlagen die Nachrichten (Huhu, es ist ein Autrag da, geh und hol die Datei) per XML zu machen, das waere zwar "Hype" aber etwas geschaetzig und uerberkandidelt.

Hoffe dir geholfen zu haben.

Gruss Frank

Es gibt die statische Methode "static void Thread.sleep( )", mit der man den aktuellen Thread schlafen legen kann. Der Code müsste in etwa so aussehen:


Das mit dem Datum müsste über



gehen. Um dann die einzelnen Werte für Tag, Monat etc. reauszufischen muss man dann wohl die get-Methode anwenden, also rightNow.get(DAY_OF_WEEK). Anschließend könnte man sich daraus einen String zusammenschustern. Ich weiß ist beknackt, aber die Methoden der Klasse Date sind als deprecated markiert und sollten deshalb nicht mehr verwendet werden (was mich selber verwundert) - aber ich musste noch nie was mit Datum in Java machen... (vermutlich wird sich Frank gerade auch die Haare raufen bei dem Vorschlage, auf die Schnelle fällt mir aber nichts besseres ein). Zu den Signalen kann ich dir nichts sagen, da muss Frank aushelfen

Gruß, Lars

wie , was ?
Date "deprimated" ?
was kommt denn dann ?
Java 5 ?

Oh Mann, wir verwenden Date oft....

Gruss Frank

Hallo,

Erst mal dank euch beiden. Das das mit dem Thread.sleep auch bei Singlethreaded geht war mir nicht klar (Eh das ist mein erstes wirkliches Java-Program)

Auch wenns zu systemnah ist, wären mir Signale am liebsten, weil es dann einacher bleibt (on Single spingt das Prog an und tut was soll und gut ist, keine Auswertung von Nachrichten usw. Und mit Signalen hab ich schon gearbeitet (ein nicht zu unterschätzender Vorteil wenn die Zeit knapp ist ) Und portable muss das Teil auch nicht sein.

Anderseits, wenn ich IBM richtg verstehe, sollen/werden SIgnale unter Java nur dazu verwendet n der einen oder anderen Form einen Shutdown durchz`uführen oder zur internen Kommunikatio (Ärgelich schient hier zu sein das SIGUSR1 und SIGUSR2 bereits von der JVM verwendet werden).

Anderseits bin ich gerade auf ein Javasignals gestossen. Wenn das läuft wäre es das was ich suche. Werds morgen mal ausprobieren.



BTW: Gibt es eigentlich ein Java 1.4.x für LInuxPPC,das sauber ist (IBM 1.4.2 ist es ja wohl nicht) und auf meiner SuSEW 7.3 läuft. BlackDown geht leider nur bis 1.3.1

Bis dann

R"udiger

Hmm, ja ich weiß auch nicht, auf jeden Fall ist unter http://java.sun.com/j2se/1.4.2/docs/api/index.html nahezu jede Methode von Date mit "Deprecated. As of JDK version 1.1, replaced by..." markiert.

Gruß, Lars

Hallo,

O.K. Das Prog steht. Aber, mit Verlaub Java ist eine Sch***-Sprache. (Beispiele bei Bedarf)

Eine Frage hab ich aber noch. Sie ist allerdings eher kosmetischer Art. Wie bekomme ich formatierte Ausgabe hin. In den Büchern hab ich nix gefunden. Momentan wird in der Ausgabe aus 5 min nach 12: '12:5' statt '12:05', was sich in log eibesser liesst.

Any Hints?

Bis dann

R"udiger

PS: Das Datumsproblem hab ich mit Calendar gelöst, sleep(0 war easy nachdem klar war das auch bei SingleThreaded ein Thread-Objekt existiert. Und Signale verwende ich nun nicht. Statt dessen wird gepollt. Leider.

Ohne deinen Code zu kennen: evtl. hilft es erst in einen String zu konvertieren und dann noch bei Bedarf 'ne "0" mit einzufügen. (wie gesagt, kenn die Datumsfunktionen auch nicht).

Ansonsten zeig mal die Beispiele, warum Java eine Sch***-Sprache sein soll *gespannt sei*

Gruß, Lars

Hallo,

Beispiele.
1. Java kennt keine Pointer! Wirklich? Jede Variable ist ein Pointer! (Nennt sich halt nur
Verweis), d.h. das ganze Speichermanagment ist undurchsichtig.

Beispiel:

legt einen String an, denn man dann füllen kann.
Aber

legt nicht 4 Strings an, sondern nur 4 Verweise. Wozu brauch ich dann aber den
new-Operator?. Wenn eh jede Variable ein Verweis ist, würde es doch auch

tun, was in sich konsistenter wäre. In C/C++ -Logik steht dann eben vor jeder Variable immer ein '*'.

Durch diese ich tu so als ob och keine Pointer habe, verwende sie aber ständig bin ich mir
nie ganz sicher auf welchem Objekt ich gerade arbeite. Und umgekehrt, wie oft sinnlose
Kopien angelegt werden, wo ein Pointer reichen würde (Methode-Aufruf z.B.)

2. Ich hatte dann glücklich einen String geüllt und war hocherfreut das es die
trim()-Methode gibt. Ich muss zugeben, flüchtig gelesen zu haben. Aber warum legt

eine Kopie von str an und trimt diese, statt wie es IMHO der OOP-Logik entspräche sich zu trimmen.

3. Warum muss es zig Stream-Klassen geben, die alle Spezialfälle abdecken, statt einer (oder
zwei) mächtiger Klassen pro Richtung, die alles wesentliche abdecken, quasi eine Klasse die
alle C-Funktionen, die auf FILE * arbeiten in sich vereint. Ich hab keine Klasse gefunden, die
- Characterweise lsen kann (analog fgetc,fputc)
- Speichernblöcke lesen kann (analog fread, fwrite)
- zielenweise (analog fgets()), in diesem Fall müsste man sowohl nach String als auch anch char/byte-Arrays)
- und formatiert lesen (analog zu fscanf() ).

Formatierte I/O hab ich bisher gar nciht gefunden

4. Warum muss der File mit der Main.-Klasse Main heissen?

Das ist das was mir an Frust der letzten Tag spontan einfällt.


Zur Formatierten Ausgabe.

Ich wünschte mir eine



Bis dann

R"udiger

Du arbeitest im Prinzip immer auf dem selben Objekt. Objekte werden in Java immer per Referenz übergeben (ich denke es ist mit den Referenzen aus C++ vergleichbar, nix mit Pointer). Auch bei Methodenaufrufen werden Objekte per Referenz übergeben, da erfolgt keine Kopie (ich glaube nur bei den Grunddatentypen wie int, double etc. erfolgt die Kopie)



Die String-Klasse ist in Java als unveränderliche Klasse implementiert (afaik auch aus Sicherheitsgründen). Deswegen gibt die trim( )-Methode immer eine Kopie zurück, weil sie ja das eigene Objekt nicht manipulieren darf. Um ein und denselben String zu bearbeiten (also keine Kopie zu erhalten), nimmt man gewöhnlich die StringBuffer-Klasse, welche einen veränderlichen String darstellt.



Hmm, gute Frage, letztendlich gibt es aber eine Oberklasse, von der alle weiteren erben. Somit ist es zum Beispiel extrem einfach ein Objekt zu serialisieren: das geht zum Beispiel über ein File genauso gut wie übers Netz.

Zeilenweise kann man zum Beispiel über die readLine( )-Methode eines BufferedReader-Objektes. Einzelne Zeichen (also char) sollten sich über ein Objekt der Klasse CharArrayReader lesen lassen. Letztendlich bietet das Paket java.io für jeden Fall eine Klasse an, die eine solche "Spezialaufgabe" erfüllt.




Muss er doch gar nicht. Jede Datei muss nur so heißen wie die Klasse, die in dem File definiert wird. Zum Beispiel definierst du eine Klasse



dann muss der File auch ClassA.java heißen. In welcher Klasse die main-Funktion steht, ist letztendlich egal. Du kannst in einem Projekt auch mehrere Klassen haben, die jeweils eine main-Funktion mitbringen. Beim Starten musst Du dann nur die Klasse angeben, deren main-Funktion ausgeführt werden soll.




Wie gesagt, mir fällt auf die Schnelle nur das mit der Konvertierung in einen String ein.

Gruß, Lars

Ehm. Soweit ich sehen kann ist eien C++-Referenz nix anders als ein Pointer der so tut als wäre er keiner. Was ich sogar für gefährlich halte (in C++): Bei einem Pointer muss ich um den Wert (auf den er zeigt) zu ändern bewusst anders zugreifen. Bei einer Referenz sieht es so aus als wäre es eine Kopie und Flux habe ich auch die Variable in der aufrufenden Funktion geändert. BTW: IMHO Untergräbt das konsequnte Arbeiten mit Referenzen das Konzept von globalen und lokalen Variablen, da alle übergeben Variablen ja quasi global sind (zumindest bis zu der Ebene auf der sie ursprünglich definiert wurde).


O.K. Nehm ich zum Teil auf meine Kappe. Auch wenn es mir ein Bruch von OOP-Prinzipien zu sein scheint. Machmal muss man Prinzipien brechen, z.B. wegen Sicherheit. Allerdings kam mir beim Überfliegen StrignBuffer etwas unklar vor, was es genau sein soll. Deshlab bin ich bei String geblieben.




Das Problem kommt dann, wenn man mehere Zugriffmethoden mischen möchte oder muss (z.B> beim ppm Format, erst ASCII-Zeilen,m dann Binär-Daten). Abgesehen davon das ich nciht weiss was Serialisieren ist (bin halt Autodidakt), warum geht das mit vielen Spezialklassen besser als mit einer universellen?.



Warum? z.B. kann es IMHO Sinnvoll sein mehrer Klassen die zusammen etwas darstellen in einer Datei zusammenfassen, die dann u.U. besser nicht nach einer der Klassen benannt wird sondern eine übergeordneten Namen hat.



Natürlich soll es einen String ergeben. Nur wenn ich die Teil zusammenconcat (via +) fehlen die führenden "0" wo nötig. Und ein Äquivalent zu sprintf habe ich nicht gefunden.
Und zusammenpusseln mit if(tag<10) ... else.. kanns ja wohl nicht sein.


Bis dann

R"udiger

PS: Eine andere Sache die ich an Java nervig finde (die man aber wohl auch in C++ ähnlch machen kann) ist das try-catch im Vergleich zum checken des Rückgabe wertes. Die try-catch Syntax erzeugt IMHO ne Meneg Text-Noise ohne das sie wirklich Vorteile bringt (oder ich hab sie bis jetzt nicht gesehen.) Und Textnosie schadet der lesbarkeit und nachvollziehbarkeit von Code weil Zusammenhänge zu weit auseinander gereissen werden.

*Ich habe als Zitate nur das verwendet, was du im letzten Posting geschrieben hast, um das ganze wieder etwas übersichtlicher zu machen; hoffe der Gesprächsfluß leidet darunter nicht allzu sehr*



Aber ist das nicht bei Pointern genau dasselbe? Damit kann man das ja auch untergraben.
Java wurde halt so designt ohne explizite Pointer auskommen zu können und eigentlich klappt das ja auch ganz gut. Das alles per Referenz übergeben wird, hat ja nur was mit Effizienz zu tun.




So ein Problem hatte ich bis jetzt noch nicht. Aber wäre es denn rein theoretisch nicht möglich alles in ein byte-Array einzulesen und damit dann weiterzuarbeiten? Was letztendlich zu dem Design der Klassen geführt kann ich dir auch nicht sagen, aber wirklich OOP wäre das ja auch nicht mehr, wenn eine Klasse so allgemein gültig sein soll, dass sie zur eierlegenden Wollmilchsau wird!? (IMHO)

*EDIT* Serialisieren bedeutet einfach ein Objekt persistent zu machen, es zum Beispiel mit seinen aktuellen Werten in den einzelnen Variablen abzuspeichern. In Java ist das auch eine Möglichkeit ein Objekt zu kopieren.



Das geht natürlich auch, nur kann pro File nur eine Klasse das Attribut "public" tragen, die anderen Klassen im selben File dürfen dann nicht mehr public sein. Es ist auch möglich eine Klasse innerhalb einer anderen zu definieren.



Ja, das ist mur auch schon aufgefallen. An manchen Stellen werden Exceptions geworfen, wo es auch ein spezieller Rückgabewert getan hätte. Da muss man dann halt zu try/catch greifen.

Gruß, Lars

Werd mich mal auch mal die Zitate stärker kürzen.

In C/C++ ist eine Referenz und eine bei value übergebene Variable ununterscheidbar, ausser in der Deklaration/Definition der Funktion. Bei eine Pointer ist immer klar zu erkennen, Hey ich bin in globalen Kontext. Durch Wahl by value oder by pointer zu arbeiten, kann ich das angmessene wählen. Ist alles bei Referenz gibt es nur noch einen semi-globalen Kontext. Bei alten Sprachen, wie Fortran etc, mag sowas noch verständlich sein und im High-Performance-Computing auch. Aber wenn man viel Performance in Kontruktur/Destruktor-Aufrufe "verschwendet" macht es IMHO wenig Sinn nur by reference zu arbeiten. (Auf dem Newton mit seinen begrenzten Resourcen machte es auch Sinn).

IMHO behält Java die problematischen Seiten der Pointer-Artimetik (der unklare Kontext bleibt erhalten), gibt aber die Stärken auf, z.B. mehrfache explizite Verweise auf ein Objekt, z.B. zu "Refernzzwecken" .



Wieso soll das nicht OOP sein. Woher der Zwang alles durch möglichst viele Vererbungebnen zu realisieren. Effizienter wird es daurch wohl kaum (der link, linkt eh nur was gebraucht wird). Und eine große Klasse zu lernen dürfte auch einfacher sein als den Klassenzoo von Java (ich muss morgen mal zählen wieviele I/O-Stream-Klassen ich finde)


Ehm, Was ist daran besonders? <sarksamus> Oder muss man das extra einführen, da Java eigentlich nur mit Referenzen arbeitet. Sowas hab ich bisher eine globale oder auch nur eine static-Variable genannt</sarkasmus> Oder hab ich jetzt was nicht verstanden?



Wozu diese Einschränkung? Ich kann dariun keine Sinn erkennen. Bestenfalls soweit, das dadurch javac vielleicht etwas einfacher zu bauen ist.


Das mich niemand falsch versteht. Wer mit Java glücklich ist, soll es bleiben. Aber ich kann kaum erkennen, wo Java besser sein soll als C++. Ich habe das Gefühl das Java eher eine Sprache mit mehr Einschränkungen ist, die eine behindern, als wirklich weiterhelfen. C++ hat sicher auch seine Schwächen (welche Sprache hat das nicht).

BTW: Um auf den Ausgangspunkt zurück zukommen. Für das Programm, das ich in den letzten Tagen geschrieben habe, hät es auch reiner prozedualer Code getan. Und wahrscheinlich wäre er sogar wartbarer weil linearer in seinem Ablauf. Das Ding macht nicht viel mehr als auf Eingabe warten und wenn die da ist, dann nach immer dem gleich Schema abarbeiten.

So das reicht f[r heute

Bis dann

R"udiger

Hmm, in Java können aber auch mehrere Variablen dasselbe Objekt referenzieren (oder besser gesagt den Speicherbereich, den das Objekt belegt). Ich denke das meinst Du mit mehrfachen expliziten Referenzen. Das ganze ist in Java aber dahingehend problematisch, dass man nicht vergessen sollte, alle Referenzen irgendwann auf "null" zu setzen (bzw. den Wert der Variablen, die die Referenz herstellt), denn ansonsten kann der Garbage Collector den vom Objekt belegten Speicher nicht wieder freigeben, da ja noch irgendwo 'ne Referenz besteht. Letztendlich wurde die Sprache so entworfen ohne Zeiger auszukommen, da man ja mit Pointern auch jede Menge Blödsinn anstellen kann - vielleicht wollte man das vermeiden.



Ja, wirklich übersichtlich ist das ganze nicht. Ich weiß nicht, wie die Entwickler auf diese Vererbungshierarchie gekommen sind. Ist sicher nicht optimal. Im Prinzip reicht es die Klassen im Package java.io zu zählen.



Beim Serialisieren wird ein Objekt in einen Byte-Strom verwandelt. Diesen kannst Du anschließend in einer Datei abspeichern. Später kannst Du diese Datei wieder einlesen und somit das Objekt wieder herstellen. Du kannst das Objekt aber auch übers Netz schicken und woanders weiternutzen (wobei RMI dafür sicherlich der bessere Ansatz wäre).

Zitat aus dem Buch von Guido Krüger: "Unter Serialisierung wollen wir die Fähigkeit verstehen, ein Objekt, das im Hauptspeicher der Anwendung existiert, in ein Format zu konvertieren, das es erlaubt, das Objekt in eine Datei zu schreiben oder über eine Netzwerkverbindung zu transportieren. Dabei wollen wir natürlich auch den umgekehrten Weg einschließen, also das Rekonstruieren eines in serialisierter Form vorliegenden Objekts in das interne Format der laufenden Java-Maschine.

Serialisierung wird häufig mit dem Begriff Persistenz gleichgesetzt, vor allem in objektorientierten Programmiersprachen. Das ist nur bedingt richtig, denn Persistenz bezeichnet genaugenommen das dauerhafte Speichern von Daten auf einem externen Datenträger, so daß sie auch nach dem Beenden des Programms erhalten bleiben. Obwohl die persistente Speicherung von Objekten sicherlich eine der Hauptanwendungen der Serialisierung ist, ist sie nicht ihre einzige. Wir werden später Anwendungen sehen, bei der die Serialisierung von Objekten nicht zum Zweck ihrer persistenten Speicherung genutzt werden."


Hauptsache dein Programm steht und es läuft zufriedenstellend

Gruß, Lars

Dachte ich mir doch das da noch was kommt, nach dem du im ICQ auftauchtest



O.K. hatte ich anders verstanden. Nur Aufregend finde ich es nach wie vor nicht. Da ganze kann ich doch auch mit einer Struct oder Klasse unter c/C++ und den Kommandos fwrite/fread erreichen., bzw. write und read (dann geht es auch über Netzwerk-Socktes).

Natürlich müssen Sender und Empfänder beide die Klasse / die Struct kennen. Aber das ist ja wohl bei Java auch nicht anders. Oder kann Java aus dem gespeicherten Objekt, die Klasse in einem anderen Program importieren? Und was soll das anderes Programm damit anfangen, wenn es zur Kompilzeit Varbiablen und Methoden nicht kennt?

Kurz wirkt auf mich wie eine toller Name für etwas eigentlich recht selbstverständliches. Aber was solls.

Ausserdem bis du wohl in Bett (jedenfalls aus dem ICQ verschwunden).
Dann ruf ich dir mal ein GUTE NACHT nach.

Bis dann

R"udiger,
der jetzt auch Schluss für heute macht.

was du beim Serialiserien alles ablegen kannst ist schlicht der Hammer.
Es können automatisch ganz Objektbäume serialisiert werden, die bei Bedarf wieder eingelesen werden und somit die Objecte wieder materialisiert werden.
Kennen zB. die Java Anwendungen die Kalssen, so kannst du auf diese Art z.B. via RMI (oder auch anders) ganze Objektbäume über ein Netz verteilen.
Noch schlimmer, du könntest auch angeben wo er die Klasse nachladen soll, und dann erst die konkreten Ausprägungen rüberschieben und materialiseren.
Dass das C++ auch geht ist klar, nur danach sieht man danach aus.

In der Praxis ist allerdings das persistieren von ganz objektbäumen in form serialisierter objekte auch etwas aus der Mode gekommen. man speichert eher in Datenbanken entspr. Daten und lässt die Object dort beim lesen wiederherstellen.

Im Prinzip ist die oben beschriebene Art der Persistierung einfach genial.
so sind viele Objekte serialisierbar, so z.B. ganze Fenster inklusive Inhalt.
Klar, dass kann man auch alles parametrisiert ablegen, eine Art Record/Struct für das Fenster, der beim eneuten Anlegen angezogen wird, aber mal eben einen Fenster wegspeichern, einfach so, hat ja auch einen gewissen Charme.

Gruss Frank