Klasse die in C geschrieben wurde in Java verwenden?

[Novanic]

Hi Leute,

ich würde gerne eine Klasse (Daten-Container) performanter arbeiten lassen. Ich denke die Klasse würde schneller laufen, wenn sie in C geschrieben wäre. Es sollte kein Problem sein die Klasse nach C zu übersetzen, aber ist es auch möglich eine in C geschriebene, kompilierte Klasse in Java zu nutzen und würde das mehr Performance bringen?

Gibt es ansonsten noch eine Möglichkeit eine Klasse eigentlich nur die Aufgabe hat mit Arrays umzugehen etwas performanter zu machen?

Vielen Dank im Voraus!

Gruß Nova

 

[lin]

schau dir mals das JavaNativeInterface JNI an
http://java.sun.com/j2se/1.4.2/docs/guide/jni/index.html
obs performanter ist weiss ich net... musste halt ausprobieren

Gibt es ansonsten noch eine Möglichkeit eine Klasse eigentlich nur die Aufgabe hat mit Arrays umzugehen etwas performanter zu machen?

dazu müsstest du schon code zeigen, damit wir berurteilen können, wo du noch etwas optimieren könntest...

 

[Roar]

hm..
1. gibs in c gar keine klassen und
2. warum sollte das schneller sein? der java code ist auch nich langsamer als dasselbe in c. du wirst eher geschwindigkeitsverlust haben, wegen den jni aufrufen, es sei denn dein java code is sehr großer pfusch

 

[Sky]

Was verstehst Du unter einem "Daten-Container" ?

Wenn das eine Klasse mit Variablen, setter- und getter-Methoden sein soll, so würde ich gerne mal wissen, wieso das in C schneller sein soll ???????????

 

[Novanic]

Naja, C/C++ ist ja grundsätzlich schneller als Java, da es richtig kompiliert wird und nicht interpretiert werden muss.

Aber wenn ich fertig kompilierte C++ Klassen in Java benutzen möchte (falls es überhaupt möglich ist), werden diese wohl auch genau so lahm wie Java-Klassen ausgeführt, da Java da wohl auch mit rumpfuschen würde. ;-)

Und die Klasse als lauffähiges Programm zu kompilieren und mit Parametern oder ähnlichem zu arbeiten, wäre wohl auch sehr unsauber und nicht performanter.

Mein Container arbeitet sehr ähnlich wie eine Collection (hält ein Object-Array).

Aber trotzdem danke für eure Hilfe.

Gruß Nova

 

[AlArenal]

Naja, C/C++ ist ja grundsätzlich schneller als Java, da es richtig kompiliert wird und nicht interpretiert werden muss.

Du solltest deinen Kenntnisstand aktualisieren. Alles weitere erübrigt sich bis dahin.

 

[Novanic]

Was? Willst du damit sagen, dass Java mittlerweile schneller als C++ geworden ist? Das glaub ich kaum. *g*
Java ist zwar für Entwickler angenehm, aber extrem lahm und extrem resourcenfressend. Da kann man sich das noch so schön reden. ;-)

Und das mit der Plattformunabhängigkeit ist doch auch total die Lüge oder nicht? Denn Java läuft nur auf Plattformen, für die Sun nicht zu faul war ein JDK zuschreiben...

Ich find Java ja schön und gut, Java ist extrem flexibel, es gibt sehr viel Support und es ist angenehm mit Java zu entwickeln, aber ich denke dass Endergebnis (für die Anwender) sollte im Vordergrund stehen. Und ein Unterschied zwischen Java-Programmen und Programmen die beispielsweise mit C++ programmiert wurden ist für jeden Anwender deutlich spürbar.

Und falls du auf .Net hinaus willst, da wird C++ mittlerweile auch vom .Net-Framework interpretiert, aber selbst dass läuft noch wesentlich performanter als Java.

Sorry, aber musste ich jetzt mal loswerden. ;-) Kannst mich gerne vom Gegenteil überzeugen. ;-)

Gruß Nova

 

[goodvirus]

