News Oracle veröffentlicht Java 7

Wie trag ich Java7 in OOo/LibreOffice ein? Java7 wird bei mir irgendwie nicht erkannt.
 
Thaxll'ssillyia schrieb:
Mal eine Frage: Für manche Anwendungen wird die Java Runtime benötigt, um es laufen zu lassen. Was ist das? Ich denke, das Programm liegt schon kompiliert vor, wozu dann sowas installieren?

Wie gut, dass M$ seit jeher .NET im Windowsordner unterbringt, sonst müsste der normaldumme User sich ja mit der nachträglichen Install von Runtimes wie VB6 rumschlagen, das ist dem selbstverständlich nicht zuzumuten. Platz für das ein oder andere ungenutzte GB zusätzlich hat heute ohnehin jeder.
Und es wuchert und wuchert. .NET 1, 2, 3, 4, und Müllionen an Patches, Hotfixes, SPs. Es entbehrt ja nicht gewisser Komik, wenn man auf nem selten genutzten System den Patch für den Patch tatsächlich nochmal patchen muss :freak:
 
DaBzzz schrieb:
NET 1, 2, 3, 4, und Müllionen an Patches, Hotfixes, SPs. Es entbehrt ja nicht gewisser Komik, wenn man auf nem selten genutzten System den Patch für den Patch tatsächlich nochmal patchen muss :freak:

Du solltest doch mal nachdenken was du da von dir lässt. Schnelle Entwicklung ist nie schlecht. Du musst ja nicht immer gleich die neuesten Pakete nutzen. Um Bugs kommst du sowieso nicht rum, ganz gleich wie gut du programmieren kannst.

Im Prinzip ist es das gleiche wie bei C oder C++. Da kommt alle 10 + x Jahre ein neuer Standard heraus indem das Zeug aus der Boost Library in die STL wandert und dazwischen wird gepatcht und entwickelt. Also nichts was unüblich oder verwerflich ist.
 
@ darkfate:
Ich denke DaBuzz wollte auf was anderes hinaus (oder ich interpretiere da mehr rein).
.NET installiert jeden Mist. Der Installer von .NET installiert jede Version, auch wenn sie schon total veraltet ist und ich eine neuere Version installiert habe. Das selbe Schauspiel z.B. mit den C++ Redistributable Packages. Man installiert das neueste Package, aber irgendeine Software verlangt dann eine alte Version und schwupps wird das alte Package mitinstalliert.
Wieso kann Mircosoft da nicht einen Installer entwickeln, der überprüft, welche Version installiert ist und obs notwenig ist, die Software zu installieren. Bei DirectX haben sie es doch auch hinbekommen. Wenn ich DirectX11 installiert habe, kann ich nicht mehr zusätzlich DirectX10 installieren.
Ich hab zwar wenig Ahnung mit .NET, aber ich kann mir nicht vorstellen, dass sie bei jedem Release ihr Framework komplett ändern, sodass neuere Versionen komplett inkompatibel mit den älteren Versionen sind.
 
Whiz-zarD schrieb:
Ich hab zwar wenig Ahnung mit .NET, aber ich kann mir nicht vorstellen, dass sie bei jedem Release ihr Framework komplett ändern, sodass neuere Versionen komplett inkompatibel mit den älteren Versionen sind.

doch das ist der Grund, Microsoft garantiert für die Net-Versionen keine Abwärtskompatibilität.
 
Ja ne is klar. Das hat auch total viel mit der inkrementellen Patchweise zu tun. Als obs so schwer wäre (oder nennenswert Arbeitszeit kosten würde) kumulative Updatepakete zu schnüren. Und zwar für die, bei denen über die erzwungenen Stasidienste ohnehin feststeht, dass sie eine Uraltversion haben*. Nein, lieber .NET installieren, dann SPx dafür, darauf ein "kumulatives Update", das man dann patcht und den Patch dann noch zwei, drei mal akut hotfixt. Und vielleicht noch ein paar erzwungene Neustarts einstreut. Klasse Arbeit. Aber dann mit festen Patchdays daherkommen anstatt sofortigem Release von wichtigen Sachen, weils den vielen Admins auf dieser Welt ja Zeit spart.

