DLL systemunabhängig?

[Elvis]

Zitat von Phoenix:

.NET ist da ne gute Alternative.

Wenn es eine komplette XPlattform-App werden soll, dann wäre Java sogar eine exzellente Wahl.
Aber wie es aussieht soll das ganze nativ bleiben (da bereits eine native GUI existiert, oder? ) und da fliegen sowohl Java als auch Mono raus.

[Angel4585]

ne es existiert noch keine GUI, wenn Java geeignet wäre würde man Java nehmen, aber es wird als "zu lahm" angesehen.. ich mag Java eigentlich

[Elvis]

Zitat von Angel4585:

ne es existiert noch keine GUI, wenn Java geeignet wäre würde man Java nehmen, aber es wird als "zu lahm" angesehen.. ich mag Java eigentlich

Selbst Swing ist mit Java6 schneller als SWF oder WPF, Javas SWT hingegen war schon von Anfang an schneller als jedes .Net GUI Framework. Also was immer von der MS-Fanboy-Ecke zum Thema .net GUIs wären schneller kommt, kannst du getrost vergessen.
Mache dir selbst ein Bild von Lazarus und Java um herauszufinden was dir besser gefällt.

Aber wie gesagt, eine Java Bibliothek in einer nativen Anwendung zu benutzen wird so abartig dass
es zu einem Kündigungsgrund deinerseits werden kann.
Überlege dir also genau wie das gemeint war, frage besser ob da überhaupt etwas gemeint war (@Manager, oben).
Soll es as Bibliothek zur Verfügung stehen, sollte es eine native DLL sein. Die GUI kannst du aber immer noch in Java schreiben. (Von Java eine native Lib zu benutzen ist einfacher als andersrum, etwa um den Faktor 10^100)

[Angel4585]

ne es sollte ein Funktionskern für unsere neue Software sein, es ist noch nicht klar in welcher Sprache das programmiert werden soll, aber es ist klar das es auch auf Linux laufen soll.
Die Frage ist jetzt: Alles in Java, wobei dann ein Thema wie ein Dienst etwas schwierig sein dürfte, oder eben eine Bibliothek in Delphi/C++ und für jedes System ne eigene GUI.

[OregonGhost]

[OT]
Also, auf meinen Rechnern sind WPF und Windows Forms wesentlich schneller als jede Java-Anwendung, die ich bisher gesehen habe, während Java, egal ob AWT, SWT oder sonst was immer dahinkriecht.
[/OT]

Schonmal Qt ausprobiert? C++, "plattformunabhängig" (Unix/X11, MacOS X Native und Win32 Native), ein Quellcode für alle Plattformen und eine relativ gute Bibliothek, die den C++-STL-Murks und auch Boost überflüssig macht.

[Phoenix]

Als ob ich mit dem Performance-Argument kommen würde... . Es geht simpel um Wartbarkeit der Anwendungen.

Java wird inzwischen von QM-Unternehmen (imho zurecht) als so unwartbar angesehen, dass die z.B. Pharmaunternehmen die ISO-Zertifizierung nur noch unter der Auflage erneut zuteilen, bestehende Java-Anwendungen durch wartbare Anwendungen abzulösen. Befolgt das Unternehmen die Auflage nicht, ist das QS-Zertifikat wech.

Das war z.B. bei Phizer und Sanofi Aventis schon so.

[Angel4585]

warum soll Java unwartbar sein?
Also ich mach jetzt seit inigen Monaten Java. Es stimmt schon das wenn ich von 1.4 auf 1.6 gehe sich einiges ändert, aber wenn ich bei 1.6 bleibe über Jahre hinweg, ändert sich nichts an Funktionen und man muss dann wenn man die Version wechselt nur einmal alles überarbeiten, was relativ schnell geht.(Naja kanns chon paar Tage/Wochen gehn wenns viel ist, klar)
Aber wie gesagt: Ich find mich sehr gut in Java zurecht.

[Der_Unwissende]

Zitat von Angel4585:

Es stimmt schon das wenn ich von 1.4 auf 1.6 gehe sich einiges ändert, aber wenn ich bei 1.6

Hi,
eine Geschichte die MS bisher auch nicht besser gemacht hat, schauen wir uns mal die Vorgänger von .net (COM, COM+, DCOM, DDE) an und die Entwicklung .net 1.x, 2.x, 3.x (ok 3 ist ja nur ein leicht erweitertes 2).
Was die Geschwindigkeit angeht, so ist das eh immer ein (langweilig altes) Argument, dass man mal mit heutigen JITs betrachten sollte, da relativiert sich dann doch einiges. Nebenbei gibt es auch Qt mittlerweile für Java. Qt läuft dabei nativ und wird über eine JNI (Java Native Inteface) - Brücke angesprochen. An sich kannst Du aus Java heraus eben auch native Programme in dyn. linkbaren Bibliotheken ablegen und diese nativ ausführen. Für den Aufruf und das marshaling geht natürlich etwas Zeit drauf, aber das Problem hast Du auch wenn Du Objekte verwendest.

