OCI != Thin
Außer denen, dass im Code Referenzen auf Spezialfunktionen (transparent Failover, Connection Caching, Statement Caching, usw.) und für das jeweilige andere DBMS inkompatible SQL Statements drin sind.
Wer zig tausend EUR für eine ORACLE Lizenz ausgibt, der weiß in der
Regel auch, wenn er sowas benutzt, das er sich auf properitären
Gebiet bewegt und muss sich dann doch nicht wundern wenn seine
Applikation nur mit ORACLE läuft. Es gibt sehr gute freie distributed
DB und Failoverpackages die mit 100% pure Java arbeiten wie z.B
Sequoia die sogar einen Mix aus verschiedenen RDBMS zulassen.
Egal, ob Dir das in den Weg passt oder nicht. Erzähl mal Deinem Großkunden, dass seine vor 7 Jahren entwickelte und immer noch tadellos laufende Applikation voll Grütze ist und er sich mit solch unsupportetem Zeugs doch selbst ins Knie schießt.
Die Großklunden die ich kenne haben meistens eigene IT-Abteilungen und
die sind in der Regel sehreinsichtig und stimmen einem Upgrade unter
Einhaltung bestimmter Releasebedingungen meist zu.
Anders als in Deiner Fantasie gibt es Software die über mehrere Jahre läuft, supportet und erweitert wird.
Vergleiche das mal mit Deinem Beispiel über XT Commerce.
Sagt ja auch keiner was dagegen. Ein Source der auf 1.3 basiert und auf
Standard JRE basierenden Funktionen läuft (was eigentlich immer so sein sollte) wird auch weiterhin laufen (wovon Du gerade sprichst sind übrigens
Java Desktop Applikationen, PHP ist aber nur eine Sprache für dynamsiches
HTML - das ist daher ganz sicher ein Vergleich von Äpfel mit Birnen).
Ich kanns nur wiederholen: Wer meint es muss mit "Gewalt" unstadardisierte
Native Verquickungen zum Betriebssystem zu bauen, der ist selber schuld.
SUN hat schon immer davon ageraten sowas zu machen und in jedem
Java Handbuch wird davor gewarnt. Es kann also keiner sagen, daß
er nicht wüßte was er da macht, er weiß es in der Regel ganz
genau, sich also darüber beschweren das es in späteren JRE's irgendwie
poblematisch wird ist wohl handfestes Eigenverschulden und kein
Java spezifisches Problem. Ich muss mich auch nicht wundern, wenn
ich meinen C Source auf AMD64 anpasseund das Programm dann auf
einem Intel nicht mehr läuft.
Ich kann es gerne nochmal wiederholen, denn die eigentliche Kernaussage hast Du immer noch nicht begriffen (wie auch Dein nachfolgener Auswurf deutlich macht):
Schlechten Code kann ich mit jeder Programmiersprache schreiben. Manche Sprachen sind zwar restriktiver als andere, aber das ist für viele "Künstler" kein Hinderungsgrund. Der bloße Einsatz einer Technologie / Plattform / Programmiersprache hat _keinen_ Einfluß auf die Qualität des Codes.
Anders ausgedrückt: A fool with a tool is still a fool.
Da gebe ich Dir recht.
Soso für PHP gibt es also keinen Debugger. Wozu hat Eclipse dann eine PHP Debug Perspektive? Vielleicht so als Placebo? Oder als Platzhalter, falls mal jemand einen PHP-Debugger erfindet?
Dein Halbwissen ist auch nicht von schlechten Eltern.
Das ist ja wohl kein Anständiger, objektorientierter Debugger wie im
Fall von Java, Und nur weil Eclipse ein Fenster ambietet, das die Parser
und Laufzeitfehler sturkturierter ausgibt, kann man wohl kaum von einem
richtigen Debugger sprechen. Vor allem da PHP ein native gelinktes Modul ist.
Um sowas vernünftig debuggen zu können, bräuchtest Du den passenden
C Source, sämmtliche Header oder alternative zur verwendeten Version
die Debug Symbols, damit Du auch siehst wie deine Expressions in die
Internen Strukturen von PHP verarbeitet werden.
Bei Java ist das völlig anders. Jeder 100% Compliant JVM hat Debug
Agents Connectoren die in die JVM schauen und detailliert berichten
welcher Thread wo, was gerade macht. Du siehst sogar, wo eine Endloss.
schleife oder ein Deadlock entsteht und kannst Code ändern und
mit repat fortsetzen.