1. gibs in c gar keine klassen und

Wollt nur kurz einwerfen, das C auch OOP unterstützt.
mfG goodvirus

 

[AlArenal]

Was? Willst du damit sagen, dass Java mittlerweile schneller als C++ geworden ist? Das glaub ich kaum. *g*
Java ist zwar für Entwickler angenehm, aber extrem lahm und extrem resourcenfressend. Da kann man sich das noch so schön reden. ;-)

1. Ich habe nicht behauptet, dass Java schneller als C++ ist. Ich habe der Mär vom aaaach soo laaaaangsaaaamen Java widersprochen. Schau ins Netz und lerne.
2. Time-to-market ist zweifelsohne mit ein Grund für den Erfolg von Java. Mach mal ne Umfrage bei Kunden was ihnen wichtiger ist, 10% schnellere Laufzeit oder 10% weniger Entwicklungszeit und damit auch Entwicklungskosten. Zumal die meisten Anwendungen ihre Zeit imi Leerlauf verbringen.

Und das mit der Plattformunabhängigkeit ist doch auch total die Lüge oder nicht? Denn Java läuft nur auf Plattformen, für die Sun nicht zu faul war ein JDK zuschreiben...

Abgesehen davon, dass die Plattformunabhängigkeit ein deutlich komplexeres Thema ist, mach doch mal ne Liste der Plattformen, für die Java nicht verfügbar ist und rechne mal deren Marktanteile zusammen.

Ich find Java ja schön und gut, Java ist extrem flexibel, es gibt sehr viel Support und es ist angenehm mit Java zu entwickeln, aber ich denke dass Endergebnis (für die Anwender) sollte im Vordergrund stehen. Und ein Unterschied zwischen Java-Programmen und Programmen die beispielsweise mit C++ programmiert wurden ist für jeden Anwender deutlich spürbar.

Vermutlich sprichst du aus eigener Erfahrung und da kann ich nicht gegen argumentieren, da ich ja deine Java- und C++-Anwendungen nicht kenne. Aber vermutlich weißt auch du, dass wenn man nicht schwimmen kann, es in der Regel nicht an der Badehose liegt.
Ich entwickle selbst Desktop-Anwendungen und arbeite damit in einem Bereich, wo man schlechte Anwendungsperformance als allererstes zu spüren bekommt, weil es naturgemäß einfacher ist ne Anwendung auf nen fetteren Server umzuziehen, als die Hardware Dutzender und Hunderter von Clients upzugraden, die in aller Regel nicht eh nicht auf dem Stand der Dinge sind. Dennoch kann ich von keinen Problemen berichten, wobei ich aber auch keine Klimasimulationen entwickle...

Und falls du auf .Net hinaus willst, da wird C++ mittlerweile auch vom .Net-Framework interpretiert, aber selbst dass läuft noch wesentlich performanter als Java.

Sorry, aber musste ich jetzt mal loswerden. ;-) Kannst mich gerne vom Gegenteil überzeugen. ;-)

Überzeugen musst du dich schon selber.

http://www.shudo.net/jit/perf/
http://www.jot.fm/issues/issue_2003_09/column3
http://www.alessandropulvirenti.it/programmazione/

Und vermutlich gibts noch Unmengen weiterer mehr oder weniger synthetischer Benchmarks. Aber auch wenn Kunden und User mitunter sehr penetrant sind, habe ich noch von niemandem eine Performance-Beschwerde bzgl. der Performance einer Java-Anwendung gehört. Beschwerden und Wünsche gehen nahezu immer in Richtung Features und Entwicklungszeit (auch Beschwerdens seitens des Chefs ). Wenn ich nun noch länger bräucht in .NET, um eine Lösung zu entwickeln, eine Komponente im Netz zu finden, ... wie sollte mein Arbeitgeber unseren Kunden verlängerte Entiwcklungszyklen und erhöhte Kosten ohne ein Mehr an Substanz verkaufen?

 

[Roar]

1. gibs in c gar keine klassen und

Wollt nur kurz einwerfen, das Java auch OOP unterstützt.
mfG goodvirus

