Java 6 Fonte indietro-compatibilità e SQL

Question

La mia comprensione è che, al fine di mantenere la fonte-compatibilità, Java non introduce nuovi metodi per interfacce pubbliche, come quella spezza i clienti esistenti di attuazione delle interfacce. Note Java Release stati

  

In generale, la politica è la seguente,   ad eccezione di eventuali incompatibilità   elencati più sotto:

     

  

• release di manutenzione (come ad esempio 1.4.1,   1.4.2) non introducono nuove funzionalità del linguaggio o API. saranno   mantenere source-compatibilità con   l'altro.

  

• rilasci funzionalità e maggiore   stampa (come ad esempio 1.3.0, 1.4.0, 5.0)   mantenere l'alto ma non verso il basso   source-compatibilità.

  

Tuttavia, i pacchetti java.sql e javax.sql continuano ad evolversi e introdurre molti cambiamenti incompatibili. Per esempio, ho notato le seguenti modifiche incompatibili (introdotte in Java 6):

• java.sql.Statement estende java.sql.Wrapper, richiedendo nuovi due nuovi metodi.
• java.sql.Statement introduce 3 nuovi metodi
• java.sql.PreparedStatement introduce 19 nuovi metodi !
• java.sql.ResultSet introduce 48 nuovi metodi !

Sapete come e perché ottenuto aggiunto questi metodi? È java.sql essere trattati in modo diverso dal resto della piattaforma? Sapete della discussione / JSR intorno a queste integrazioni?

Answer 1

ho ottenuto la seguente risposta da uno sviluppatore Sun

La politica evoluzione generale per le API nel JDK per rilasci delle funzioni come JDK 7 è

1. Non rompere la compatibilità binaria (come definito nel capitolo JLSv3 13)
2. Evitare di introdurre incompatibilità di origine
3. Gestisci cambiamento comportamentale compatibilità

(Per di più, molto di più di quanto si desideri leggere su diversi tipi di compatibilità vedi

"Tipi di Compatibilità: Source, binario, e comportamentali" e "Compatibilmente evoluzione BigDecimal"

Aggiunta di metodi di interfacce è binario compatibile ma sorgente incompatibile, quindi non è comunemente fatto. In generale, più ampiamente implementato un'interfaccia è, meno è probabile che siamo di aggiungere metodi ad essa. L'area JDBC è un'eccezione a questa politica e utilizza le regole di aggiornamento looser, ma che provoca problemi reali quando la gente vuole effettuare l'aggiornamento a una nuova release di JDK.

Answer 2

Si noti che l'aggiunta di nuovi metodi rompono solo compatibilità fonte, le implementazioni già compilati di Statement o ResultSet in un driver JDBC continueranno a funzionare su una più recente JDK. Solo quando si tenta di chiamare un nuovo metodo si otterrà un NoSuchMethodError.

Answer 3

Probabilmente presuppongono che i fornitori di driver di database che implementano questi metodi stanno mantenendo up-to-date con nuovi runtime Java, e che è meglio introdurre nuovi metodi utili temporaneamente rompere la compatibilità.

Naturalmente, essi potrebbero aver progettato meglio in modo che rompere la compatibilità non sarebbe necessario ...

Answer 4

Sun non garantisce la compatibilità fra le release fonte, solo la compatibilità binaria. L'esempio più comune è che il codice sorgente che contiene 'asserzione' o identificatori 'enum' non verrà compilato in JDK 1.4 (per assert) o 1.5 + (per enum), ma i file esistenti .class sarà ancora eseguito con quelle più recenti JVM.

Si può provare a utilizzare il flag -source per compilare file .java anziani sotto JVM più recenti, ma si può ancora incorrere in problemi se vi affidate ai classi JVM che sono stati modificati.