Hi, wir brauchen mehr solcher Threads. Für derartige Längen mußt Du normalerweise flamen oder trollen ...
On Sun, 2018-03-25 at 17:52 +0200, Volker A. Brandt wrote: > Christopher J. Ruwe writes: > > On Fri, 2018-03-23 at 17:10 +0100, Volker A. Brandt wrote: > > > Hi Christopher! > > > > > > [...] > > > > wundert es mich jetzt, daß man das für SPARC überhaupt rausgebracht > > > > hat. Development und Integration-Testing für die JVM kann ich mir auf > > > > Solaris und gerade SPARC eh schwer vorstellen. > > > > > > Dafür haben die doch seit Jahren fertige Verfahren. Was soll daran > > > schwierig sein? > > > > Das meine ich nicht. Ich frage, warum man es überhaupt tut. Die JVM > > ist eine Process Virtual Machine und abstrahiert hinreichend genau von > > der Rechnerarchitektur. > > Hmmm.... Deine Aussage ist also "Oracle sollte Java für SPARC > überhaupt nicht rausbringen, weil eine JVM die Prozessor-Architektur > verdeckt?" Verstehe ich irgendwie nicht. Einer muß die abstrakten > Java-Ops auf die CPU mappen. Genau das macht die JVM. Wenn es die > für eine Plattform nicht gibt, läuft nix. Nur halb. Ich behaupte, daß Java 9 und 10 keine Versionen sind, auf denen man produktiv Software betreiben kann (da haben wir glaube ich Konsens). Deswegen braucht man es nur zum Testen. Weil 9 und 10 nicht produktiv gehen werden, benötigt man weder Akzeptanz- noch Performanz-Tests, weil die dann eh für die Tonne sind. Übrig beleiben funktionale Tests im Rahmen der Software-Entwicklung (meist Integrationstests). Hier behaupte ich, daß es innerhalb der JVM keinen Unterschied machen _sollte_ (wenn wäre es ein Bug in der JVM), ob die JVM nun auf Intel oder SPARC oder auf Linux oder Solaris läuft. Ich versuche auszudrücken, daß ich in Solaris eine Plattform sehe, die man nur dort betreibt, wo es eine PROD gibt, die sehr serös betrieben wird. Wenn es für 9 und 10 keine solche PROD (und auch keine ACCPT und INT) geben wird, sondern allenfalls eine DEV, behaupte ich, daß man dort noch kein Solaris braucht. Deswegen am Schluß auch mein Unverständnis, warum man überhaupt hier eine Solaris-Version der JVM _veröffentlicht_. Das kommt dann mE später, wenn das staging komplett ist. Ungeachtet dessen _hoffe_ ich, daß innerhalb von Oracle in die Entwicklung der JVMs für alle OS/Arch Kombinationen adäquater Test-Aufwand gesteckt wird, weil man es dann, wenn es eine realistische Option auf eine PROD gibt, doch wieder braucht. > > Bei Integrations-Test prüfe ich Programm-Funktionalität. Da kann es > > mir doch egal sein, auf welcher OS-Plattform das Programm läuft. Unter > > der Voraussetzung, daß ich nicht irgendwelche System-Programme aufrufe, > > was man aber in Java allgemein nicht machen sollte. > > Das wäre der Test eines Java-Programms. Der Test einer JVM ist > notwendigerweise aber plattform-spezifisch. s.o. Aber der tatsächlich plattform-abhängige Test der JVM ist doch nicht Aufgabe der Kunden, sondern von Oracle. JVM haben und testen sehe ich bei Oracle, aber nicht beim Kunden, daher meine Betonung von _veröffentlicht_. > > > > Akzeptanz-Testen ist etwas anderes, aber da brauch ich doch kein > > > > Akzeptanz-Testen für 6 Monate? > > > > > > Es geht wohl eher darum, das neue Release-Modell aufzubauen. > > > > Das meinte ich nicht. Wenn ich bei einer Process-VM auf OS-Plattform > > und Rechnerarchitektur teste, dann kann es sich mE nur um Performanz > > oder Akzeptanz handeln. Und dann mache ich das doch nicht für 6 > > Monate. Was anderes fällt mir nicht ein, lasse mich aber gerne > > belehren. > Du nimmst an, daß die sechs Monate für Tests sind. Das gibt die > bisherige Informationslage aber nicht her. Ich vermute eher, daß > die sechs Monate bürokratie-bedingt sind. Das kann sehr gut sein. Aber ungeachtet dessen kann man ja nicht gegen die neuen Funktionen von 9 und 10 entwickeln, wenn man gar nix zum testen hat. > > > Viele Kunden haben Unmengen an Java-Bestands-Code, der möglicher- > > > weise auch noch mit DBs redet. Auch Oracle hat DB-Zeugs in Java > > > geschrieben. Die SPARC-CPU- und die JVM-Leute haben angeblich > > > koordiniert JVM-Primitiven in der CPU abgebildet. > > > > Das sehe ich ein. Meine spätere Aussage war eher, warum diese > > _Zwischen_-Releases überhaupt für das Solaris-Umfeld interessant sein > > sollten. Ab Java 11 wird es vielleicht wieder interessant. Aber für > > diese Interims-Versionen sehe ich den Case nicht. > > Der Case ist auch nicht technisch: Die Leute sollen sehen, daß die > Plattform weiter unterstützt wird. Momentan sehen sie es nicht. Ja. Das sehe ich ein. Die Kommunikation ist Oracle-typisch unterirdisch. > > Uns zu meiner früheren Aussage: Ich sehe wenig Weiter-Entwicklung auf > > Solaris, auch bezüglich der Applikations-Software. Wäre froh, da > > Unrecht zu haben, aber ich bin nunmal Pessimist. Deswegen mein > > Gedanke: Dann reicht doch Java 8. > > Das ist ja ein generelles Solaris-Problem. Mein Punkt ist eher der, > daß Oracle einen Unterschied zwischen Solaris SPARC und Solaris x86 > macht. Da kenne ich mich leider zuwenig aus. Ich verstehe in 90% der Fälle sowieso nicht, warum man SPARC nimmt. (Neutral gemeint, daß ich es nicht verstehe, heißt nicht, daß ich es für falsch halte.) > > Abgesehen davon sehe ich den Case für SPARC da, wo ich I/O brauche, > > was ich nicht für einen Java-Sweet-Spot halte. Java in Silicon? Werde > > ich mal suchen, habe aber gerade massive Schwierigkeiten, mir den Case > > vorzustellen. > > Da gibt es diverse Jubel-Seiten von Oracle im Netz. Sowas wie das: > > https://blogs.oracle.com/bestperf/accelerating-java-streams-performance-using-sparc-with-dax So wie ich das überflogen habe, sind das Filter, wie sie in funktionalen Sprachen seit zwei drei Jahren gehyped werden. Die Beispiele auf der Seite sind abgesehen von dem SQL alle irgendwo Java, aber das Konstrukt kommt doch auch in anderen Sprachen vor. Als Java in Silicon würde ich es jetzt nicht sehen, wobei mit hier allerdings die Sprach-Verteilung im Data Processing Bereich nicht bekannt ist. Kann schon sein, daß es sehr viel Scala und Clojure sein wird und das ist ja dann tatächlich JVM. Auf jeden Fall viele Grüße! -- Christopher
