La nuova J2EE promette più integrazione

Sun ha svelato la nuova versione 1.3 della Java 2 Enterprise Edition, un ambiente di sviluppo ancora più focalizzato sui Web service

Palo Alto (USA) - Connettività e integrazione semplificate: questo l'obiettivo che Sun ha perseguito nello sviluppo della nuova Java 2 Enterprise Edition (J2EE) 1.3, la nuova versione dell'ambiente di sviluppo standard per la costruzione di applicazioni Java di livello enterprise.

J2EE 1.3 contiene diverse nuove funzionalità che aiutano gli sviluppatori a creare soluzioni più integrate e maggiormente connesse con il back-end.

"Queste ultime specifiche della J2EE forniscono agli sviluppatori funzionalità e flessibilità senza precedenti nella costruzione delle loro applicazioni Web di livello enterprise", ha dichiarato in un comunicato Rob Gingell, a capo del Java Community Process.
Il rinnovato ambiente di sviluppo integra una nuova architettura Java Connector che migliora l'integrazione con i sistemi eterogenei esistenti, incluse le applicazioni back-end (come ERP e CRM), verso cui offre interfacce standard.

Le nuove specifiche richiedono ora ai produttori di applicativi il supporto alle API Java Message Service (JMS) e alla stessa versione dell'Inter-ORB Protocol (IIOP), un requisito essenziale per superare i test di compatibilità. Questa imposizione risulta importante per garantire che le applicazioni possano dialogare fra loro, cosa che, secondo alcuni sviluppatori, nelle precedenti versioni della J2EE non era affatto scontata.

Con l'intento di semplificare ulteriormente la vita agli sviluppatori, Sun ha integrato nella J2EE 1.3 il supporto all'ultima versione delle specifiche Enterprise JavaBeans (EJB) e JavaServer Pages, estendendo inoltre il supporto a XML attraverso nuove API che consentono il parsing e la trasformazione di documenti XML e la traduzione di questo linguaggio per l'utilizzo con le Java Servlet e le JSP.

Le nuove specifiche EJB 2.0 - un'architettura a componenti per lo sviluppo di applicazioni enterpirse orientate agli oggetti, distribuite e maggiormente scalabili - introducono un miglior supporto al multi-transaction e alla sicurezza, inoltre dovrebbero poter consentire agli sviluppatori di concentrarsi maggiormente sulle logiche di business e meno sul processo di sviluppo.

