Christopher J. Ruwe writes:
> On Fri, 2018-03-23 at 17:10 +0100, Volker A. Brandt wrote:
> > Hi Christopher!
> >
> > [...]
> >
> > Das mußte ich ein paarmal (auf der Original-Seite) lesen. Ich vermute,
> > mit "Public Updates Notification" meinen sie diese Dialoge, die auf-
> > gehen, wenn Oracle meint, daß man aktualisieren sollte.
>
> Gemeint ist, so korreliere ich es, wann Oracle _angekünidgt_ hatte,
> keine public updates mehr liefern zu wollen.
Hatte ich anders verstanden. Ist langfristig aber wohl egal.
> > > dh, Java 10 hat einen Public Support Cylce von 6 Monaten und der von
> > > Java 9 war genauso lang. Hatte ich jetzt so nicht auf dem Schirm. Ihr
> > > könnt da ruhig schimpfen, aber ich binde mir solche Support-Zyklen nur
> > > dann ans Bein, wenn ich mir davon einen wirklich wesentlichen Vorteil
> > > verspreche.
> >
> > Da gibt es nix zu schimpfen. Sie sagen, 9 und 10 seien Übergangs-
> > versionen (war mir vorher so nicht bewußt). Also kann man auch bis
> > Dezember 2020 ("or later" :-) bei Version 8 bleiben und dann auf
> > 18.9 LTS gehen.
>
> Genau. Mir war auch bisher kein "professionelles" Java 9 Projekt
> bekannnt und jetzt verstehe ich auch, warum die alle auf 8 bleiben.
Vermutlich ist alles, was mit 8 läuft, auch auf 9 lauffähig. Wenn
sie nicht großen Mist gebaut haben.
> > > 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.
> 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.
> > > 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.
> > 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.
> 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.
> 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
> > > Ich hätte darüber nicht nachdenken sollen, ab jetzt verstehe ich das
> > > gesamte Umfeld nicht mehr.
> >
> > Tja :-)
>
> Es wird nicht besser ...
:-)))
Viele Grüße -- Volker
--
------------------------------------------------------------------------
Volker A. Brandt Consulting and Support for Solaris-based Systems
Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: [email protected]
Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt
"When logic and proportion have fallen sloppy dead"
