Festplattengröße, CPU Usage unter Java 1.5

[Xin]

Moin!

Nach vielen Jahren Java-Abstinenz hat man mich nun wieder auf Java losgelassen und bin nun auf der Suche nach einer möglichst eleganten Lösung die einzelnen Laufwerke, sowie deren Größe und Belegung zu erfragen.
Des weiteren muss ich die CPU Auslastung eines Rechners bestimmen.

Ich habe gesehen, dass zumindest Java 1.6 einfache Funktionen für die Datenträgerbestimmung unter java.io.File anbietet und finde bei Google auch immer wieder die Hinweise auf die 1.6er Funktionen.
Leider bin ich noch auf 1.5 angewiesen und kann sie daher nicht nutzen.

Wie kommt man an diese Informationen in Java 1.5?

Vielen Dank

 

[tuxedo]

Vielleicht hilft dir das hier zur Größe und Belegung weiter:
http://jgoodies.com/freeware/jdiskreport/index.html

CPU-Last ... fällt mir gerade nix Hauseigenes dazu ein. Wie häufig brauchst du denn da eine Aktualisierung des Wertes?

 

[Xin]

Vielleicht hilft dir das hier zur Größe und Belegung weiter:
http://jgoodies.com/freeware/jdiskreport/index.html

Das Programm ackert rekursiv Verzeichnisse durch, ich brauche lediglich die Information 'Es gibt eine Festplatte, die heißt "C:\" oder "/home", die ist 500G groß und davon sind 250G belegt.
Cool wäre auch, wenn man S.M.A.R.T. Warnungen erhalten könnte, aber das ist nichtmals notwendig.

CPU-Last ... fällt mir gerade nix Hauseigenes dazu ein. Wie häufig brauchst du denn da eine Aktualisierung des Wertes?

Nicht häufig. Da die Abfrage über's Netz kommt, wären das im Extremfall 10 Abfragen pro Sekunde. Vorraussichtlich wird eine Abfrage nicht häufiger als 1/s kommen.
Die Abfragen kommen also nicht regelmäßig. Man muss aus ihnen letztendlich auch nur ablesen können, ob der Rechner im Dauerstreß ist, eine perfekte Statistik ist nicht erforderlich.

 

[tuxedo]

Naja, zur Größe und Belegung kannst du sowas hier machen:

File[] f = File.listRoots();
		for (File file : f) {
			System.out.println("Device: "+file.getAbsoluteFile());
			System.out.println("Total Space: "+file.getTotalSpace());
			System.out.println("Usable Space: "+file.getUsableSpace());
			System.out.println();
		}

Ergibt bei mir:

Device: A:\
Total Space: 0
Usable Space: 0

Device: C:\
Total Space: 36701163520
Usable Space: 12558487552

Device: D:\
Total Space: 43322548224
Usable Space: 40090583040

Device: E:\
Total Space: 0
Usable Space: 0

Device: F:\
Total Space: 80023715840
Usable Space: 57766584320

ZUr CPU-Last: Einfach mal google befragen. Hab als erstes das hier gefunden: http://www.javaworld.com/javaworld/javaqa/2002-11/01-qa-1108-cpu.html

- Alex

 

[Xin]

Naja, zur Größe und Belegung kannst du sowas hier machen:

File[] f = File.listRoots();
		for (File file : f) {
			System.out.println("Device: "+file.getAbsoluteFile());
			System.out.println("Total Space: "+file.getTotalSpace());
			System.out.println("Usable Space: "+file.getUsableSpace());
			System.out.println();
		}

Ergibt bei mir:

...

Und bei mir 'method getTotalSpace() is undefined for the type File' und 'method getUsableSpace() is undefined for the type File', weil - wie ich ja bereits schrieb - Java 1.5 und nicht 1.6. Java 1.5 ist Vorgabe und darum suche ich Lösung, die für 1.5 gilt.

ZUr CPU-Last: Einfach mal google befragen. Hab als erstes das hier gefunden: http://www.javaworld.com/javaworld/javaqa/2002-11/01-qa-1108-cpu.html

But, this approach is fragile at best

Der Rest ist die Empfehlung C/C++ zu benutzen.

Der Artikel ist über 5 Jahre alt. Ich hoffe eigentlich, dass sich da in der Zwischenzeit was getan hat.
Ich habe seinerzeit Java gelernt und an den Nagel gehängt, weil wenn ich eh alle Fragen plattformspezifisch mit C/C++ stellen muss, dann kann ich mir Java auch schenken.