danke für die info :arrow: :toll:

edit: davon abgesehen:
- java wird nicht interpretiert
- c++ wird nicht interpretiert (erst gar nicht von .net, hat ja nix damit zu tun)
- c# und alle anderen .net sprachen werden auch nicht interpretiert :roll:

edit2:
ansonsten :arrow: AlArenal :idea:

 

[Novanic]

Also mit C# lässt sich auch sehr schnell und komfortabel entwickeln. Und die Sprache mit der man am Schnellsten entwickeln kann ist wohl VB, zwar sehr unschön, aber ich kenne keine Sprache mit der man schneller an ein sehr gutes (performantes, resourcensparendes) Ziel kommt.

In meiner Firma z.B. arbeiten zwei Gruppen an einem sehr sehr ähnlichen Produkt (bietet eigentlich die gleichen Features). Die eine Gruppe besteht nur aus einem einzigen Team und programmiert mit C#, die andere Gruppe (Rest der Firma/etliche Teams) programmieren mit Java und haben ständig Probleme...

Wenn man sich auch mal so im Heimanwenderbereich Java und C++ Programme ansieht, merkt man auch sehr deutlich die Unterschiede.

Z.B. bei BitTorrent-Clients (beide bieten ziemlich die gleiche Features):

BitComet ist mit C++ programmiert braucht ca. 12MB Arbeitsspeicher ud läuft sehr performant.

Azureus ist mit Java programmiert, frisst ganze 130MB Arbeitsspeicher!! und läuft langsamer als BitComet (trotzdem noch erstaunlich schnell für ein Java-Programm).


Aber ich mein wenns nur um die schnelle Entwicklung geht, ist Java ja genau so eine Quick-'n'-Dirty-Sprache wie VB.

Ich finde das Endergebnis sollte immer im Vordergrund stehen, ich find es irgendwie schlampig so unperformante, resourcenfressende Lösungen zu programmieren. Die man einfach mit einer anderen "Basis" wesentlich sauberer/besser machen könnte und nur so schlampig programmiert damit man schneller fertig wird... Das bringt die Welt doch nicht voran... ;-)

Aber das sollte jetzt auch keine Diskussion über All vs. Java werden...

@goodvirus: Natürlich unterstützt Java OOP, C++ und C# auch, aber jetzt lass uns nicht auch noch über unperformante OOP-Konzepte diskutieren. ;-)

@roar: Ich weiß jetzt nicht wodrauf du hinaus willst, natürlich werden Java, C++ und C# nicht interpretiert, sondern die daraus resultierenden Anwendungen?! Wolltest du darauf hinaus?
Ansonsten werden Java-Anwendungen in Bytecode kompiliert und von den Runtimes interpretiert. Sonst bräuchte man ja keine Java-Runtimes... ;-) Und die neuen .Net-Anwendungen brauchen alle das .Net-Framework, um ausgeführt zu werden...

Gruß Nova

 

[AlArenal]

Also mit C# lässt sich auch sehr schnell und komfortabel entwickeln.

Da fehlts aber an Komponenten. Da hat Java im Vergleich den Vorteil länger am Markt zu sein. Die Produkte sind entsprechend länger am Markt und ausgereift. Von den Problemen der .NET Frameworks untereinander mal ganz abgesehen. Wobei das mit den Komponenten auch wieder stark vom Einsatzzweck der Anwendung abhängt.

In meiner Firma z.B. arbeiten zwei Gruppen an einem sehr sehr ähnlichen Produkt (bietet eigentlich die gleichen Features). Die eine Gruppe besteht nur aus einem einzigen Team und programmiert mit C#, die andere Gruppe (Rest der Firma/etliche Teams) programmieren mit Java und haben ständig Probleme...

Ich kann auch keine Aussage über die Skills eurer Java-Progger machen. Ich halte mich für keinen Java-Guru und komme bestens klar.

Wenn man sich auch mal so im Heimanwenderbereich Java und C++ Programme ansieht, merkt man auch sehr deutlich die Unterschiede.