.net ist leider als Plattformunabhängige Plattform noch ungeeignet, da es keine Implementierung für genügend Plattformen gibt (über die Wartbarkeit von Managed C++ könnte man z.B. auch streiten).

Aber es gibt trotzdem Alternativen zu Haskell, z.B. kannst Du auch auf Python, Haskell oder die universelle TuringMachine zurückgreifen (ok, das mit dem unendlichen Speicher wird schwer), was am besten geeignet ist sollte nicht pauschal festgelegt werden. Vielmehr hat jede Sprache so ihre Nische in der sie besonders toll ist (oder auch nicht).

Gruß Der Unwissende

[Angel4585]

OK, das heisst man müsste Aufgaben definieren die die Software tun soll und dann schauen welche Sprache für diesen Bereich am geeignetsten ist?

In unserem Beispiel hiesse das, das die Software sehr viele Dateien vergleicht und kopiert.
Ausserdem soll sie als Dienst laufen und übre Netzwerk kommunizieren.

Ich weis das Java schneller als C++ ist wenns darum geht Objekte zu erzeugen. da es viele Dateien sein werden und jede vmtl ein Objekt sein wird, wäre das evtl ein Vorteil oder?
Allerdings wie es mit Java auf Dateiebene aussieht weis ich nicht.

[Der_Unwissende]

Zitat von Angel4585:

OK, das heisst man müsste Aufgaben definieren die die Software tun soll und dann schauen welche Sprache für diesen Bereich am geeignetsten ist?

Na ja, etwas mehr sollte man schon berücksichtigen. Natürlich ist es auch wichtig, welche Sprachen im Haus verwendet werden. Wenn es z.B. total super in Brainfuck gelöst werden könnte (glaube nicht, dass irgendwas gut in der Sprache lösbar ist), könnte der Code aber auf die meisten Leute doch etwas schwer Les-/Wartbar wirken. Auch wirst Du kaum für jedes Programm eine neue Sprache lernen wollen. Hast Du im Haus eine Abteilung, die für die Qualitätssicherung zuständig ist, so wirst Du sicherlich nichts nehmen dürfen, was die nicht verstehen (Verifikation des Codes wäre sonst etwas schwer).

Zitat von Angel4585:

In unserem Beispiel hiesse das, das die Software sehr viele Dateien vergleicht und kopiert.
Ausserdem soll sie als Dienst laufen und übre Netzwerk kommunizieren.

Also was Dateien angeht, da würde ich fast mal behaupten, dass der Java-Code ähnlich flink wie der C++ Code arbeiten sollte. Es hängt hier i.d.R. viel mehr vom Code selbst (was kann der Entwickler, was berücksichtigt er, ...) ab als von der verwendeten Sprache. Ich bekomme sicherlich ein Programm in C langsamer als das Äquivalent in einer interpretierten Sprache hin, ich muss eben nur schlecht genug arbeiten. Ein pauschales schneller gibt es halt nicht. Wichtiger ist deshalb eher, ob Du besser mit C++ oder Java zurecht kommst (wo es mehr Komponenten und Bibliotheken gibt, die Du verwenden möchtest, ...).
Netzwerk ist immer so ein Wort, wo viele Leute an Java denken. Java ist nun mal mit Netzwerken groß geworden und bietet von sich aus gleich eine ganze Menge schöner gekapselter Funktionen rund um das Thema Netzwerk. In C++ ist das eventuell (kenn mich da nicht so aus) anders, hier kann es sein, dass eher auf die direkte Schnittstelle des OS zurückgegriffen werden würde. Qt abstrahiert davon, stellt auch in C++ eine unabhängige Schnittstelle für solche Dinge bereit (vielleicht hat C++ die ja ohnehin). Die .nets dürften hingegen ähnlich wie Java arbeiten (aber kaum unter Linux voll unterstützt werden).

Zitat von Angel4585:

Ich weis das Java schneller als C++ ist wenns darum geht Objekte zu erzeugen. da es viele Dateien sein werden und jede vmtl ein Objekt sein wird, wäre das evtl ein Vorteil oder?

Ok, sagen wir mal dem ist so, der Hauptteil der Zeit vergeht aber nicht beim Erzeugen (und Freigeben) von Objekten, wichtiger erscheint doch häufig die Zeit die bei der Ausführung der Methoden vergeht, da kann das Bild dann anders aussehen (und diese Zeit dürfte die des Erzeugen häufig dominieren).