Edit: Trotzdem danke für den C/C++ Artikel, im Notfall hilft er mir weiter, die Sache mit C/C++ zu lösen.

 

[tuxedo]

Naja, Java läuft nunmal in einer virtuellen Maschine. Die CPU-Last liegt da "ausserhalb". In den vergangenen 5 Jahren hat sich schon extrem viel getan. Aber die Abfrage der CPU-Last ist leider noch nicht in die aktuelle JRE rein gewandert.

Mit den zwei Methoden ... Ja, kann sein dass die in der Tat aus Java 6 sind. Ich check das mal eben.

- Alex

[update]

Sieht schlecht aus: http://forum.java.sun.com/thread.jspa?threadID=5202181&messageID=9805599

Ist halt auch doof dass du an 1.5 gebunden bist. Das hat ja auch schon ein paar Jahre auf dem Buckel (Herbst 2004 wenn ihc mich recht entsinne).

 

[Xin]

Sieht schlecht aus: http://forum.java.sun.com/thread.jspa?threadID=5202181&messageID=9805599

Ist halt auch doof dass du an 1.5 gebunden bist. Das hat ja auch schon ein paar Jahre auf dem Buckel (Herbst 2004 wenn ihc mich recht entsinne).

Naja, ich sage mal "Geht nicht" habe ich schon selbst gefunden. ^^
Ich suche eher Leute, die sagen "Geht so, die Leute, die 'Geht nicht' sagen, wissen es nicht besser."

Denn auch bei Java 1.0 waren Festplattenlaufwerke in Computern eher Regel als Ausnahme und die Frage, welche Laufwerke gibt es und wie voll sind sie, ist nichts, was nicht plattformunabhängig gelöst werden kann.

Trotzdem danke, sollte noch jemand einen Tipp haben, ich wäre dankbar.

 

[tuxedo]

Naja, mir scheint du hast das Sandbox Prinzip nicht verstanden. Dass Java6 jetzt die Größe auslesen kann liegt daran, dass die JVM das jetzt unterstützt und selbst das OS frägt "wieviel platz ist noch".

Irgendeine "Schnittstelle" runter zur Hardware brauchst du ja, ob Windows oder Linux. Und wenn's die VM (noch) nicht kann, dann musst du über nativen Code (JNI) gehen oder doch reines C/C++ nehmen.

In Java 6 ist die VM diesbezüglich schon "schlauer". Warum die Abfrage der CPU-Zeit noch nicht dirn ist weiß ich nicht. Aber man kann ja nicht sagen:

"Java hat sich seit 5 Jahren nicht gebessert", wenn man nur eine etwa 3 1/2 Jahre alte VM benutzen kann.

Wenn due Jungs im SUN-Forum (ja, Java ist von SUN), es nicht besser wissen, dann wirst du wohl niemanden finden.

Wenn du JNI nicht magst, dann schau dir mal JNA (jna.dev.java.net) an. Da kannst du native Methoden aufrufen ohne C/C++ coden zu müssen. Wenn dein OS also eine solche Funktion über irgendeine Lib zur Verfügung stellt, dann kannst du sie mit JNA benutzen (bei JNI muss man ja immer erst in C einen Wrapper dafür schreiben, das fällt mit JNA weg).

- Alex

 

[ms]

Mir stellt sich die Frage ob für den Fall der CPU-Last Java wirklich die erste Wahl ist.
Die JVM garantiert ja nicht, dass Threads regelmäßig ausgeführt werden.
Wenn die Maschine also unter Last ist kann es doch sein, dass die CPU-Informationen nicht gesendet werden.
Ich hab momentan so ein ähnliches Problem und versuche daher eine sehr leichtgewichtige Lösung zu finden.
Bin mir aber nicht sicher ob ich mit meiner Annahme wirklich richtig liege.

ms

 

[Xin]

Naja, mir scheint du hast das Sandbox Prinzip nicht verstanden. Dass Java6 jetzt die Größe auslesen kann liegt daran, dass die JVM das jetzt unterstützt und selbst das OS frägt "wieviel platz ist noch".

Ich denke schon, das Sandbox-Prinzip verstanden zu haben, aus diesem Grund hätte ich es ja auch gerne benutzt, statt plattformabhängiges zu verwenden.