Secondo alcuni esperti, quello che ancora manca alla J2EE è un adeguato supporto al protocollo SOAP, uno standard per rendere interoperabili i Web service sviluppati per piattaforme differenti. Pare che Sun introdurrà un primo supporto a SOAP nella prossima versione della J2EE, la 1.4, dove offrirà anche meccanismi più avanzati per la costruzione di Web service.
TAG: sw
48 Commenti alla Notizia La nuova J2EE promette più integrazione
Ordina
  • L'ennesima bufala... e farà la stessa fine...
    bye++
    non+autenticato
  • - Scritto da: bye++
    > L'ennesima bufala... e farà la stessa fine...
    > bye++
    ma bravo, adesso al posto di tanti
    esperti del settore arriva un picchiacchiello
    come te che riesce a prevedere il
    futuro dell'informatica...
    clap clap clap

    Pino Silvestre
    non+autenticato
  • e tu che ne sai di chi sono io veramente?
    non+autenticato


  • - Scritto da: bye++
    > e tu che ne sai di chi sono io veramente?

    Una buona idea ce la si puo' fare leggendo le cazzate che hai scritto ultimamente su java....

    non+autenticato
  • poveri illusi...
    non+autenticato
  • e chi ha detto che java non è concettualmente bellissimo?

    fatto sta che non è più supportato da microsoft, e voglio vedere quei CTO che avranno il coraggio di adottare una piattaforma java 100%

    detto questo, gli application server java (dynamo in testa) sono dei CHIODI!

    Bellissimo fin che vuoi per lo sviluppatore, ma Microsoft che ci rema contro e PESANTISSIMO...

    ciao ciao java...
    non+autenticato
  • - Scritto da: max
    > e chi ha detto che java non è
    > concettualmente bellissimo?

    Mah, veramente sotto alcuni aspetti è meglio .NET (molti linguaggi in primis), ma il problema è che il mercato c'è già dentro fino al collo. Java non può essere abbandonato per lo stesso motivo per cui non si può abbandonare Windows.
    non+autenticato
  • guarda, mi fa piacere sentirtelo dire...

    non è che questa egemonia microsoft mi faccia piacere...

    ma ci credi veramente...

    ho paura che ci saranno sempre meno sviluppatori java in giro, che già non abbondano... e per forza, ma chi glielo fa fare a uno di buttarsi su una piattaforma che il maggior produttore di software al mondo vede come il fumo negli occhi?

    e poi, diciamolo, non è che sia sta gran rivoluzione... molto cool la prima javaconference, carina la seconda, alla terza c'erano quattro sfigati...

    non+autenticato
  • - Scritto da: max
    > guarda, mi fa piacere sentirtelo dire...

    Sorpresa)

    > non è che questa egemonia microsoft mi
    > faccia piacere...
    > ma ci credi veramente...

    Sì, come ho già detto Java non morirà per lo stesso motivo per cui non morirà Windows. Ormai c'è, mi dispiace ma ti devi rassegnare.

    > ho paura che ci saranno sempre meno
    > sviluppatori java in giro, che già non
    > abbondano... e per forza, ma chi glielo fa

    Se mettevi "buoni" tra "sviluppatori" e "Java" e sostituivi "giro" con "Italia" ero d'accordo. Ti assicuro che dall'esperienza (non è che sia tanta, ma mi guardo molto in giro ;o) che ho io Java per lo sviluppo enterprise è molto usato e nessuno ha intenzione di abbandonarlo per seguire le bizze di MS. MS deve prima *dimostrare* che la sua piattaforma è altrettanto stabile, flessibile e sicura di Java (e quindi Passport va alle ortiche, per esempio).

    > fare a uno di buttarsi su una piattaforma
    > che il maggior produttore di software al
    > mondo vede come il fumo negli occhi?

    Molte aziende si stanno stancando della politica egemonica del "maggior produttore di software", una volta che hai un suo prodotto da qualche parte della rete (SO a parte), sei legato mani e piedi e questo non è molto bello...

    > e poi, diciamolo, non è che sia sta gran
    > rivoluzione... molto cool la prima

    Java non è una rivoluzione, è una evoluzione (IMHO). Quello che hanno fatto esisteva già, ma l'hanno integrato bene e l'hanno messo tutto in un pacchetto solo (beh, in realtà sono di più, ma hai capito...). Così come .NET è un'evoluzione di Java... (e non mi riferisco alla presunta somiglianza Java/C#)

    > javaconference, carina la seconda, alla
    > terza c'erano quattro sfigati...

    Beh, il mio CTO è andato a JavaONE qualche mese fa a mi ha riferito esattamente il contrario...

    P.S.: Vorrei farti notare che non sono un fanatico di Java, anzi il 90% delle volte preferirei usare Python, ma purtroppo Jython non va bene per quello che devo fare io...
    non+autenticato


  • - Scritto da: A.C.
    > - Scritto da: max
    > > e chi ha detto che java non è
    > > concettualmente bellissimo?
    >
    > Mah, veramente sotto alcuni aspetti è meglio
    > .NET (molti linguaggi in primis),

    Beh, java e' si un linguaggio ma e' anche una piattarforma. Ci sono compilatori per un bel po di linguaggi che producono bytecode per la JVM... C'e' in rete un sito che li indicizza tutti. Non ho il link sottomano, ma c'era solo l'imbarazzo della scelta.


    > ma il
    > problema è che il mercato c'è già dentro
    > fino al collo. Java non può essere
    > abbandonato per lo stesso motivo per cui non
    > si può abbandonare Windows.

    gia', per fortuna Sorride
    non+autenticato
  • - Scritto da: KerNivore
    > Beh, java e' si un linguaggio ma e' anche
    > una piattarforma. Ci sono compilatori per un

    Anche .NET è una piattaforma, *progettata* per supportare linguaggi diversi, mentre...

    > bel po di linguaggi che producono bytecode
    > per la JVM... C'e' in rete un sito che li
    > indicizza tutti. Non ho il link sottomano,
    > ma c'era solo l'imbarazzo della scelta.

    ... la JVM è progettata per funzionare solo con Java, infatti incastrarci dentro un altro linguaggio non è una cosa che si fa tutti i giorni, nonostante sia utilissima.
    I tecnici MS hanno collaborato con alcune università statunitensi per assicurarsi che non ci fossero grossi limiti tecnici all'inserimento dei linguaggi più assurdi: funzionali, logici, a vincoli e tutti quei linguaggi di ricerca per applicazioni particolari (non vedo l'ora di scrivere i miei programmi con un mix di Python e Haskell!).

    Conosco bene quella pagina e uso Jython.
    non+autenticato


  • - Scritto da: A.C.
    > - Scritto da: KerNivore
    > > Beh, java e' si un linguaggio ma e' anche
    > > una piattarforma. Ci sono compilatori per
    > un
    >
    > Anche .NET ?na piattaforma, *progettata*
    > per supportare linguaggi diversi, mentre...
    >
    > > bel po di linguaggi che producono bytecode
    > > per la JVM... C'e' in rete un sito che li
    > > indicizza tutti. Non ho il link sottomano,
    > > ma c'era solo l'imbarazzo della scelta.
    >
    > ... la JVM ?rogettata per funzionare solo
    > con Java, infatti incastrarci dentro un
    > altro linguaggio non ?na cosa che si fa
    > tutti i giorni, nonostante sia utilissima.
    > I tecnici MS hanno collaborato con alcune
    > universit?tatunitensi per assicurarsi che
    > non ci fossero grossi limiti tecnici
    > all'inserimento dei linguaggi pi? assurdi:
    > funzionali, logici, a vincoli e tutti quei
    > linguaggi di ricerca per applicazioni
    > particolari (non vedo l'ora di scrivere i
    > miei programmi con un mix di Python e
    > Haskell!).
    >
    > Conosco bene quella pagina e uso Jython.

    Non mi sono spiegato.... ALTRI LINGUAGGI SULLA JVM . Sono stato chiaro ora ? E ti assicuro che non era Jython, erano ALTRI LINGUAGGI (lo riscrivo, non si sa mai) e ti assicuro che erano molto piu' di quelli che girano sullo schifoso runtime di micro$oft.

    Se ti interessa *veramente* l'argomento ti cerco il link, se s' solo per dare contro a java allora lasciamo perdere. Ciao
    non+autenticato
  • - Scritto da: KerNivore
    > Non mi sono spiegato.... ALTRI LINGUAGGI
    > SULLA JVM . Sono stato chiaro ora ? E ti
    > assicuro che non era Jython, erano ALTRI
    > LINGUAGGI (lo riscrivo, non si sa mai) e ti
    > assicuro che erano molto piu' di quelli che
    > girano sullo schifoso runtime di micro$oft.
    >
    > Se ti interessa *veramente* l'argomento ti
    > cerco il link, se s' solo per dare contro a
    > java allora lasciamo perdere. Ciao

    Ho detto che la pagina la conosco: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht...
    Quanti di quei linguaggi vengono usati per sviluppare applicazioni *reali*?
    La JVM non è stata progettata per supportare linguaggi diversi, .NET sì.

    E non sto dando contro a Java. Java mi piace, ci sono alcune cosa che non mi piacciono, così come ci sono in .NET. Se non riesci a fare un confronto tra i due e a vedere quali sono le differenze senza incazzarti solo perché .NET viene da Redmond...

    Prova a leggere gli altri post prima di arrabbiarti, il tuo fegato ti ringrazierà.
    non+autenticato
  • - Scritto da: A.C.

    > Ho detto che la pagina la conosco:
    > http://grunge.cs.tu-berlin.de/~tolk/vmlanguag
    > Quanti di quei linguaggi vengono usati per
    > sviluppare applicazioni *reali*?

    Boh ! Per quanto ne so io, magari tutti !!!
    O magari nessuno !!! Tu puoi dire con certezza che la risposta e' Nessuno ?

    > La JVM non è stata progettata per supportare
    > linguaggi diversi, .NET sì.

    Puo' essere, ma dal quanto hai riportato te nell'altro post non viene data nessuna spiegazione tecninca del perche' (ammesso che crei tutte queste difficolta' e che chi l'ha scritto non fosse di parte !!!) Comunque andro a dare un'occhiata al link, magari spiega piu' nel dettaglio.

    > E non sto dando contro a Java. Java mi
    > piace, ci sono alcune cosa che non mi
    > piacciono, così come ci sono in .NET. Se non
    > riesci a fare un confronto tra i due e a
    > vedere quali sono le differenze senza
    > incazzarti solo perché .NET viene da
    > Redmond...

    Gia' ! Lo ammetto... Non essere obiettivo su tutto quello che viene da M$ e' uno dei miei limiti !!! Sorride


    > Prova a leggere gli altri post prima di
    > arrabbiarti, il tuo fegato ti ringrazierà.

    Ma se e' il mio fegato il primo ad odiare M$ ogni volta che vedo di striscio una macchina con winzozz !!!!

    Sorride

    Ad ogni modo, forse il mio post precedente sembrava piu' "incazzoso" di quanto non volesse essere !

    Ciao !


    non+autenticato
  • - Scritto da: KerNivore
    > > Quanti di quei linguaggi vengono usati per
    > > sviluppare applicazioni *reali*?
    > Boh ! Per quanto ne so io, magari tutti !!!
    > O magari nessuno !!! Tu puoi dire con
    > certezza che la risposta e' Nessuno ?

    Una frase che ripeto spesso è: "Non sono mai sicuro di niente".
    Però, dato che l'argomento mi interessa, sto attento alle voci che girano (non ho studiato approfonditamente, ma tengo le orecchie bene aperte) e da quello che sento io, l'unico linguaggio alternativo sulla JVM è Jython che comunque non riscuote grande successo.
    I limiti di gran parte di quei linguaggi sono spiegati nell'articolo che ti ho indicato.
    Ti assicuro che sarei felicissimo di vedere la JVM realmente indipendente dal linguaggio e il supporto per molti linguaggi (Python ce l'ho, adesso voglio Haskell ;o), ma Sun non ha dimostrato di essere interessata a questo aspetto della questione.

    > > La JVM non è stata progettata per
    > > supportare linguaggi diversi, .NET sì.
    > Puo' essere, ma dal quanto hai riportato te
    > nell'altro post non viene data nessuna
    > spiegazione tecninca del perche' (ammesso
    > che crei tutte queste difficolta' e che chi
    > l'ha scritto non fosse di parte !!!)

    Lo dicono praticamente tutti, dove c'è un confronto J2EE/.NET uno dei vantaggi della seconda (occhio che io parlo sempre di piattaforma) è l'indipendenza dal linguaggio.
    Comunque a me è stato detto da una persona che stimo molto e che trovo molto obiettiva. Dato che me l'ha detto in un messaggio privato non so se posso riportarlo qui, ma se ha messo qualcosa online te lo faccio sapere.

    > Comunque andro a dare un'occhiata al link,
    > magari spiega piu' nel dettaglio.

    Fammi sapere, sarei felice di continuare la discussione.

    > Gia' ! Lo ammetto... Non essere obiettivo su
    > tutto quello che viene da M$ e' uno dei miei
    > limiti !!! Sorride

    Vale anche per me, ma sto cercando di superarlo.
    "Doubt your limitations" - Bruce Eckel

    > Ma se e' il mio fegato il primo ad odiare M$
    > ogni volta che vedo di striscio una macchina
    > con winzozz !!!!

    Spero venga un giorno in cui il tuo fegato non debba più essere obbligato a vedere Win in ogni ufficio!Sorpresa)

    > Ad ogni modo, forse il mio post precedente
    > sembrava piu' "incazzoso" di quanto non
    > volesse essere !

    No prob, qui su PI è la norma. Ripeto, mi farebbe piacere continuare il discorso. Dimmi cosa pensi di quell'articolo.
    non+autenticato
  • Dai un'occhiata anche qua: http://www.objectwatch.com/issue_33.htm

    """
    At best, the Java platform supports not true language neutrality but rather language replacement. There is a big difference between language neutrality and language replacement.

    With a language neutral platform, one can choose between any number of languages, mixing and matching based on the needs of a given project. This is one of the defining strengths of the Microsoft .NET platform.

    With language replacement, you can, indeed, choose which language you will use, but once you make that choice, you can't change. Yes, you can use an Ada compiler that generates JBC, but future work will be limited not only to Ada, but to that particular compiler's notion of how the JBC will be generated from Ada. This is much more limiting than, say, being able to program only in Java. At least then you are using a popular language, and one with a number of compilers from which to choose.

    I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform. The evidence indicates that true language neutrality in the Java platform is nonexistent, and even language replacement is sparse, if it exists at all.

    In fact, it appears that Sun as a company is much less interested in language neutrality than is Simon Phipps. Sun's most recent JavaOne conference, for example, had almost 300 sessions. I could not find one that discussed the use of non-Java languages to program to the Java platform.
    """
    non+autenticato
  • Molti di coloro che postano qui
    sono convinti che Java sia il linguaggio
    usato per fare le applet nei siti web,
    non sanno un accidente della programmazione
    ad oggetti (i moduli del visual basic e le
    form sarebbero oggetti, eh?!),
    non sanno cosa voglia dire fare un software
    che:
    - si adatta alla risoluzione attuale
    - si adatta al sistema operativo attuale
    (es. un look & feel sotto Windows, ed un altro
    sotto Motif)
    - si adatta al linguaggio attuale, multilingue
    - multiutente
    - capace di utilizzare oggetti non ancora
    esistenti (do you know what's "interface"?)
    - utilizza oggetti remoti con una tecnologia
    messa di default nel kit distribuito
    (do you know what's "Remote Method Invocation"?)

    ne sono capaci di distinguere tra
    un linguaggio di scripting interpretato
    (il VBScript delle ASP) ed un linguaggio
    compilato (il Java con cui sono scritte le
    Java Server Pages), perche`magari da ASP
    andate direttamente e solo su MS SQL SERVER...

    diciamoci la verita`, parlate di Java
    senza sapere di che si sta a parlare...

    Pino Silvestre
    non+autenticato
  • Complimenti, hai centrale il reale problema di Java, pochi ne conoscono le possibilità ma molti lo criticano
    non+autenticato
  • dunque: partiamo del presupponsto ke non parteggio per nessuna tecnologia in particolare, ma, detto qsto:
    I moduli (di classe) e le form di VB sono classi (e non oggetti) a tutti gli effetti.
    La classe, come ben saprai, è un tipo di dato astratto ke descrive valori (o insiemi di valori) e le operazioni atte a trattarli. Attributi e funzioni membro (volgarmente: proprietà e metodi).
    I form VB soddisfano pienamente qsta definizione, ed infatti puoi usare il metodo costruttore fornito dal linguaggio ("guardacaso", si kiama New) per ottenere quante istanze _indipendenti_ vuoi del form disegnato.
    Es:

    Dim frmIstanza1 as frmDesignTime
    Dim frmIstanza2 as frmDesignTime

    Set frmIstanza1 = New frmDesignTime
    Set frmIstanza2 = New frmDesignTime

    frmIstanza1 e frmIstanza2 sono oggetti, in qnto istanze di classe, ed indipendenti (basta anke confrontare i loro puntatori usando le funzioni non documentate del linguaggio).
    Puoi anke realizzare form indipendenti dalla risoluzione gestendo il messaggio (ops! evento) "Resize". Esistono kilate di componenti free ke lo fanno in autmatico, se vuoi, e puoi anke scriverle in VB, subclassando (perdonami la traduzione, ma tu come diresti in italiano "subclassing"?!?) il form contenitore.

    Puoi realizzare applicazioni multi-language usando il meccanismo delle risorse, esattamente come fai con _tutti_ gli altri compilatori (mi ricordo i primi esperimenti usando il Borland C++ 3.1, altri tempi...)

    Anke con VB puoi usare oggetti non esistenti, avvalendoti dei meccanismi di late binding forniti da COM. Lo stesso discorso per le interfacce: una classe VB può implementare interfacce eretitate da altre classi, nonchè esporre + di una interfaccia. Ottimo per implementare (semplici) metodi polimorfici.
    In realtà, cmq, parlare di "VB" è improprio. Nel mondo Windoze, i servizi di cui parlo sono forniti da COM (Component Object Model), una specie di CORBA (ma inventato prima, seppure si kiamava ancora OLE), qndi pui fare qste con tutti i compilatori COM-enabled (VC++, VB, Delphi, ed anke col MS J++, nonke tanti altri), miskiando anke sottosistemi implementati con linguaggi differenti, poikè sarà COM a permettenre la comunicazione.
    Il fatto ke VB non supporti l'ereditarietà di implementazione (ma solo quella di definizione) deriva proprio dal fatto ke COM non la contempla, ed infatti VB7 (ke si basa su .NET) la fornisce, con tanto di funzionalità di override o overload (e volevo vedere!)
    In ogni caso, l'ereditarietà di implementazione può anke essere pericolosa (nelle mani sbagliate), ed infatti anke Java non la supporta nei casi di ereditarietà multipla.
    COM supporta anke l'invocazione remota (esattamente come RMI) tramite DCOM, oppure COM+, sin dal 1996.
    In quanto ad ASP, l'uso cui tu accenni è errato (io lo definisco "dei polli"), nonkè sconsigliato anke da M$. Infatti, bisognerebbe implementare il codice sotto forma di Server COM (ke sono compilati e se li scrivi bene skeggiano da paura), mentre ASP funge solo da "collante" tra IIS e il codice compilato.
    cmq, stiamo parlando di "spazzatura", visto ke COM dovrà, pian piano, "morire" a favore di .NET (tra parentesi, ci si guadagna...)
    semplici precisazioni di un amighista affranto...
    non+autenticato
  • un altro che si fuma i calzini...

    - Scritto da: pecos
    > I moduli (di classe) e le form di VB sono
    > classi (e non oggetti) a tutti gli effetti.

    ti comunico che sei *l'unico* al mondo a considerare VB (pre .NET) un linguaggio ad oggetti, neanche alla MS direbbero una cosa del genere (e infatti l'hanno buttato alle ortiche).

    > La classe, come ben saprai, è un tipo di
    > dato astratto ke descrive valori (o insiemi
    > di valori) e le operazioni atte a trattarli.
    > Attributi e funzioni membro (volgarmente:
    > proprietà e metodi).

    Queste cose le puoi fare anche in C, mettendo in una struct dei puntatori a funzioni.
    Mancano alcune cosa tipo polimorfismo, ereditarietà e magari eccezioni...

    > Nel mondo Windoze, i servizi di cui parlo
    > sono forniti da COM (Component Object
    > Model), una specie di CORBA (ma inventato

    Ma lo sai cosa stai parlando?
    http://www.omg.org/gettingstarted/corbafaq.htm

    > Il fatto ke VB non supporti l'ereditarietà
    > di implementazione (ma solo quella di
    > definizione) deriva proprio dal fatto ke COM
    > non la contempla, ed infatti VB7 (ke si basa
    > su .NET) la fornisce, con tanto di
    > funzionalità di override o overload (e
    > volevo vedere!)

    Ed infatti VB.NET è praticamente una riscrittura di VB assolutamente incompatibile con le versioni precedenti (la frase vale anche per VB6 ma togliete "riscrittura").

    > In ogni caso, l'ereditarietà di
    > implementazione può anke essere pericolosa
    > (nelle mani sbagliate), ed infatti anke Java
    > non la supporta nei casi di ereditarietà
    > multipla.

    Cambia pusher...
    non+autenticato
  • > Mancano alcune cosa tipo polimorfismo,
    > ereditarietà e magari eccezioni...

    Stavo per rispondegli io ma mi hai preceduto.
    Una volta ad un colloquio alla domanda: hai mai avuto esperieza di programmazione ad oggetti? Mi ha risposto C++, java, VB...non gli ho riso in faccia per educazione...

    >
    > > Nel mondo Windoze, i servizi di cui parlo
    > > sono forniti da COM (Component Object
    > > Model), una specie di CORBA (ma inventato
    >
    > Ma lo sai cosa stai parlando?
    > http://www.omg.org/gettingstarted/corbafaq.ht

    Credo di no.

    >
    > > Il fatto ke VB non supporti l'ereditarietà
    > > di implementazione (ma solo quella di
    > > definizione) deriva proprio dal fatto ke
    > COM
    > > non la contempla, ed infatti VB7 (ke si
    > basa
    > > su .NET) la fornisce, con tanto di
    > > funzionalità di override o overload (e
    > > volevo vedere!)
    >
    > Ed infatti VB.NET è praticamente una
    > riscrittura di VB assolutamente
    > incompatibile con le versioni precedenti (la
    > frase vale anche per VB6 ma togliete
    > "riscrittura").

    Secondo me ha copiato le frasi da qualche libro o sito...

    > > In ogni caso, l'ereditarietà di
    > > implementazione può anke essere pericolosa
    > > (nelle mani sbagliate), ed infatti anke
    > Java
    > > non la supporta nei casi di ereditarietà
    > > multipla.
    >
    > Cambia pusher...

    Infatti in java puoi estendere una classe da un'altra solo una volta, ma puoi implementare quante volte vuoi...

    Ciao
    Luca
    non+autenticato
  • spiacente di deludervi: tipicamente fumo cose migliori dei calzini... Sorride
    detto qsto, prima di definirmi "uno che copia dai libri" ci avrei pensato su un pokino di +...
    VB6 supporta molte delle caratteristiche della OOP: certo non tutte (ed infatti non l'ho sostenuto), ma dovete anke considerare quale sia il target del prodotto.
    Detto qsto:
    - con una struct in C puoi simulare solo gli attributi (tramite i suoi membri), ma non le funzioni membro (metodi). A meno di non usare dei membri ke in realtà contengono dei puntatori a funzione. In ogni caso, l'idea mi sembra un po' "tirata per i capelli". Il concetto di "classe", infatti, evolve proprio qllo di "struttura" (infatti sono entrambi dei tipi), aumentandone l'usabilità grazie soprattutto alla proprietà dell'incapsulamento.
    Infatti, se in C++ usi un puntatore ad istanza anzikè un oggetto, ti ritrovi a fare i conti con il deferenziatore, esattamente come se in C usassi un puntatore a struttura. In ogni caso, il C non sa nemmeno cosa sia la OOP: C e C++ sono due linguaggi differenti ke hanno in comune una minimale sintassi di base. Le similitudini sono state create "ad arte" affinkè i programmatori C vedessero nel C++ il naturale successore del loro linguaggio "preferito". Ringraziamo per qsto Bjarne e il comitato ANSI.
    - In VB6 puoi utilizzare una forma primitiva di polimorfismo: se definisci una classe astratta (basta marcare la classe PublicNotCreatable in un server COM) e successivamente ne implementi le classi derivate, puoi scrivere funzioni (e qndi anke metodi) ke accettano generike implementazioni della classe base. Certo, non è l'overload ke hai a disposizione in C++ (ma anke altri linguaggi, tra i quali anke VB7), ma è pur sempre una forma primitiva di polimorfismo.
    - VB (dalla versione 5) dispone solo dell'ereditarietà di definizione non tanto per "carenze del linguaggio", qnto per il fatto ke la tecnologia su cui si basa (COM) non prevede l'ereditarietà di implementazione, punto e basta. Puoi usare anke C++ con ATL, la musica non cambia. Ora ke VB dovrà appoggiarsi al framework .NET, il quale ha caratteristike (e target, leggi "clienti"), differenti il linguaggio è stato modificato all'occorrenza. In pratica, M$ ha SEMPRE evoluto VB in funzione del mercato.
    consiglio per "Luca": mi sembra proprio ke tu non abbia kiaro il concetto di "ereditarietà multipla"... Magari sarebbe il caso ke studiassi un po' di +, e ke nel frattempo non dicessi baggianate.
    senza rancore.
    non+autenticato
  • - Scritto da: pecos
    > spiacente di deludervi: tipicamente fumo
    > cose migliori dei calzini... Sorride

    prova, prova...Sorpresa)

    > VB6 supporta molte delle caratteristiche
    > della OOP: certo non tutte (ed infatti non
    > l'ho sostenuto), ma dovete anke considerare
    > quale sia il target del prodotto.

    "I moduli (di classe) e le form di VB sono classi (e non oggetti) a tutti gli effetti."

    Come fanno ad essere classi a tutti gli effetti e non supportare polimorfismo ed ereditarietà?

    > - con una struct in C puoi simulare solo gli
    > attributi (tramite i suoi membri), ma non le
    > funzioni membro (metodi). A meno di non
    > usare dei membri ke in realtà contengono dei
    > puntatori a funzione. In ogni caso, l'idea

    Beh, e quando ho un puntatore a funzione non posso chiamarlo come se fosse una funzione normale?
    Se scrivo:
    struct {
    int (*somefunc)(void);
    }
    posso chiamare:
    struct.sumefunc();
    dov'è il problema?

    > grazie soprattutto alla proprietà
    > dell'incapsulamento.

    L'incapsulamento non è una proprietà delle classi ma uno stile di programmazione OO che prevede di non accedere direttamente ai dati ma modificarli solo tramite metodi.

    > struttura. In ogni caso, il C non sa nemmeno
    > cosa sia la OOP: C e C++ sono due linguaggi

    Mai sentito parlare di Gtk+? E' (o meglio, contiente) un intero framework OO scritto completamente in C.
    Certo, non hai l'aiuto del linguaggio, ma si può fare, quindi abbiamo insegnato al C che cos'è la OOP.

    > (ma anke altri linguaggi, tra i quali
    > anke VB7)

    VB.NET è un linguaggio *diverso* da VB6 esattamente come dicevi tu per C/C++.

    > modificato all'occorrenza. In pratica, M$ ha
    > SEMPRE evoluto VB in funzione del mercato.

    E' questo il problema di VB (pre .NET) è un'accozzaglia di roba aggiunta qua e là...

    > consiglio per "Luca": mi sembra proprio ke
    > tu non abbia kiaro il concetto di
    > "ereditarietà multipla"... Magari sarebbe il
    > caso ke studiassi un po' di +, e ke nel
    > frattempo non dicessi baggianate.
    > senza rancore.

    Prima di dire agli altri cosa studiare sarebbe bene che sapessi che le interfacce sono state inventate proprio per ovviare ai *grossi* problemi che crea l'ereditarietà multipla. E' stata scelta una soluzione più semplice perché quella più complessa portava più danno che profitto (infatti le interfacce ci sono anche in C#).

    Saluti vado a cena. A domani.
    non+autenticato


  • - Scritto da: A.C.
    > - Scritto da: pecos
    >
    > > (ma anke altri linguaggi, tra i quali
    > > anke VB7)
    >
    > VB.NET è un linguaggio *diverso* da VB6
    > esattamente come dicevi tu per C/C++.
    >

    Anzi, VB.NET sembra essere più che altro una brutta copia del C++ 3.0 (prima dei template, del RTTI e di tante altre cose sfiziose).

    > > modificato all'occorrenza. In pratica, M$
    > ha
    > > SEMPRE evoluto VB in funzione del mercato.
    >
    > E' questo il problema di VB (pre .NET) è
    > un'accozzaglia di roba aggiunta qua e là...
    >
    > > consiglio per "Luca": mi sembra proprio ke
    > > tu non abbia kiaro il concetto di
    > > "ereditarietà multipla"... Magari sarebbe
    > il
    > > caso ke studiassi un po' di +, e ke nel
    > > frattempo non dicessi baggianate.
    > > senza rancore.
    >
    > Prima di dire agli altri cosa studiare
    > sarebbe bene che sapessi che le interfacce
    > sono state inventate proprio per ovviare ai
    > *grossi* problemi che crea l'ereditarietà
    > multipla. E' stata scelta una soluzione più
    > semplice perché quella più complessa portava
    > più danno che profitto (infatti le
    > interfacce ci sono anche in C#).
    >
    > Saluti vado a cena. A domani.
    non+autenticato
  • Se posso permettermi, un consiglio: se vuoi un linguaggio semplice, agile, potente, coerente, multipiattaforma, integrato col SO (qualsiasi SO... gira anche su Palm), ben supportato, liberamente disponibile, Open Source, seriamente ad oggetti e con qualche altra cosina simpatica prova qui: www.python.org

    P.S.: Sarà supportato in .NET e lo puoi usare anche da Visual Studio: www.activestate.com
    non+autenticato
  • > Mancano alcune cosa tipo polimorfismo,
    > ereditarietà e magari eccezioni...

    Stavo per rispondegli io ma mi hai preceduto.
    Una volta ad un colloquio alla domanda: hai mai avuto esperieza di programmazione ad oggetti? Mi ha risposto C++, java, VB...non gli ho riso in faccia per educazione...

    >
    > > Nel mondo Windoze, i servizi di cui parlo
    > > sono forniti da COM (Component Object
    > > Model), una specie di CORBA (ma inventato
    >
    > Ma lo sai cosa stai parlando?
    > http://www.omg.org/gettingstarted/corbafaq.ht

    Credo di no.

    >
    > > Il fatto ke VB non supporti l'ereditarietà
    > > di implementazione (ma solo quella di
    > > definizione) deriva proprio dal fatto ke
    > COM
    > > non la contempla, ed infatti VB7 (ke si
    > basa
    > > su .NET) la fornisce, con tanto di
    > > funzionalità di override o overload (e
    > > volevo vedere!)
    >
    > Ed infatti VB.NET è praticamente una
    > riscrittura di VB assolutamente
    > incompatibile con le versioni precedenti (la
    > frase vale anche per VB6 ma togliete
    > "riscrittura").

    Secondo me ha copiato le frasi da qualche libro o sito...

    > > In ogni caso, l'ereditarietà di
    > > implementazione può anke essere pericolosa
    > > (nelle mani sbagliate), ed infatti anke
    > Java
    > > non la supporta nei casi di ereditarietà
    > > multipla.
    >
    > Cambia pusher...

    Infatti in java puoi estendere una classe da un'altra solo una volta, ma puoi implementare quante volte vuoi...

    Ciao
    Pippo
    non+autenticato
  • - Scritto da: pecos
    > dunque: partiamo del presupponsto ke non
    > parteggio per nessuna tecnologia in
    > particolare, ma, detto qsto:
    > I moduli (di classe) e le form di VB sono
    > classi (e non oggetti) a tutti gli effetti.
    > La classe, come ben saprai, è un tipo di
    [... serie di cazzate...]
    > Dim frmIstanza1 as frmDesignTime
    > Dim frmIstanza2 as frmDesignTime
    >
    > Set frmIstanza1 = New frmDesignTime
    > Set frmIstanza2 = New frmDesignTime
    [...ancora cazzate...]

    - Innanzitutto, in visual basic e`comunque
    possibile allegramente
    frmDesignTime.show
    utilizzando la medesima "classe" (B000rp,
    scusa ma ci vuole troppo fegato a chiamarla
    cosi`) sia come classe "statica" che come
    classe "dinamica"; OGNI form di VB
    in questo modo fa le veci del
    singleton pattern, e senza che il programmatore
    ci possa fare niente

    - non e`possibile estendere una form
    e continuare ad usarla come oggetto;
    non c'e`ereditarieta`;

    - non e` possibile ISTANZIARE un modulo
    di visual basic; quelli che tu sei pronto
    a chiamare "metodi" ed attributi sono in realta`
    funzioni e variabili globali perche`
    globale e`la loro visibilita`(scoping) nel
    progetto, senza poterli legare a nessuna
    istanza

    - la remote method invocation e`supportata
    in Java in maniera nativa, cioe`senza
    pagare gabelli per i runtime alla Sun, mentre
    il compilatore Visual Basic e`tutt'altro che
    gratuito, quindi se per te questo e`un
    dettaglio trascurabile non credo sia possibile
    parlare oltre dell'argomento...

    Pino Silvestre
    non+autenticato
  • ammettetelo... non ha avuto il successo che sun si aspettava

    e ora che microsoft non lo supporta più...

    io il mio tempo su java non ce lo butto...
    non+autenticato
  • - Scritto da: max
    > ammettetelo... non ha avuto il successo che
    > sun si aspettava

    vero, Sun pensava che si diffondesse anche sui client

    > e ora che microsoft non lo supporta più...

    Microsoft sta per morire
    ammettetelo... si stanno accorgendo tutti che vuole solo i soldi
    (in realtà secondo me sta cambiando strategie, ma volevo rompere le balle)

    > io il mio tempo su java non ce lo butto...

    leggiti gli altri messaggi...
    non+autenticato
  • letto gli altri messaggi...

    perchè dovrei investire su java?
    se microsoft non lo supporta più, mi spiace dirlo, ma possiamo pure intonare un requiem...

    e cosa si è fatto di serio con java finora?

    i giochini sul web?
    dynamo?
    oracle lo supporta, e allora?

    java è pesante come un elefante, chissenefrega della portabilità, vogliamo le PRESTAZIONI!

    non ha convinto nessuno
    non+autenticato
  • Ma avete solamente una vaga idea di che cosa state dicendo?
    Lavoro su java da un annetto e ho partecipato a progetti per assicurazioni, compagnie telefoniche, portali internet.
    Non dico i nomi per correttezza ma sono aziende veramente grosse...
    I loro server sono tutti o solaris (con qualche macchina linux ultimamente) con applicativi scritti in java, con utilizzo massiccio de servlet e jsp
    Sviluppo con Asp la mia azienda ne fa, ma per quanto ne so sono tutte robe molto più piccole, se non altro perchè un server nt non ha certo l'affidabilità che servirebbe
    Certo che se usi il pc per navigare e vedere le applet e sviluppi siti internet per la drogheria sotto casa ti può sembrare che java non lo usi nessuno...
    non+autenticato
  • Meno male cominciavo a sentirmi come Don Quijote...
    non+autenticato
  • ne riparliamo tra un anno eh?

    voglio vedere quel CTO che sceglierà di andare controcorrente, rischiando il posto se java sparirà nel nulla... come accadrà sicuramente...

    perchè credi che vengano fatte le scelte tecniche, per la loro bellezza concettuale?

    illuso...
    non+autenticato
  • - Scritto da: max
    > letto gli altri messaggi...

    > perchè dovrei investire su java?
    > se microsoft non lo supporta più, mi spiace
    > dirlo, ma possiamo pure intonare un
    > requiem...

    > e cosa si è fatto di serio con java finora?

    La IBM ha fatto varidi programmi ad uso interno delle banche ad esempio.

    > java è pesante come un elefante,
    > chissenefrega della portabilità, vogliamo le
    > PRESTAZIONI!

    Guarda che non esiste solo windows per fortuna.
    non+autenticato
  • e chi ha fatto la scelta?

    dei direttori tecnici che volevano salvarsi il culo, prendendo quello che era assolutamente di "tendenza"

    all'epoca.., ora vedremo...
    non+autenticato

  • - Scritto da: max
    > letto gli altri messaggi...

    allora sei un completo idiota

    > perchè dovrei investire su java?
    > se microsoft non lo supporta più, mi spiace
    > dirlo, ma possiamo pure intonare un
    > requiem...

    non sai di cosa parli, che vuoi che importi se m$ supporti o meno java, un dato di fatto e' che la JVM creata ma m$ e' una porcata

    > e cosa si è fatto di serio con java finora?

    applicazioni enterprise distibuite, ejb con supporto delle transazioni, generazione automatica delle query SQL e gestione db con ejb CMP, controllo di qualunque DB di rete con la tecnologia JDBC, kernel dei cellulari ecc... se conosci java e le tecnologie di contorno puoi scrivere applicazioni scalabili di *qualunque* tipo, che girano su qualunque piattaforma e venderle per centinaia e centinaia di milioni.
    La maggior parte delle aziende di un certo peso ti ridono in faccia quando gli parli di tecnologie microsoft (visual basic, asp, c#) ma cambiano attegiamento appena nomini SUN e IBM (fai 2 colloqui a Roma o Milano)   

    > java è pesante come un elefante,
    > chissenefrega della portabilità, vogliamo le
    > PRESTAZIONI!

    ?? elefante java???? forse intendi le GUI , sul lato server java e' una scheggia (vedi benchmark di Resin su www.caucho.com o altri)


    > non ha convinto nessuno

    dovresti smettere di fumare il crack
    non+autenticato
  • Hmmmm...
    Forse non hai mai sentito parlare SERIAMENTE di J2EE e di Application Server.
    Vatti a fare un giro su www.theserverside.com e poi ne riparliamo.

    ...Altro che .NET

    Bye
    non+autenticato
  • peccato che per fare girare meraviglie come dynamo (java 100%) serva una base hardware che neanche la nato...

    gli application server java sono dei chiodi!!!

    dio ce ne scampi...
    non+autenticato
  • Ma dai, mandate a cagare Java & Sun e passate tutti a .NET !!!
    non+autenticato
  • Sei un idiota
    non+autenticato
  • Concordo!
    non+autenticato
  • Sì, hai proprio ragione.
    Buttiamo alle ortiche una piattaforma affermata, testata, sicura e diffusa da più di cinque anni su cui molte aziende hanno incentrato il loro business, spendendo carriole di soldi...
    non+autenticato


  • - Scritto da: A.C.
    > Buttiamo alle ortiche una piattaforma
    > affermata, testata, sicura e diffusa da più
    > di cinque anni su cui molte aziende hanno
    > incentrato il loro business, spendendo
    > carriole di soldi...

    ... E sopratutto buttiamo alle ortiche un linguaggio di programmazione che almeno prova a essere realmente portabile, a favore del solito sistema di nicchia M$ che di nicchia e` e di nicchia rimane, pur se piu` diffuso di qualunque altro software. Del resto, se non fosse di nicchia, non sarebbe incompatibile con il resto dell'universo.
    non+autenticato
  • - Scritto da: Mentore Siesto
    > ... E sopratutto buttiamo alle ortiche un
    > linguaggio di programmazione che almeno
    > prova a essere realmente portabile, a favore
    > del solito sistema di nicchia M$ che di
    > nicchia e` e di nicchia rimane, pur se piu`
    > diffuso di qualunque altro software. Del
    > resto, se non fosse di nicchia, non sarebbe
    > incompatibile con il resto dell'universo.

    Eh eh... volevo dirlo anch'io, ma siccome ogni volta che vedo scritto .NET aggiungo www.go-mono.org e www.gnu.org/projects/dotgnu non mi è sembrato il caso... ;o)
    non+autenticato
  • E non dimentichiamoci che Oracle - leader mondiale dei database professionali - ha scelto Java come linguaggio di programmazione (leggi stored procedure) per i suoi database e le ultime versioni sono j2ee compliant. Non so se passera' a C#, ma penso di no!!!!
    non+autenticato
  • E non dimentichiamoci che molte aziende si stanno stancando di MS...
    non+autenticato