Z.B. bei BitTorrent-Clients (beide bieten ziemlich die gleiche Features):

BitComet ist mit C++ programmiert braucht ca. 12MB Arbeitsspeicher ud läuft sehr performant.

Azureus ist mit Java programmiert, frisst ganze 130MB Arbeitsspeicher!! und läuft langsamer als BitComet (trotzdem noch erstaunlich schnell für ein Java-Programm).

Dann frag mal die Heimanwender, warum es aktuell über alle Versionen rund 115 Millionen Downloads von Azureus gab. Sicher nicht, weil alle die es testeten so unzufrieden waren, dass alle die davon hörten, ganz maso wurden und es selbst ausprobieren mussten - immer und immer wieder...

Aber ich mein wenns nur um die schnelle Entwicklung geht, ist Java ja genau so eine Quick-'n'-Dirty-Sprache wie VB.

Spaghetti-Code kann man in jeder Sprache schreiben, sollte aber kein Thema für ne ernsthafte Diskussion unter Entwicklern sein.

Ich finde das Endergebnis sollte immer im Vordergrund stehen, ich find es irgendwie schlampig so unperformante, resourcenfressende Lösungen zu programmieren. Die man einfach mit einer anderen "Basis" wesentlich sauberer/besser machen könnte und nur so schlampig programmiert damit man schneller fertig wird... Das bringt die Welt doch nicht voran... ;-)

Wie gesagt, kann ich weder in meinem Arbeitsbereich grundsätzliche Performance-Probleme sehen, noch finde ich in den vielen Blogs, die ich lese, über solche. Wenn es solche gäbe sollte man annehmen, dass jemand der sich viel in der Java-Community rumtreibt häufig über entsprechende Blog-Einträge u.ä. stolpern würde. Tue ich aber nicht.

Wenn ich irgendwo ein Haar in der Suppe finden will, werde ich das auch schaffen. Aber besonders schlau ist es nicht als Anfänger in einem Java-Forum anzufangen und erstmal der versammelten Mannschaft, die damit teils recht lang schon ihr Geld verdient, ans Bein zu pissen.
Sun ist mit Java recht früh einen Weg gegangen, der nun von anderen (MS) ausgebreitet wird. Es hat so seine Paralellen zur Geschichte von Mac OS und MS Windows...

 

[MPW]

Wooow ich muss sagen, das gibt einen Recordthread...so viele falsche Thesen hab ich schon lange nicht mehr gesehen...

BitComet ist mit C++ programmiert braucht ca. 12MB Arbeitsspeicher ud läuft sehr performant.

Azureus ist mit Java programmiert, frisst ganze 130MB Arbeitsspeicher!! und läuft langsamer als BitComet (trotzdem noch erstaunlich schnell für ein Java-Programm).

Hol dir halt die Java 6 Beta, das Problem ist da geloest. (Mal abgesehen davon, dass Java in der Regel hoestens 10-20 MB mehr braucht, ich weiss nicht, wie schlampig der Client programmiert worden ist!)

Mal abgesehen von dem Mumpitz den du erzaehlt hast, gebe ich dir nur in einem Punkt recht, Swinggui sind wirklcih traege, wenn man z.B. ein anderes Fenster mit der Maus drueberschiebt dauert es immer ein bisschen, bis der weisse Fleck wieder gefuellt wird.


Da das aber nicht deine komische Datenklasse betrifft, mach die einfach in Java und fertig!

 

[0xdeadbeef]

Hol dir halt die Java 6 Beta, das Problem ist da geloest. (Mal abgesehen davon, dass Java in der Regel hoestens 10-20 MB mehr braucht, ich weiss nicht, wie schlampig der Client programmiert worden ist!)

Na ja, die JVM benutzt üblicherweise per default schon 64MB. Ich nehme mal an, daß Azureus (wie Eclipse) so eingestellt ist, daß er sich etwas mehr nehmen darf. Ist ja heute auch kein Thema mehr. Wenn man 2006 unbedingt eine Anwendung schreiben möchtem die garantiert nur 12MB braucht, ist eine Sprache mir Garbage Collection schlicht und einfach nicht die richtige Wahl. Das ist meines Wissens aber mit C# und Objective C++ auch nicht anders.

 

