# Festplattengröße, CPU Usage unter Java 1.5



## Xin (18. Jan 2008)

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 (18. Jan 2008)

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 (18. Jan 2008)

alex0801 hat gesagt.:
			
		

> 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.



			
				alex0801 hat gesagt.:
			
		

> 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 (18. Jan 2008)

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
> 
> ...



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 (18. Jan 2008)

alex0801 hat gesagt.:
			
		

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



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.



			
				alex0801 hat gesagt.:
			
		

> 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





			
				01-qa-1108-cpu.html hat gesagt.:
			
		

> 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 (18. Jan 2008)

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 (18. Jan 2008)

alex0801 hat gesagt.:
			
		

> 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 (18. Jan 2008)

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 (18. Jan 2008)

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 (18. Jan 2008)

alex0801 hat gesagt.:
			
		

> 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.



			
				ms hat gesagt.:
			
		

> 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 (18. Jan 2008)

Xin hat gesagt.:
			
		

> 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 (19. Jan 2008)

Xin hat gesagt.:
			
		

> 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 (20. Jan 2008)

Wildcard hat gesagt.:
			
		

> Xin hat gesagt.:
> 
> 
> 
> ...


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.



			
				ms hat gesagt.:
			
		

> Xin hat gesagt.:
> 
> 
> 
> ...


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 (20. Jan 2008)

> 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 (22. Jan 2008)

Ganz zu schweigen von JNA ... ;-)


----------



## lhein (22. Jan 2008)

alex0801 hat gesagt.:
			
		

> 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 (22. Jan 2008)

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 (22. Jan 2008)

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

lr


----------



## tuxedo (22. Jan 2008)

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 (22. Jan 2008)

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 (22. Jan 2008)

alex0801 hat gesagt.:
			
		

> 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 (22. Jan 2008)

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?


----------