Wenn ich eine Frage stelle, die Plattformabhängig ist, zum Beispiel die Version einer externen Library wie GTK, dann kann ich verstehen, dass Java mit das nicht beantwortet. Datenträger und Dateisysteme haben aber auf allen Plattformen große Ähnlichkeiten, sonst wäre java.io.File nicht möglich.
Da habe ich auch kein Problem, das zu offen zu bemängeln, unabhängig ob irgendwer glaubt, dass ich das Sandbox Prinzip verstehe oder nicht.

Mir stellt sich die Frage ob für den Fall der CPU-Last Java wirklich die erste Wahl ist.
Die JVM garantiert ja nicht, dass Threads regelmäßig ausgeführt werden.

Ich möchte das auch nicht selbst ausrechnen, ich möchte Java ja nur fragen, wie es grade aussieht. Als würde ich den Taskmanager aufmachen und gucken, was der mir grade sagt. Nur muss ich den Wert über's Netz schicken.

 

[Wildcard]

Das Programm ackert rekursiv Verzeichnisse durch, ich brauche lediglich die Information 'Es gibt eine Festplatte, die heißt "C:\" oder "/home", die ist 500G groß und davon sind 250G belegt.

Weder gibt es eine Festplatte C:\, noch /home. Du sprichst von Partitionen, bzw. einem Mountpoint.

 

[ms]

Ich möchte das auch nicht selbst ausrechnen, ich möchte Java ja nur fragen, wie es grade aussieht. Als würde ich den Taskmanager aufmachen und gucken, was der mir grade sagt. Nur muss ich den Wert über's Netz schicken.

Nur die Antwort senden kostet auch Ressourcen, wenn auch sehr sehr wenig.
Wie gesagt besteht keine Garantie, dass regelmäßig gesendet wird.

ms

 

[Xin]

Das Programm ackert rekursiv Verzeichnisse durch, ich brauche lediglich die Information 'Es gibt eine Festplatte, die heißt "C:\" oder "/home", die ist 500G groß und davon sind 250G belegt.

Weder gibt es eine Festplatte C:\, noch /home. Du sprichst von Partitionen, bzw. einem Mountpoint.

Das ist vollkommen richtig, doch ich bin sicher, dass mein Anliegen trotz dieser kleinen Ungenauigkeit verständlich ist. Zu einer Lösung verhilft Dein Einwand leider nicht.

Ich möchte das auch nicht selbst ausrechnen, ich möchte Java ja nur fragen, wie es grade aussieht. Als würde ich den Taskmanager aufmachen und gucken, was der mir grade sagt. Nur muss ich den Wert über's Netz schicken.

Nur die Antwort senden kostet auch Ressourcen, wenn auch sehr sehr wenig.
Wie gesagt besteht keine Garantie, dass regelmäßig gesendet wird.

Das Problem ist nicht wie oft etwas gesendet wird, weil wie oft gesendet wird, bestimme ich. Das Problem ist, dass ich nichts zu senden habe, weil ich nicht an die Informationen herankomme, die ich senden muss. Meine Frage lautet entsprichend nicht, wie ich regelmäßig sende, sondern wie ich möglichst elegant eine Momentaufnahme des aktuellen Zustands erhalte, den ich versenden könnte. Auch interessiert mich nur, ob der Rechner stark ausgelastet ist (regelmäßig >80%) oder nur vor sich dahindümpelt (<10%) oder normal benutzt wird (10-80%). Ob da mal eine Message gesendet und wieviel Resourcen das Versenden einer Message wird spielt bei den Kisten überhaupt keine Rolle. Weder in der Problemstellung noch von der Leistungsfähigkeit der Rechner.

Und die einzige Antwort darauf lautet bisher Funktionen aus Java 1.6 zu benutzen - also eine Lösung, die ich direkt mit der Frage ausgeschlossen habe, weil es der Vorgabe widerspricht und damit erst die Frage aufwirft.

Ich möchte nicht unhöflich oder undankbar klingen, aber dieser Thread behandelt die halbe Historie von Java, nur der interessanten Part - nämlich die Fragestellung - wird irgendwie kunstvoll umgangen. Es muss doch 2004 schon in Java möglich gewesen sein, grundlegende Informationen des Systems plattformunabhängig auszulesen.

 

[maki]

