hardware ansprechen ?

[Neral]

warum kann java eigentlich keine hardware ansprechen ? also koennen sich da die leute von sun nicht was ausdenken ? dann waere java doch unschlagbar

 

[sigma]

da java platform unabhängig ist is dies sehr schwer. (java lässt ja alles über die runtime environment laufen.) wenn du die hardware ansprechen willst machst du am besten mit C, C++, Bash oder was auch immer ein Programm, das die Daten die du über die Hardware brauchst ausliest bzw. die Hardware steuert. Wenn du diest gemacht hasst, kannst du den Code als Nativecode einbinden. Natürlich ist dies nicht mehr platformunabhängig.

gruss sigma

 

[AlArenal]

Mit ner bash die Hardware ansprechen? Wie geht denn das? :lol:

Also soweit mir bekannt ist, kommt man in einem Unix-System auch nicht mal einfach so an die Hardware ran. Und schonmal gar nicht mit Shellskript..

 

[Tommi Necker]

Hallo,
Du solltest Dir mal das Thema "Native Methoden" anschauen. Ich selbst hab mal an nem Projekt gearbeitet, wo ich auf verschiedene Hardwaretreiber zugreifen musste. Unter Windows funktioniert es gut, mit Unix hab ich keine Erfahrung.
Abhängig von dem, was Du machen willst, must Du eventuell einen eigenen EventHandler schreiben, der die Rückgabewerte entgegen nimmt. Und schau Dir das Thema Hexzahlen an!

Viel Glück

 

[Roar]

warum kann java eigentlich keine hardware ansprechen ? also koennen sich da die leute von sun nicht was ausdenken ? dann waere java doch unschlagbar

sagt mal, könnte man da sdenn nicht in die vm integrieren? und die vm holt dann die entsprechende soundkarte oder usb port raus oder so

 

[AlArenal]

sagt mal, könnte man da sdenn nicht in die vm integrieren? und die vm holt dann die entsprechende soundkarte oder usb port raus oder so

Warum setzen wir uns nicht zusammen und überlegen uns ne tolle Erfindung? Ich hab da schon eine Idee für etwas, das ich mal einfach "Rad" genannt habe...

Andererseits wäre schon viel gerettet, wenn der eine oder andere sich mal selbst trauen würde eine Suchmaschine zu bedienen. Dann findet man vielleicht fertige USB- und Sound-Klassen...

 

[tomkruse]

Hi!

Man kann mit Java sehrwohl - zumindest indirekt - auf alles zugreifen, worauf man zugreifen will. Das ganze geht mittels JNI und einer DLL-Datei, die Funktionen enthält, die z.B. in C++, Visual Basic etc. geschrieben wurden. Ich habe sowas mal gemacht, um Fenstertitel auszulesen. Ist aber ziemlich aufwändig und man büsst dabei die Plattformunabhängigkeit (die größte Stärke von Java) ein.

Cu - Tom.

 

[juppi]

Hallo,



Was steht in so einer DLL (oder meinetwegen einem anderen ausführbaren Programm), das für mich den Desktop per SystemParametersInfo() manipuliert?
Ich möchte den Dektop von windows nach unten schieben, um oben einenf festen Platz für meine Applikation zu haben.

Ich habe hier Info zur passenden WinApi-Funktion, weiß aber jetzt nicht mehr weiter.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/w98ddk/hh/w98ddk/multimon_0ay7.asp

Wie spreche ich diese Funktion genau an?

wie sieht denn von c++ aus der Code genau aus, der SPI anspricht? Ich sehe immer nur die Definition mit Platzhaltern für zu übergebende Werte.
Ich kann mir aber den übergebenen Parameter nicht recht vorstellen. Ich muß der WinApi doch bestimmte Werte mitteilen.

Ich stelle mir den Aufruf in etwa vor, als würde ich (ähnlich wie in der Shell und in Shell-skripten) diesen in die DOS-Box hineinrufen. Ist das in etwa so? Oder ganz daneben und völlig anders?
So könnte ich mir den Transfer nach JNI in etwa vorstellen.


Danke für Hilfe oder Hinweise wo ich mich schlauer machen kann oder wo es Codebeispiele daür geben könnte.