Bei Adobe der selbe Rotz, zwischen ner Neuinstall des 8er Acrobats und ner aktuellen Version kann man locker 10x den Update-Manager aufmachen (der sich zwischendurch auch mal updatet...). Man lädt mehr Daten runter, als die ursprüngliche Install groß ist - muss das sein? Gibts beim Kauf eines 1000€-Softwarepakets auch gleich noch nen Monat Inet-Flat geschenkt?

*): Nokia machts (oder hats?) genau andersherum: Dort gibts es grundsätzlich nur komplette Pakete und KEIN Update, man kann sich also für drei neue Funktionen zwischen der letzten und der neuen Version jedes Mal ein paar 100 MB laden und installen. Genauso bescheuert.
 
DaBzzz schrieb:
Und es wuchert und wuchert. .NET 1, 2, 3, 4, und Müllionen an Patches, Hotfixes, SPs. Es entbehrt ja nicht gewisser Komik, wenn man auf nem selten genutzten System den Patch für den Patch tatsächlich nochmal patchen muss :freak:
Java 6 Update 26 klingt auch nicht gerade nach einer stabilen Plattform. Außerdem sollte man beachten, dass Java mittlerweile als größtes Sicherheitsrisiko auf Windows PCs gilt - im letzten Jahr hat Sun/Oracle damit erfolgreich Adobe diesen Rang abgelaufen (wobei man fairerweise dazu sagen muss, dass Java sich nicht extrem verschlechtert sondern Adobe sich stark gebessert hat).

Whiz-zarD schrieb:
Bei DirectX haben sie es doch auch hinbekommen. Wenn ich DirectX11 installiert habe, kann ich nicht mehr zusätzlich DirectX10 installieren.
Das glaubst aber auch nur du - geh mal in deinen System32 Ordner, such nach d3dx* und du wirst überrascht sein. Hast du ein paar Spiele installiert, so hast du wohl mehr als 10 DirectX 9 Versionen auf deinem Rechner.

Whiz-zarD schrieb:
Ich hab zwar wenig Ahnung mit .NET, aber ich kann mir nicht vorstellen, dass sie bei jedem Release ihr Framework komplett ändern, sodass neuere Versionen komplett inkompatibel mit den älteren Versionen sind.
Komplett inkompatibel zueinander sind sie nicht - aber am Beispiel Sun/Oracle sieht man wunderschön, dass die Microsoft-Strategie besser funktioniert. Jede größere Java-Applikation bringt heute bereits eine eigene JRE mit, da auch die kleinen Unterschiede manchmal einfach zu groß waren. Der große Vorteil von .Net ist, dass jede Version wirklich nur einmal abgelegt sein muss - bei Java ist sowas schon lange nicht mehr der Fall. Wird bei .Net eine DLL gesucht, so wird zunächst immer versucht, genau die passende Version zu laden - bei Java gibt es keinen solchen Mechanismus, unterschiedliche Versionen beißen sich und Bibliotheken können nur per Suchpfad bzw. unterschiedliche JREs unterschieden werden.
 
Zuletzt bearbeitet:
Bis auf Java 4 zu 5 wegen neuer Keywords ist Java voll abwärtskompatibel, das ist bei Java so, selbst die absolut überholten Klassen aus Java 1.2 existieren noch immer.

Die Updates in Java, also dein Beispiel des Java 6 Update 23 sind abwärtskomaptibel, dies sind fast immer nur Bugfixes oder es werden neue experimentelle Funktionen (wie der neue GC in Java7) eingebaut, diese sind aber alle ausgeschaltet und müssen per Flag beim Starten von Java speziell aktiviert haben.

Der Vergleich von Java zu C#/.NET hinkt da gewaltig ;) MS hat natürlich aber auch dadurch den Vorteil alten Mist wegwerfen zu können, bei Java werden diese veralteten Klassen auch noch die nächsten 10 Jahre vorhanden sein.


Die Sache mit der JRE-Mitlieferung hat einen ganzen anderen Grund, man kann Windows-Nutzern scheinbar nicht zutrauen, dass diese selbst eine JRE laden und installieren, da muss alles fertig installierbar in einer Datei sein, bei der der Nutzer immer nur auf weiter klicken muss.
 
Bei uns in der Firma wird mittlerweile die JRE auch mitgeliefert (wohlgemerkt in 3 unterschiedlichen Versionen) weil es einfach zu viele Kompatibilitätsprobleme gegeben hat. Das größte Problem neben der Speicherplatzverschwendung ist das Problem, dass diese Versionen natürlich z.T. mehrere Jahre alte Sicherheitslücken enthalten.
 
