Non sono stato mai un sostenitore di questo ambiente di sviluppo se non per quanto riguarda i concetti di base e l’eleganza del linguaggio.
I concetti di Java, come linguaggio di programmazione ed ambiente di esecuzione in-Sandbox, sono talmente potenti da aver segnato per sempre l’informatica spingendo la tecnologia verso una direzione che ne ha aiutato la rapida espansione.

Purtroppo, una cosa sono i concetti e i linguaggi, un’altra è il business e, più in generale, la capacità di realizzare fattivamente certe cose. In questo Sun ha fallito miseramente generando lei per prima una confusione ed una incertezza che hanno minato alla base il suo gioiello.

Ora che, in virtù dei soliti esperti da brochure pubblicitaria, per alcune cose abbiamo scelto di utilizzare questa tecnologia unitamente a Oracle e BEA ci troviamo nel peggiore dei mondi possibili di questo variegato universo: il versioning hell.

Avendo vissuto, nel mondo Windows, il famoso DLL Hell non pensavo di doverci ricadere dopo aver tanto penato in quell’incubo. Invece….

Sun e compari hanno pensato bene di moltiplicare i flavor di Java (J2EE, J2SE, Java Beans e compagnia cantante..) e se questo non bastasse il versioning è da panico. Alcune cose fatte in 1.4 non vanno in in 1.4.05 oppure in 1.4.11 e il JDK è versionato in maniera non allineata con la JVM che ha al suo interno.

In più BEA ha la sua versione speciale della JVM, JRockit, che segue un versioning tutto suo a ruota dei rilasci di SUN ma non completamente allineati e causa dei problemi con le librerie: in una parola INCUBO.

Sono un pò di giorni che abbiamo un misterioso problema su una conversione di tipo LONG nel driver di Oracle che si presenta, almeno in maniera riconducibile ad un problema unico, solo nell’ambiente di produzione.

L’errore è questo:

java.sql.SQLException: ORA-01461: si può eseguire associazione di valore LONG solo per inserirlo in una colonna LONG
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:111)
	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:330)
	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:287)
	at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:744)
	at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)	        at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:954)	at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1169)at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3338)	at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3444)	        at weblogic.jdbc.wrapper.PreparedStatement.execute(PreparedStatement.java:104)
	at it.code.dao.ChildDAO.processNotUniqueChild(ChildDAO.java:278)
	at it.code.dao.ChildDAO.serialize(ChildDAO.java:183)
	at it.code.model.Child.serialize(Child.java:75)
	at it.code.engine.Feeder.createParentsFS(Feeder.java:1358)
	at it.code.engine.Feeder.run(Feeder.java:278)

Sebbene l’argomento sia stato già a lungo dibattuto e indirizzato mi sono trovato a cambiare il driver Oracle seguendo la tabellina seguente:

Oracle Database 10g Release 2 (10.2.0.3) JDBC Drivers

JDBC Thin for All Platforms

• classes12.jar (1,600,090 bytes) – for use with JDK 1.2 and JDK 1.3
• classes12_g.jar (2,044,594 bytes) – same as classes12.jar, except that classes were compiled with “javac -g” and contain some tracing information.
• classes12dms.jar (1,607,745 bytes) – same as classes12.jar, except that it contains additional code`to support Oracle Dynamic Monitoring Service.
• classes12dms_g.jar (2,052,968 bytes) – same as classes12dms.jar except that classes were compiled with “javac -g” and contain some tracing information.
• ojdbc14.jar (1,545,954 bytes) – classes for use with JDK 1.4 and 1.5
• ojdbc14_g.jar (1,938,906 bytes) – same as ojdbc14.jar, except that classes were compiled with “javac -g” and contain some tracing information.
• ojdbc14dms.jar (1,553,561 bytes) – same as ojdbc14.jar, except that it contains additional code`to support Oracle Dynamic Monitoring Service.
• ojdbc14dms_g.jar (1,947,136 bytes) – same as ojdbc14dms.jar, except that classes were compiled with “javac -g” and contain some tracing information.
• orai18n.jar (1,645,114 bytes) – NLS classes for use with JDK 1.2, 1.3, 1.4, and 1.5. This jar file replaces the old nls_charset jar/zip files.
• ons.jar (48,492 bytes) – for use by the pure Java client-side Oracle Notification Services (ONS) deamon.
• demo.tar (604,160 bytes) or demo.zip (529,267 bytes) – contains sample JDBC programs.

Sarà sicuramente per mancanza di esperienza ma questo mi sembra veramente confuso e non aiuta la soluzione del problema.
Infatti il driver non è il problema e l’assenza di un debugger serio costringe ad andare per esclusione allungando drammaticamente i tempi di risoluzione.

.Net certo non è perfetto ma ha affrontato, e risolto, tutti i problemi che stanno uccidendo Java.

L’ironia vuole che, il motto che avrebbe dovuto fare di Java un grande linguaggio di programmazione oltre che di runtime (Write once, run everywhere), è stato modificato e scimmiottato in modo quanto mai efficace dai suoi avversari (write once, debug everywhere).

del.icio.us tags: java, bea, oracle, driver, versioning