[MPW]

Na ja, die JVM benutzt üblicherweise per default schon 64MB. Ich nehme mal an, daß Azureus (wie Eclipse) so eingestellt ist, daß er sich etwas mehr nehmen darf. Ist ja heute auch kein Thema mehr. Wenn man 2006 unbedingt eine Anwendung schreiben möchtem die garantiert nur 12MB braucht, ist eine Sprache mir Garbage Collection schlicht und einfach nicht die richtige Wahl. Das ist meines Wissens aber mit C# und Objective C++ auch nicht anders.

Aehm ???:L

1. Der andere, zum Vergleich herangezogene Client, war doch in C++ geschrieben, oder?
2. Natuerlich beschlagtnahmd Java nicht gleich 64 oder mehr....ich glaube 5 oder so sind Minnimum, aber trotzdem...also 130 fuer einen simplen Downloadclient ist einfach mieserable Programmierung.

 

[AlArenal]

Das ist meines Wissens aber mit C# und Objective C++ auch nicht anders.

Objective C++?

Also wenn du nicht möchtest, dass dir gerade die Apple-Coder mit nacktem Hintern ins Gesicht springen, solltest du da ne Wissenslücke schließen.

1. Es heißt "Objective C" und hat mit Stroustrups ++-Erweiterung syntaktisch nichts am Hut.
2. Objective C hat keine Garabge Collection

 

[byte]

Also erstmal muss ich Novanic in einem Punkt recht geben: Es sollte immer das Endprodukt im Vordergrund stehen und nicht das Werkzeug, um dieses Endprodukt zu erreichen. Wenn eine Technologie besser geeignet ist an ein Ziel zu kommen, dann sollte darüber nachgedacht werden auch dieses einzusetzen.

Jetzt kommt das große Aber:

Du schiesst Dir schon am Anfang dieser Diskussion selbst ins Bein, indem Du gnadenlos pauschalisierst:

... werden diese wohl auch genau so lahm wie Java-Klassen ausgeführt, da Java da wohl auch mit rumpfuschen würde.

Wenn Du schon in einem Java-Forum über Java herziehen willst (ich weiss, dass Du deshalb nicht hier bist, aber Du tust es halt), dann solltest Du Dir Dich schon vorher informieren. Java hat in einigen Punkten seine Schwächen, aber deshalb ist Java keineswegs generell langsam oder inperformant. Das werden Dir diverse Internetseiten bestätigen. Es gibt mittlerweile Operationen, die Java schneller ausführt als die Konkurrenz.

Im Endeffekt gibt es folgende Kritikpunkte:

1. Höherer Speicherverbrauch durch VM: Wir leben in einem Zeitalter wo Computerspiele zig GB fressen, da wird man wohl 64 MB für ne VM übrig haben... und für den Embedded Markt gibts sogar auch schon Java Lösungen mit entsprechend kleiner VM.

2. Trägere GUIs mit Swing als native Lösungen: Das ist imo der Hauptgrund, warum viele Java als langsam abstempeln. Wo andere Sprachen die nativen GUI Komponenten des Betriebssystems nutzen, zeichnen Swing Anwendungen in Java diese Komponenten halt selbst und sind dadurch plattformunabhänig. Aber wem Swing nicht Smooth genug läuft und dem die Plattformunabhängigkeit wurscht ist, der soll halt SWT/JFace benutzen.

3. Der Garbage Collector: Ist für mich der einzig wirkliche Grund, warum man Java als Langsam abstempeln könnte. Man kann halt nicht wirklich kontrollieren, wann er anspringt. Fakt ist, er verlangsamt das System, wenn er aktiv wird. Aber Fakt ist nunmal auch, dass er Java-Anwendungen extrem sicher macht. Das ist wohl eine der wichtigsten Eigenschaften in einem Zeitalter, wo die Komplexität von Softwareprodukten stetig wächst.

