Java Data Objects è open source

Sun e le altre aziende che decidono del futuro di Java hanno approvato una nuova specifica, la Java Data Objects 2.0, pubblicandola sotto una nota licenza open source

Las Vegas (USA) - La comunità che porta avanti lo sviluppo dello standard Java ha approvato in via definitiva una controversa specifica, chiamata Java Data Objects (JDO) 2.0, che consente ai programmatori di accedere ad un database relazionale senza la necessità di conoscere SQL o altri linguaggi di query.

Il Java Community Process (JCP) ha rilasciato la nuova specifica sotto la licenza open source Apache, la stessa utilizzata dall'omonimo e famoso webserver. Una licenza che consentirà agli sviluppatori di utilizzare gratuitamente la tecnologia JDO a proprio piacimento, e questo sia all'interno di applicazioni aperte che proprietarie. La precedente versione 1.0 della specifica era invece accompagnata dalla più restrittiva Sun Community Source License.

JDO 2.0 introduce funzionalità di accesso ai database più avanzate e il supporto alla tecnologia JavaServer Faces per lo sviluppo di applicazioni Java web-based.
Il JCP Executive Committee, il comitato che decide quali specifiche devono entrare a far parte della piattaforma Java, aveva inizialmente respinto l'approvazione della JDO 2.0. Una recente petizione lanciata da JDOcentral.com, e firmata da oltre un migliaio di sviluppatori, ha tuttavia convinto il comitato a tornare sui propri passi e a dare il via libera alla nuova specifica. Tra coloro che hanno votato "no" c'è la società JBoss, la quale sostiene che JDO 2.0 è solo un piccolo aggiornamento alla specifica precedente e, oltre a ciò, rischia di creare confusione con Enterprise JavaBeans 3.0: quest'ultima specifica dovrebbe rimpiazzare JDO come metodo per la gestione della persistenza dei dati in Java.
TAG: sw
48 Commenti alla Notizia Java Data Objects è open source
Ordina
  • Sempre alle solite chiecchere da bar: .NET e' piu' bello di Java o Java e' piu' buono di .NET.
    La legge sui brevetti sul software sta passando, state solo perdendo tempo.
    non+autenticato
  • dimenticavo: so che tra i promotori del .NET ci sono anche quelli che apprezzano i brevetti sul software.
    Finalmente ora comprenderete sia cosa sono i brevetti sul software sia cosa e' Microsoft.
    Per capire che .NET non e' chissa quale piattaforma occorre essere competenti e per questo comprendo le vostre idee.
    non+autenticato

  • - Scritto da: Anonimo
    > dimenticavo: so che tra i promotori del .NET ci
    > sono anche quelli che apprezzano i brevetti sul
    > software.
    > Finalmente ora comprenderete sia cosa sono i
    > brevetti sul software sia cosa e' Microsoft.
    > Per capire che .NET non e' chissa quale
    > piattaforma occorre essere competenti e per
    > questo comprendo le vostre idee.

    Quando imparerai ad esprimerti ne riparliamo.
    non+autenticato
  • ho dato una vista veloce al sistema JDO
    (very very interesting )
    ora però mi sorge un dubbio
    non è che JDO va in conccorrenza con J2EE ?
    da quanto ho capito fa le stesse cose degli entity bean
    ma in maniera piu semplice...
    non+autenticato
  • Fa proprio concorrenza e non è supportato da nessuno dei grandi quindi è inutile! Pre questo SUN l'ha donato.
    non+autenticato
  • Mamma mia che mi tocca sentire! JDO è uno standard... Gli Entity Beans non li usa proprio nessuno in ambito industriale anche perchè se si conoscono POCO POCO ci si rende conto dei LORO LIMITI!

    JDO supera questi limiti e poi non si applica solo al settore Enterprise (J2EE) ma anche a quello desktop (J2SE).

    Esistono una dozzina di implementazioni ormai mature, provane una open source come JPOX Occhiolino e poi mi dirai!

    bye, Lvc@
    non+autenticato
  • JDO e ADO.NET sono vecchiume in quanto non astraggono totalmente il mondo relazionale rispetto a quello OO.

    Una completa astrazione e un totale disaccoppiamento si ha solo usando OR mapper. Esempi famosi sono TopLink di Oracle e l'ottimo Hibernate (open) di, guarda caso, Jboss Inc.

    http://www.hibernate.org

    Le versione 3 (in beta) surclassa anche TopLink, IMHO.

    Questi ultimi tool consentono di progettare e scrivere codice totalmente ad oggetti java classici (quindi pensando al problema) senza alcun vincolo di ereditarietà o quant'altro, definire in un file xml le logiche e i criteri di mappatura sul database, e quindi persistere o interrogare sulla base di dati tramite un linguaggio di query agnostico rispetto al db.

    Hibernate supporta 15 database diversi cui si può migrare senza toccare una linea di codice (ma solo un paio, sul file xml di configurazione)

    Nel mondo .NET d'altra parte, l'accesso al db si fonda su ADO.NET il quale, in sostanza mappa il modo relazionale su quello OO, ma a rovescio. Ossia, da una rappresentazione, ad oggetti, delle entità del db (tabelle, viste, ecc...). Vedi DataTable, DataSet, DataRelation, DataView.

    L'oscenità consiste nella necessità di progettare il codice .NET pensando alla base di dati sottostante e non al problema.

    Grazie a Dio, qualcuno sta portando hibernate su .NET, e devo dire, per quanto ho avuto modo di provare, che funziona già egregiamente:

    http://nhibernate.sourceforge.net

    Microsoft dal canto suo aveva iniziato un progetto analogo chiamato ObjectSpaces... che a vedere su MSDN sembra sparito nel nulla.
    non+autenticato
  • > Microsoft dal canto suo aveva iniziato un
    > progetto analogo chiamato ObjectSpaces... che a
    > vedere su MSDN sembra sparito nel nulla.

    mi pare l'abbiano spostato verso Avalon/WinfFS, prova a cercare nella preview dell'SDK su MSDN
    non+autenticato
  • Secondo me è il DB che deve correttamente descrivere il problema, non il modello ad oggetti. Anche perchè con un approccio MVC la parte di model è gestita dal DAO mentre la parte di logica CONTROLLER è gestita con il classico approccio ad oggetti. Insomma alla fine secondo me l'approccio
    di Ivar Jakobson risulta quello più naturale.
    Personalmente usando i DAO non ho mai avuto problemi di sorta. Qui al lavoro usiamo Firestorm DAO per la generazione automatica dei DAO e non abbiamo nemmeno il problema di perdere tempo a scrivere codice molto simile.

    Ciao

  • - Scritto da: pomy
    > Secondo me è il DB che deve correttamente
    > descrivere il problema, non il modello ad
    > oggetti. Anche perchè con un approccio MVC la
    > parte di model è gestita dal DAO mentre la parte
    > di logica CONTROLLER è gestita con il classico
    > approccio ad oggetti. Insomma alla fine secondo
    > me l'approccio
    > di Ivar Jakobson risulta quello più naturale.
    > Personalmente usando i DAO non ho mai avuto
    > problemi di sorta. Qui al lavoro usiamo Firestorm
    > DAO per la generazione automatica dei DAO e non
    > abbiamo nemmeno il problema di perdere tempo a
    > scrivere codice molto simile.
    >
    > Ciao

    Da quel che so io, la teoria ti da gli strumenti per generare da un modello ad oggetti (esempio un diagramma delle classi UML) un modello relazionale che lo soddisfi. Generalmente una cosa con gerarchie profonde e ben normalizzata porta a numerose tabelle in join 1-1.
    Un layer come hibernate può ottimizzare le singole query in funzione della "profondità polimorfa" reale richiesta dal tipo dinamico che stai tentando di interrogare.
    Un generatore di codice CRUD ti permette ciò?

    - Ti permette ottimizzazioni del tipo "lancia l'update sui soli campi variati"?

    - Include un doppio livello di caching (a livello di sessione multithreaded, e a livello applicativo)? Ne include anche solo uno di livello di cache?

    - Ti permette il versionamento nativo dei salvataggi?

    E infine, la più grossa:
    se devi cambiare DB sottostante che fai? Rigeneri tutto il codice con il tool e accedi via Abstract Factory?
    non+autenticato

  • - Scritto da: Anonimo
    > Da quel che so io, la teoria ti da gli strumenti
    > per generare da un modello ad oggetti (esempio un
    > diagramma delle classi UML) un modello
    > relazionale che lo soddisfi. Generalmente una
    > cosa con gerarchie profonde e ben normalizzata
    > porta a numerose tabelle in join 1-1.
    > Un layer come hibernate può ottimizzare le
    > singole query in funzione della "profondità
    > polimorfa" reale richiesta dal tipo dinamico che
    > stai tentando di interrogare.
    > Un generatore di codice CRUD ti permette ciò?
    >
    > - Ti permette ottimizzazioni del tipo "lancia
    > l'update sui soli campi variati"?
    >
    > - Include un doppio livello di caching (a livello
    > di sessione multithreaded, e a livello
    > applicativo)? Ne include anche solo uno di
    > livello di cache?
    >
    > - Ti permette il versionamento nativo dei
    > salvataggi?
    >
    > E infine, la più grossa:
    > se devi cambiare DB sottostante che fai? Rigeneri
    > tutto il codice con il tool e accedi via Abstract
    > Factory?

    Sicuramente è meno flessibile di un approccio come quello che hai descritto, ma su due piedi non riesco a quantificare quanto sia più conveniente utilizzarlo in termini di tempo speso a progettare una struttura che (mi sembra) abbastanza complessa. In ogni caso mi sono salvato i link e mi voglio studiare bene la cosa, non è escluso che in futuro provi a proporla.

    Ciao!
  • > non riesco a quantificare quanto sia più
    > conveniente utilizzarlo in termini di tempo speso
    > a progettare una struttura che (mi sembra)
    > abbastanza complessa.

    Tutt'altro.Occhiolino
    non+autenticato
  • Scusa ma su che base dici che JDO non astrae totalmente il modello relazionale?!?!

    bye, Lvc@
    non+autenticato
  • Ciao,
    ok, sono di parte...faccio parte dell'expert group della JSR 12 (JDO1) e 243 (JDO2).

    I vantaggi di utilizzare JDO sono molti, eccone alcuni:

    - un solo modello per applicazione e dati: quello a oggetti!
    - libertà di scelta dell'implementazione
    - possibilità di utilizzare un ODBMS in modo trasparente con gli ovvi vantaggi
    - possibilità di cambiare il DBMS (da Oracle a MySql, ecc.) senza modificare il codice
    - sistema di caching avanzato
    - utilizzo di java anche per le query

    Un consiglio: date 1 occhiata a JDO...con poche righe di codice avrete un applicazione che dialoga con il database Occhiolino

    Il sito di riferimento della tecnologia: http://www.jdocentral.com

    bye,
    Lvc@
    non+autenticato
  • molto interessante
    non+autenticato

  • > - un solo modello per applicazione e dati: quello
    > a oggetti!
    > - possibilità di utilizzare un ODBMS in modo
    > trasparente con gli ovvi vantaggi

    Per entrambi i punti il dubbio è uno soltanto: tutti quelli (e sono pochi) che hanno scelto un database orientato agli oggetti si lamentano di un denominatore comune: le applicazini sono LENTE.
    Ora, il fatto di creare una struttura ponte che maschera il database vero e proprio per consentire all'applicazione di caricare i contenuti in formato di oggetti non rischia di incorrere in problemi di performance???
    non+autenticato
  • > Ora, il fatto di creare una struttura ponte che
    > maschera il database vero e proprio per
    > consentire all'applicazione di caricare i
    > contenuti in formato di oggetti non rischia di
    > incorrere in problemi di performance???

    shhhhttt! per l'amor del cielo!
    preferisci vedere fiorire veri oodbms?
    non+autenticato
  • Scusa ma è la prima volta che sento che un ODBMS è più lento di un relazionale!!!

    Gli ODBMS sono utilizzati sopratutto in alcune nicchie come quella TELCO dove le prestazioni sono un requisito critico e dove un relazionale non ce la farebbe mai a gestire un modello di dati complesso.

    Ma non voglio innescare un flame thread sugli ODBMS...

    bye, Lvc@
    non+autenticato
  • > Scusa ma è la prima volta che sento che un ODBMS
    > è più lento di un relazionale!!!

    http://groups.google.com

    comp.databases.theory

    buona lettua
    non+autenticato
  • > > - un solo modello per applicazione e dati:
    ...
    > un denominatore comune: le applicazini sono
    > LENTE.
    > Ora, il fatto di creare una struttura ponte che
    > maschera il database vero e proprio per
    > consentire all'applicazione di caricare i
    > contenuti in formato di oggetti non rischia di
    > incorrere in problemi di performance???

    Sai qual è il punto di forza del Fortran?
    E' il linguaggio che si compila più velocemente sul PDP/11 !

    ... ma ... chi usa i PDP/11?

    I problemi di performance si risolvono ottimizzando.
    Ottimizzare vuol dire di solito inventare nuovi algoritmi, migliorare l'implementazione degli algoritmi esistenti, raffinare il codice.
    I problemi di performance si risolvono con il tempo.
    Rinunciare ad una tecnologia promettente solo perchè ADESSO è lenta è sempre la scelta sbagliata.

    Certo, oggi si possono costruire applicazioni velocissime senza usare componenti che pongono problemi di prestazioni: basta scrivere tutto ad hoc (magari direttamente in assembler) scegliendo sempre le scorciatoie più vantaggiose offerte dalle caratteristiche intrinseche della macchina, così alla fine l'applicazione sarà quella che gira più velocemente sul Pentium IV ...

    Peccato che, finita l'applicazione, nessuno userà più il Pentium IV ...

    non+autenticato
  • ignoro...
    hibernate non fà + 0 - la stessa cosa?
    non+autenticato
  • - Scritto da: Anonimo
    > ignoro...
    > hibernate non fà + 0 - la stessa cosa?

    Non conosco molto JDO... ma se si tratta di OR-mapping, Hibernate esiste proprio per quello e (IMHO) lo fà molto bene....

    Janniz
    non+autenticato
  • Hibernate è esattamente un OR Mapping, ma JDO è molto di +: definisce uno standard che può avere come implementazioni sia tool di OR mapping, ma anche ODBMS, XML repository, ecc.

    In sostanza se usi Hibernate e vuoi migrare vs. un altro prodotto devi toccare il codice + o - pesantemente con JDO il tutto avviene in modo trasparente.

    Ci sono anche altri vantaggi nell'utilizzare JDO invece che Hibernate come le query JDOQL, il sistema di caching granulare, ecc.

    Se volete un'implementazione Open Source gratuita di JDO andate qui: http://www.jpox.org ma ne esistono anche altre Occhiolino

    bye, Lvc@
    non+autenticato

  • - Scritto da: Anonimo
    > Ciao,
    > ok, sono di parte...faccio parte dell'expert
    > group della JSR 12 (JDO1) e 243 (JDO2).
    >
    > I vantaggi di utilizzare JDO sono molti, eccone
    > alcuni:
    >
    > - possibilità di cambiare il DBMS (da Oracle a
    > MySql, ecc.) senza modificare il codice

    Cioè fammi capire se mi serve una vista per una query avanzata, (per la quale non esiste altra soluzione che utilizzare una vista), e in Mysql le viste non ci sono, come viene implementata la cosa?

    non+autenticato
  • dove si trova qualche esempio su JDO ?
    grazie
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)