JVM/CLR Opzioni lingua compatibili con origine

Possiedo uno strumento di migrazione del database Java open source (http://www.liquibase.org) che sto considerando di eseguire il porting su .Net.JVM/CLR Opzioni lingua compatibili con origine

La maggior parte dello strumento (almeno da un lato della complessità) è in logica come "se si aggiunge una chiave primaria e il database è Oracle utilizzare questo SQL Se il database è MySQL utilizzare questo SQL. è chiamato e il database è Postgres usa questo SQL ".

Potrei inserire la base di codice Java e nasconderlo (manualmente e/o automaticamente), ma poiché gli aggiornamenti e le correzioni di errori alla logica precedente sono disponibili, non voglio doverli applicare a entrambe le versioni. Quello che mi piacerebbe fare è spostare tutta quella logica in una forma che possa essere compilata e utilizzata in modo ingenuo da entrambe le versioni Java e .Net.

Il codice che sto cercando di convertire non contiene alcun utilizzo avanzato di librerie (JDBC, System.out, ecc. peggio può essere progettato intorno).

Quindi quello che sto cercando è:

Una lingua in cui posso codice parti comuni di mia app e compilarlo in classi utilizzabili dalle lingue "standard" sulla piattaforma di destinazione
non aggiunge alcuna requisiti di runtime al sistema
Niente modo strano che si spaventa di distanza i potenziali contributori

I kn o Python e Ruby hanno entrambe le implementazioni per JVM e CLR. Quanto bene si adattano alle mie esigenze? Qualcuno ha avuto successo (o senza successo) usando questa tecnica per le applicazioni multipiattaforma? Ci sono dei trucchi di cui devo preoccuparmi?

fonte

2009-05-01 Nathan Voxland

Verificare il Fantom programming language. Ha una propria sintassi simile a Java/C#, ma può essere indirizzato a Java VM o .NET CLR.

La loro pagina "Why Fantom" offre una panoramica di alto livello del loro approccio alla portabilità rispetto ai linguaggi dinamici in esecuzione su una VM.

fonte

2009-05-01 18:04:22

Penso che Fan sembra essere l'opzione migliore. Jython su Java sembra non aver funzionato per un po ', mentre IronRuby su CLR è solo alla versione 0.3. Dovrò imparare più fan per sapere se questo è quello che vorrei davvero fare o se è più semplice fare la forchetta. –

L'ultima versione di Jython era a novembre, e sembra abbastanza attiva, anche se sono d'accordo sul fatto che Fantom sia più adatto in questo caso. – Yishai

Potrebbe essere un po 'di fortuna usare IKVM.NET. Non sono sicuro sul suo stato esatto, ma vale la pena provare se si è insistenti sull'esecuzione del codice Java su .NET Framework. Include un'implementazione .NET della libreria di classi base Java, quindi sembra abbastanza completa.

L'unica altra opzione che potrei suggerire è il porting del codice alla lingua J#, un linguaggio .NET completo (sebbene non di prima classe nel senso che C# o VB.NET sia). Il linguaggio è stato progettato in modo che le differenze con Java fossero minime.

fonte

2009-05-01 18:07:25 Noldorin

Ho pensato a entrambe queste opzioni, ma la mia preoccupazione per IKVM era l'aggiunta di una dipendenza, e la mia preoccupazione per J # era stata presa in giro dagli sviluppatori .net ... –

@Nathan: Abbastanza comprensibile ...anche se non penso che troverai una soluzione "ideale" nel modo in cui desideri all'interno delle tecnologie tradizionali. La maggior parte dei manutentori dei progetti porteranno l'intera base di codice in un'altra lingua (magari con l'aiuto di altri) e apporteranno modifiche/correzioni al codice parallelo su tutte le porte. Personalmente ritengo che ti imbatterai in più problemi di quanti ne valga la pena provare a utilizzare lo stesso codice base per le versioni JVM/CLR: mantenere una porta separata è più impegnativo, ma ne vale la pena nella mia mente. – Noldorin

Se stai pensando ad un approccio integrato, potresti guardare Lua.

fonte

2009-05-03 15:44:38

JVM/CLR Opzioni lingua compatibili con origine

risposta

Problemi correlati