Simpson474 schrieb:
Java 6 Update 26 klingt auch nicht gerade nach einer stabilen Plattform. Außerdem sollte man beachten, dass Java mittlerweile als größtes Sicherheitsrisiko auf Windows PCs gilt - im letzten Jahr hat Sun/Oracle damit erfolgreich Adobe diesen Rang abgelaufen (wobei man fairerweise dazu sagen muss, dass Java sich nicht extrem verschlechtert sondern Adobe sich stark gebessert hat).

Gell Java hat tatsächlich den um immer mehr und ganz tolle Features erweiterten Adobe Reader und Flash abgelöst? Quelle?

Sagen wirs so, Oracle ist da wenigstens ehrlich und nennt die Nummer des Updates. Aus KB123456 kannste nicht rauslesen, ob das das erste oder das zwanzigste Update für einen OS-Teil ist. Man kanns raussuchen, aber wenn man mir offensichtlich etwas nicht direkt sagen will, dann hat das bestimmt auch seinen Grund.

Nebenbei, was soll ich von Kernelversion 2.6.38-10 halten? Ist das jetzt gut? Sind die noch nicht dem Versionswahn erlegen? Oder ist das der totale Flickenteppich, wenn die schon in der vierten Zifferngruppe hochzählen müssen, damit die signifikaten Stellen am Counter nicht zu brennen anfangen?
 
Mal andere Frage -> sollte man Java x32 und x64 Installieren, wenn man zb x64 Betriebsystem nutz?
Habe Windows 7 x64 und benutze zum Browsen den FireFox.

Sachen wie Netbean und Eclipse laufen mit der nur x64 Version auch ohne Probleme, aber kumpel meint man brauch beide.

Ich meine normal brauch man das nicht, weil ja Java eher Interpretiert wird oder ?

mfg
 
Für 32-Bit-Software brauchst du die 32-Bit-Laufzeitumgebung und für 64-Bit-Software brauchst du die 64-Bit-Laufzeitumgebung.
 
chied schrieb:
"in Switch-Anweisungen den Datentyp String zu verwenden"
Das gab's vorher noch nicht?!
Wow... Einmal mehr ein Grund, .NET zu verwenden und nicht dieses zurückgebliebende Kaffeetassenzeugs...
Hehe. Das siehst du als Grund an? Nicht etwa die Lambda Expressions? Extension Methods? LINQ? Die Task Parallel Library? Typinferenz? Support für interne und externe Domainspezifische Sprachen (DSLs)? Die Reactive Extensions? XML Literals? Unsafe Code? Und in Zukunft so Dinge wie Async?
So kleine Features, wie Strings in Switch Anweisungen, optionale Parameter oder sowas sind zwar schön, aber wichtig sind wohl eher die dicken Brocken, die dir die Arbeit erleichtern.

Das sind für mich eigentlich die Gründe warum ich C# und VB.NET entwickle (man beachte das man mit .NET auch eine deutlich höhere Sprachenvielfalt hat). Die Sprachen sind einfach viel moderner und sind auf dem neusten Stand. Nicht ohne Grund sprießen im JVM Bereich andauernd neue Sprachen aus dem Boden, wie kürzlich Kotlin. Die versuchen die Features zu integrieren, die Java fehlen.
Scala ist zwar schon eine gute Alternative aber in vielerlei hinsicht macht sie viele Dinge komplizierter als sie eigentlich seien müssen. Kotlin sieht eigentlich gar nicht so schlecht aus. Das wäre für mich noch eine akzeptable C# Alternative, doch ob sich neben den ganzen existierenden Sprachen jetzt noch eine zusätziche Sprache durchsetzen kann ist schwer zu sagen. Bestenfalls wird es noch Jahre dauern bis Kotlin eine große Verbreitung gefunden hat.

Und bis dahin ist .NET natürlich auch wieder viel weiter.


PS:
Eine weitere sehr wichtige Sache die man auch nie außer acht lassen sollte ist, dass die Tools mit denen man arbeitet auch hervoragend sind. Eine gute IDE ist schon sehr viel Wert genauso sehr wie der neue Compiler as a Service, welcher sehr viel Comfort und sehr geile Refaktorisierungstools für .NET ermöglichen wird.