(C++ kompilieren etc, bekomme ich auch noch hin. ...)

Schönen Gruß,
Juppi[/url]

 

[L-ectron-X]

Da die VM das Bindeglied zwischen Java und OS darstellt, neige ich dazu der Meinung von Roar zuzustimmen.
Irgendeinen Grund muss es aber haben, warum die Leute von Sun so etwas noch nicht in der VM implementiert haben. ???:L

 

[Roar]

aber es sollte doch auf allen betriebssystemen die möglichkeit geben auf hardware daten zuzugreifen z.B. RAM oder so. und wenn die VM die daten nicht bekommen kann wird halt ne exception geworfen. :? also ich finds schade dass die sowas noch nicht eingefügt haben.

 

[Grizzly]

Die Frage ist ja wohl eher: Gibt es einen überhaupt einen Grund mit Java direkt die Hardware ansprechen zu wollen?

Um bspw. Sound auszugeben, kann ich ja das Java Media Framework benutzen. Und den Drucker brauch ich ja auch nicht direkt über die parallele Schnittstelle ansprechen. Dafür hat Java ja extra Klasse zum Drucken. Vor allem wäre es schon deswegen Nonsens, da der Drucker ja auch ein Netzwerkdrucker sein könnte.
Das Ansprechen der seriellen Schnittstelle wird - außer bei medizinischen Meßgeräten & Co. - auch meistens nicht benötigt.

Und für die wenigen Spezialfälle, in denen man doch etwas direkt ansprechen muss, hat man ja noch die Möglichkeit native Bibliotheken per JNI einzubinden.



P.S.: Für das Ansprechen von seriellen und parallelen Schnittstellen gibt es für Windows und Solaris bspw. von Sun das Java Communications API.

 

[L-ectron-X]

Und für die wenigen Spezialfälle, in denen man doch etwas direkt ansprechen muss, hat man ja noch die Möglichkeit native Bibliotheken per JNI einzubinden.

Klar, geht das. Aber es geht die plattformunabhängigkeit verloren, wenn man z.B. unter Windows dll-Dateien einbinden muss.

P.S.: Für das Ansprechen von seriellen und parallelen Schnittstellen gibt es für Windows und Solaris bspw. von Sun das Java Communications API.

Auch richtig. Hast Du aber mal versucht, damit einzelne Pins am parallelen Anschluss anzusprechen?
Auch hier brauchst Du z.B. unter Windows einen Treiber, der als dll-Datei vorliegt... :roll:

 

[Reality]

Ist es nicht ein großer Schwachsinn, wenn man ein C++-Programm programmiert und diesen dann mit Java anspricht?
Da kann man grad alles in C++ machen! Wozu dann noch Java?

Übrigens kann man in C/C++ auch plattformunabhängig programmieren.
Man benutzt einfach Ansi C/C++ und beispielsweise GTK+ oder QT o.ä.

Liebe Grüße
Reality

 

[Grizzly]

Und für die wenigen Spezialfälle, in denen man doch etwas direkt ansprechen muss, hat man ja noch die Möglichkeit native Bibliotheken per JNI einzubinden.

Klar, geht das. Aber es geht die plattformunabhängigkeit verloren, wenn man z.B. unter Windows dll-Dateien einbinden muss.

Ja, aber geht nicht immer die Plattformunabhängigkeit verloren, wenn ich Hardware direkt anspreche? :? Oder hab' ich den Thread falsch verstanden und ihr wollt eine plattformunabhängige Möglichkeit in Java um Hardware anzusprechen?

P.S.: Für das Ansprechen von seriellen und parallelen Schnittstellen gibt es für Windows und Solaris bspw. von Sun das Java Communications API.

Auch richtig. Hast Du aber mal versucht, damit einzelne Pins am parallelen Anschluss anzusprechen?
Auch hier brauchst Du z.B. unter Windows einen Treiber, der als dll-Datei vorliegt... :roll:

Stimmt, mit der API kann man nur eine Datenübertragung über den entsprechenden Port durchführen. Einzelne Pins für bspw. wissenschaftliche Zwecke geht nicht. Aber das ist dann wirklich ein Spezialfall. Unter DOS mit Assembler würde ich das noch hinbekommen, doch bspw. unter Windows wüsste ich gar nicht, wie man das hinbekommt. Vielleicht mit irgendwelche tieferen API aufrufen...? 99% der Programme brauchen aber so einen Zugriff gar nicht. Denn meisten reichen Zugriff auf den Window Manager (sprich die graphische Oberfläche inkl. Tastatur und Maus), auf die Soundkarte (sprich Sound-Eingang [Mikro & Line-In] und Sound-Ausgang), auf Drucker (lokal oder im Netz), auf das Netzwerk per TCP/IP, auf Datenbanken und schließlich auf Dateien.

 

[Grizzly]

Ist es nicht ein großer Schwachsinn, wenn man ein C++-Programm programmiert und diesen dann mit Java anspricht?
Da kann man grad alles in C++ machen! Wozu dann noch Java?

Übrigens kann man in C/C++ auch plattformunabhängig programmieren.
Man benutzt einfach Ansi C/C++ und beispielsweise GTK+ oder QT o.ä.

Liebe Grüße
Reality

In vielen Fällen braucht man auch keine Zusatzbibliotheken. Und C/C++ Programme müssen dann immer noch auf bzw. für das jeweiligen System kompiliert werden, Java Programme können so verteilt werden.

 

[Roar]

Und für die wenigen Spezialfälle, in denen man doch etwas direkt ansprechen muss, hat man ja noch die Möglichkeit native Bibliotheken per JNI einzubinden.

Klar, geht das. Aber es geht die plattformunabhängigkeit verloren, wenn man z.B. unter Windows dll-Dateien einbinden muss.

Ja, aber geht nicht immer die Plattformunabhängigkeit verloren, wenn ich Hardware direkt anspreche? :? Oder hab' ich den Thread falsch verstanden und ihr wollt eine plattformunabhängige Möglichkeit in Java um Hardware anzusprechen?

ja wir wollen dass solche standart funktionen wie cd laufwerke, und andere hardware devieces direkt ansprechen in der J2SE haben. diese möglichkeiten bietet jedes betriebssystem, und wenn nicht dann kommt halt ne Exception.

 

[stev.glasow]

Ist es nicht ein großer Schwachsinn, wenn man ein C++-Programm programmiert und diesen dann mit Java anspricht?
Da kann man grad alles in C++ machen! Wozu dann noch Java?

Übrigens kann man in C/C++ auch plattformunabhängig programmieren.
Man benutzt einfach Ansi C/C++ und beispielsweise GTK+ oder QT o.ä.

Liebe Grüße
Reality

In vielen Fällen braucht man auch keine Zusatzbibliotheken. Und C/C++ Programme müssen dann immer noch auf bzw. für das jeweiligen System kompiliert werden, Java Programme können so verteilt werden.

Jetzt geht das schon wieder los :autsch:

 

[Reality]

In vielen Fällen braucht man auch keine Zusatzbibliotheken. Und C/C++ Programme müssen dann immer noch auf bzw. für das jeweiligen System kompiliert werden, Java Programme können so verteilt werden.

Klar, ist aber nicht gerade ein großer Aufwand. Dafür hat man eben die Vorteile, die C und C++ bieten.
Z.B. wenig Resourcen und Geschwindigkeit.

Kommt mir bitte nicht, mit irgendwelchen "Benchmarks", wo Java C++ schlägt. Das kommt
1. auf die Programmierung drauf an
2. auf den Compiler


Liebe Grüße
Reality

 

[L-ectron-X]

Niemanden interessiert hier ein Vergleich zwischen Java und was weiß ich welcher Programmiersprache.
Roar hat's wieder mal auf'n Punkt gebracht.

 

[stev.glasow]

Es ist doch immer das gleiche ... :roll:
(sorry das muss jetzt aber mal sein)

 

[Grizzly]

In vielen Fällen braucht man auch keine Zusatzbibliotheken. Und C/C++ Programme müssen dann immer noch auf bzw. für das jeweiligen System kompiliert werden, Java Programme können so verteilt werden.

Klar, ist aber nicht gerade ein großer Aufwand. Dafür hat man eben die Vorteile, die C und C++ bieten.
Z.B. wenig Resourcen und Geschwindigkeit.