Und die einzige Antwort darauf lautet bisher Funktionen aus Java 1.6 zu benutzen - also eine Lösung, die ich direkt mit der Frage ausgeschlossen habe, weil es der Vorgabe widerspricht und damit erst die Frage aufwirft.

Naja, die zweite dir genannte Alternative, nämlich JNI, vergisst du

Klar ist diese Möglichkeit weder sonderlich elegant noch Plattformunabhängig, aber mir fällt dazu keine Alternative mehr ein.

Falls du doch noch was finden solltest, lass es uns auf jedenfall wissen.

 

[tuxedo]

Ganz zu schweigen von JNA ... ;-)

 

[lhein]

Ist halt auch doof dass du an 1.5 gebunden bist. Das hat ja auch schon ein paar Jahre auf dem Buckel (Herbst 2004 wenn ihc mich recht entsinne).

Ich muss mir grad ein wenig das Schmunzeln verkneifen.
Im Prinzip versteh ich diese Äußerung und empfinde es auch als schade, daß man bessere Mittel zur Wahl hat, aber auf ältere Sachen beschränkt ist. Fakt ist aber, daß in einem nicht unerheblichen Teil der Firmen es eben so ist, daß man nach wie vor auf 1.4 setzt und eben nicht upgraden möchte. Es soll sogar noch 1.3 Nutzer geben.
Somit ist Xin ja fast noch gut dran, daß er bereits 1.5 nutzen kann

lr

 

[tuxedo]

Da ja "Speicher" nicht mehr die Welt kostet, versteht ich's jdoch nicht warum man nicht für Anwendung A Java 1.3 nutzt, Anwenudng B mit Java 1.5 laufen lässt, und die neue Anwendung C dann mit Java 6 läuft...

Okay, sollen A, B unc C "ein" Projekt" sein, wirds halt schwierig.

- Alex

 

[lhein]

Weil es in diesen Firmen sicherheitstechnische Bedenken in Bezug auf Java >= 1.5 gibt

lr

 

[tuxedo]

ah ja... okay. Dazu fällt mir dann auch nix mehr ein.

Naja, es gibt allerdings auch genug Firmen die in Sicherheitstechnischen Anwendungen java 6 einsetzen....

Naja, jedem das seine. SUN selbst rät ja dazu die Nutzung von Java 5 so langsam aber sicher einzustellen (find den Link gerade nicht).
Persönlich finde ich es etwas "verantwortungslos" eine Anwendung für Java 1.3 weiter zu pflegen bzw. nicht zu portieren. Ich finde da hat dann jemand gewaltig den Zug verpasst... (meine persönliche Meinung).

- Alex

 

[lhein]

Wie gesagt, ich teile Deine Meinung ja im großen und ganzen.
Btw. es gibt auch noch andere Java-Bereitsteller neben Sun, die auch gar nicht so schnell sind beim Release neuer Versionen...siehe IBM z.B.

 

[Xin]

Ganz zu schweigen von JNA ... ;-)

Elegant und innerhalb des Sandkastens, also portabel, war die Frage. Weder JNI, noch JNA sind Antworten auf die Frage.

Java ist aber offensichtlich auch nicht die Antwort und hat auch keine zu bieten.
Die Antwort wurde entsprechend weder elegant, noch portabel. Ich habe es mit JNI über die WinAPI umgesetzt. Spaßig wird's erst, wenn die Anforderung kommt, das ganze auf 3 weitere OS zu bringen.
Ich hoffe, dass es vorher das "Go" für 1.6 gibt, was mich allerdings von JNI auch nicht befreien wird.

 

[tuxedo]

JNI und JNA sind die einzigen Antworten auf die Frage. Mal ganz zu schweigen davon, dass ich bereits erklärt hab, dass die JVM das von Haus aus nicht vom OS nicht in den Sandkasten mapped.

SWT gibts im übrigen auch für unterschiedliche Plattformen. Da schreit auch kein Hahn danach. Und wenn's nur um so "primitive" Dinge wie CPU-Last und kapazitive Auslastung der Festplatte geht, dann sollte das doch in kurzer Zeit erledigt sein....Auch für mehrere Plattformen.

BTW: Hast du mal geschaut ob's für sowas überhaupt schon einen Request gibt dass das in die JVM aufgenommen wird? Weil wenn's keiner (oder nur extrem wenige) braucht/brauchen: Wieso sollte man's dann aufnehmen?