PPS:
Ein letzter Vorteil fällt mir da noch ein. Laut Java Grande Benchmark Suite, die auch in C# nachprogrammiert wurde ist .NET bei den Low Level Operations 16% schneller als Java und bei den Kernels sogar satte 75% schneller.
Muss wohl an den beschissen implementierten Generics von Java liegen. :)
 
Zuletzt bearbeitet:
noxon schrieb:
Scala ist zwar schon eine gute Alternative aber in vielerlei hinsicht macht sie viele Dinge komplizierter als sie eigentlich seien müssen. Kotlin sieht eigentlich gar nicht so schlecht aus. Das wäre für mich noch eine akzeptable C# Alternative, doch ob sich neben den ganzen existierenden Sprachen jetzt noch eine zusätziche Sprache durchsetzen kann ist schwer zu sagen. Bestenfalls wird es noch Jahre dauern bis Kotlin eine große Verbreitung gefunden hat.
jup, die funktionalen Aspekte machen Scala zu komplex. Dadurch wird Scala leider eine Randsprache bleiben, denn eines wurde da wirklich gut umgesetzt: das ganze OOP-System. Und das Actor-System passt in die Sprache wirklich wie die Faust aufs Auge, eine geniale Sache für wirklich gute Concurrency.
Aber ich würde nicht jedem zutrauen, in Scala zu programmieren, dafür hat man dann doch zuviele Features eingebaut und die Sprache zu komplex gemacht, ein Scala-- wäre durchaus angebracht...
Kotlin ist eine Totgeburt, wird nichtmal den Hauch einer Chance haben.


noxon schrieb:
PPS:
Ein letzter Vorteil fällt mir da noch ein. Laut Java Grande Benchmark Suite, die auch in C# nachprogrammiert wurde ist .NET bei den Low Level Operations 16% schneller als Java und bei den Kernels sogar satte 75% schneller.
Muss wohl an den beschissen implementierten Generics von Java liegen. :)
von denen habe ich noch nie gehört, danke.
Ich würde aber den Ergebnisen nicht zuviel relevanz zusprechen, solche primitven Operationen zu messen ist in Java einfach sau schwer, da wird alles viel zu schnell durch den GC, JIT oder sonstwas verfälscht.
Aber bei einem Punkt müssen wir uns denke ich nicht streiten oder? Sowohl Java als auch C# werden schnell genug für die meisten Anwendungszwecke sein, wenn beide das nicht sind, setzt man ohnehin auf Sprachen mit garantierten Laufzeiten für Operationen.
 
Zuletzt bearbeitet:
darkfate schrieb:
Du solltest doch mal nachdenken was du da von dir lässt. Schnelle Entwicklung ist nie schlecht.

Im Prinzip ist es das gleiche wie bei C oder C++. Da kommt alle 10 + x Jahre ein neuer Standard heraus indem das Zeug aus der Boost Library in die STL wandert und dazwischen wird gepatcht und entwickelt. Also nichts was unüblich oder verwerflich ist.

Naja, gibts schon Unterschiede. bei C oder C++ wird auf Papier theoretisch die Sprache festgelegt. Das steht dann fest für 10 Jahre oder so. Und die Software, die dafür geschrieben wird(Compiler, etc.), implementiert das und verbessert sich kontinuierlich, aber der Standard ändert sich nicht.

Bei .NET kommt fast jährlich eine neue Major-Version, die wieder Sachen anders macht.

Manchmal ist es besser sich Dinge länger zu überlegen und dann für eine große Zeitspanne festzulegen. Das heißt nicht, dass nicht Updates für Compiler kommen, aber eine Sprache jedes Jahr zu erweitern birgt das Problem in sich, dass Techniken und Ansätze, die sich die Programmierer aneignen, schnell wieder obsolet sind.

Und ein weiterer Unterschied ist: Compiler für C++ bekommen Bugfixes, die halt Bugs beheben, aber fast nie sicherheitsrelevante Dinge ausmerzen. Für die Sicherheit des Programmes ist der Programmierer zuständig.
Bei interpretierten Sprachen besteht immer das Problem des Zwischenschrittes über die virtuelle Maschine, wo zusätzliche Fehler auftreten können. Und dann gibts Patches, Patches, Patches.
 

Ähnliche Themen

Zurück
Oben