Kommt mir bitte nicht, mit irgendwelchen "Benchmarks", wo Java C++ schlägt. Das kommt
1. auf die Programmierung drauf an
2. auf den Compiler


Liebe Grüße
Reality

Es ging mir ja auch nicht darum hier einen Flamewar C/C++ vs. Java loszubrechen . Ist ja auch eigentlich Nonsens. Java ist ja in C/C++ geschrieben und läuft meist bis fast immer auf Systemen die mit C/C++ geschrieben wurden.

Der Knackpunkt an der Sache ist ja der, dass Java plattformunabhängig sein soll. Und bspw. gibt es eine serielle Schnittstelle nicht an einem PDA (oder zumindest auf den meisten nicht). Aber über einen PDA kann man per Infrarot über einen entsprechenden Drucker mit Infrarot drucken genauso wie man an einem Desktop Rechner auch drucken kann.
Wenn man natürlich einen TCP/IP Stack für seine parallele Schnittstelle in Windows implementieren will, ist man mit Java bestimmt an der falschen Adresse. :wink:

 

[foskaty]

Ist es nicht ein großer Schwachsinn, wenn man ein C++-Programm programmiert und diesen dann mit Java anspricht? Da kann man grad alles in C++ machen! Wozu dann noch Java?

Übrigens kann man in C/C++ auch plattformunabhängig programmieren.
Man benutzt einfach Ansi C/C++ und beispielsweise GTK+ oder QT o.ä.

Einige Anmerkungen dazu:

Irgendwann und irgendwo gibt es Leute, die es der Java-Programmiergemeinde ermöglichen, auf allen möglichen und unmöglichen Systemen auf das jeweilige Dateisystem, auf die Soundkarte, auf den Drucker und was weiß ich noch alles zuzugreifen. D.h. es gibt Leute, die den "Unterbau" der Java-Portabilität erstellen und nach "oben", d.h. in die VM hinein, ein und dasselbe Interface allüberall anbieten. DIESE Menschen brauchen das Java Native Interface, um aus der VM-Welt mal eben "nach Hause" zu telefonieren. Es ist fast wie bei Neo in seiner MATRIX: Irgendwo ist die Hardware, auch wenn wir uns virtuell bewegen, letztendlich ist da irgendwo dasjenige System, die CPU, die auch Java benötigt, um zu laufen... "Ich brauche ein Telefon!"

Sicher kann ich auch portabel in C und C++ programmieren (aber Achtung: Es gibt hier schattige Bereiche, die sind alles andere als portabel), aber ein übersetztes C-Programm ist eben nicht "mobil", ist kein "mobile code", d.h. ich kann meine Java-Applikation in übersetzem Zustand auf einen Server packen und dann - wo immer ich bin, was immer ich auch für ein System unterm Bytecode-Interpreter habe - vor Ort ohne weiteres ausführen! Das geht so mit C und C++ nicht! Ich kann mein x86-Office, selbst wenn es mit Qt gebunden ist, nicht einfach auf einem PowerPC-basierten Mac schaufeln und dann damit arbeiten. (Dafür gibt es VMware, VirtualPC & Co.)

Es gibt zudem interessante Artikel, die belegen, daß man selbst als C++-Programmierer von Java profitiert, in dem man nämlich über Projekte wie den GNU Java-Native-Compiler (GCJ) Zugriff auf die GUI-Bibliotheken von Java bekommt und dies ausnutzt, um diesen systemabhängigen Teil von den auf Portabilität getrimmten Java-APIs erledigen läßt. Das heißt, hier haben wir den umgekehrten Weg, der ebenfalls (!) nichts mit Schwachsinn zu tun hat, es handelt sich in beiden Fällen um ganz normale, im Falle von JNI zeitweise sogar zwingend erforderliche Methoden, um Probleme zu lösen.

Fazit: Irgendwo ist der Preis und die Arbeit versteckt, die geleistet werden muß, damit der Java-Programmierer portabel coden kann. Es hängt von der Zielsetzung des jeweiligen Projekts ab, ob ich C++ und/oder Java in dem einen oder anderen Umfange zur Implementierung nutze.