Am Ende sind es dann doch einfach die Entwicklungskosten die zählen. Und wenn es eine Sprache gibt, mit der man in kürzerer Zeit sicherere Software entwickeln kann, dann wird sie auch genutzt. Der Markt hat das erkannt, nur die C-Fraktion noch nicht.

 

[byte]

Ich weiß jetzt nicht wodrauf du hinaus willst, natürlich werden Java, C++ und C# nicht interpretiert, sondern die daraus resultierenden Anwendungen?! Wolltest du darauf hinaus?
Ansonsten werden Java-Anwendungen in Bytecode kompiliert und von den Runtimes interpretiert. Sonst bräuchte man ja keine Java-Runtimes...

Dieser Punkt sollte klar gestellt werden:

Java-Programme werden im Normalfall in einen nicht direkt ausführbaren Bytecode (Dateiendung .class) übersetzt, den Maschinencode der Java-Plattform, der in der Java Runtime Environment (JRE) ausgeführt wird. Es ist dabei festzuhalten, dass diese Ausführung von Bytecode nichts mit einem Interpreter zu tun hat, wie er zum Beispiel in Basic zum Einsatz kommt. Die aktuelle HotSpot-Technologie kompiliert den Bytecode zur Laufzeit vielmehr in nativen Prozessorcode und optimiert diesen abhängig von der verwendeten Plattform. Diese Optimierung findet dabei nach und nach statt, so dass der Effekt auftritt, dass Programmteile erst nach mehrmaliger Abarbeitung schneller werden. Auf der anderen Seite führt diese Technologie, die ein Nachfolger der Just-In-Time-Compilierung ist, dazu, dass Java-Bytecodes mindestens genau so schnell wie native, kompilierte Programme ausgeführt werden.

 

[AlArenal]

3. Der Garbage Collector: Ist für mich der einzig wirkliche Grund, warum man Java als Langsam abstempeln könnte. Man kann halt nicht wirklich kontrollieren, wann er anspringt. Fakt ist, er verlangsamt das System, wenn er aktiv wird. Aber Fakt ist nunmal auch, dass er Java-Anwendungen extrem sicher macht. Das ist wohl eine der wichtigsten Eigenschaften in einem Zeitalter, wo die Komplexität von Softwareprodukten stetig wächst.

Am Ende sind es dann doch einfach die Entwicklungskosten die zählen. Und wenn es eine Sprache gibt, mit der man in kürzerer Zeit sicherere Software entwickeln kann, dann wird sie auch genutzt. Der Markt hat das erkannt, nur die C-Fraktion noch nicht.

Sicherheit durch Garbage Collection?
Ich sehe den größten Vorteil des GC einfach darin, dass ich als Entwickler mich noch mehr auf Anwendungslogik konzentrieren kann und mir noch noch die Speicherverwaltung an die Backe heften muss, die in anderen Sprachen sicher für einen großen Teil der Software-Fehler und Seiteneffekte verantwortlich zeichnet.

Sun hat mit Java nichts grundsätzliche Neus erfunden, ebensowenig wie Microsoft mit C# und .NET (oder sonst irgendwas aus derem Hause), aber man hat Ideen und Konzepte aufgegriffen, zusammengeführt und andernorts gesammelte Erfahrungen in das Design einfließen lassen. Ich sage mal OOP, Garabege Collection, VM, ...
Das hat alles auch immer Vor- und Nachteile und so eine Entiwcklung dauert ja auch ne Weile und ist nach vorne gerichtet. AFAIK enthält Windows Vista nicht keinerlei .NET Code, ebensowenig wie keiner nen Linux-Kernel in Java coden wollen - noch nicht

 

[byte]

Sicherheit durch Garbage Collection?

Ich meine genau diese Sicherheit:

(...) Speicherverwaltung (...), die in anderen Sprachen sicher für einen großen Teil der Software-Fehler und Seiteneffekte verantwortlich zeichnet.

 

[AlArenal]

Ah, hatte da schon was vermutet..