Alfonso Maruccia

Java SE 7, il primo figlio di mamma Oracle

La societÓ di Larry Ellison ha annunciato la disponibilitÓ di una nuova major release per la popolare virtual machine Java, la prima della nuova gestione. Promessi numerosi miglioramenti, ma giÓ affiorano i primi bug

Roma - Come già ampiamente anticipato nelle scorse settimane, Oracle ha finalmente terminato il lavoro sulla nuova release della virtual machine acquisita da Sun: Java Platform, Standard Edition 7 (Java SE 7) arriva dopo anni dalla prima distribuzione di Java SE 6 e rappresenta il risultato finale di un gran lavoro di sviluppo da parte di Oracle e della community - nonché il parto travagliato di una sequela infinita di polemiche, accuse e controaccuse scambiate fra Oracle e il mondo intero.

Java SE 7 è la prima versione di Java gestita internamente da Oracle, e rappresenta il risultato finale di 9494 bugfix, 1966 migliorie, 9018 aggiornamenti, 147 build e quattro "specification request" susseguitisi nel corso del tempo.

Tra le principali caratteristiche della nuova release, Oracle ci tiene a sottolineare le modifiche al linguaggio di programmazione per "incrementare la produttività dello sviluppatore e semplificare i task di programmazione più comuni", il supporto migliorato ai linguaggi dinamici (Ruby, Python, JavaScript), una API "multi-core ready", un'interfaccia di I/O completa capace di dialogare estesamente con il file system della macchina, nuove funzionalità di sicurezza e di networking, maggiore supporto all'internazionalizzazione tramite Unicode 6.0, l'aggiornamento di numerose librerie.
Per arrivare alla distribuzione di Java SE 7, Oracle si è servita estensivamente di due strumenti di gestione comunitaria della virtual machine che in questi mesi hanno generato una serie senza fine di polemiche e scontri al calor bianco: OpenJDK Community e Java Community Process.

Superato lo scoglio fondamentale della major release, la sfida è ora mantenere aggiornata la virtual machine contro i bug che fanno la loro comparsa a brevissima distanza dal rilascio dell'ultima revisione del codice: Apache - che con Oracle ha un rapporto più che burrascoso - ha scovato un baco nel compiler di Java SE 7 in grado di mandare in crash la virtual machine a soli 5 giorni di distanza dalla disponibilità della nuova release.

Alfonso Maruccia
Notizie collegate
  • AttualitàJava, Apache abbandonaApache Software Foundation e Oracle sempre pi¨ verso la rottura. ASF voleva una risposta chiara, ora la governance di Java Ŕ pi¨ inceerta. La foundation lascia il comitato esecutivo
  • BusinessJava, uno statuto per OpenJDKOracle e IBM pubblicano quella che dovrebbe essere la nuova "carta fondativa" della rinnovata collaborazione tra i due colossi del software. In gioco c'Ŕ il destino del codice sorgente di Java.
  • AttualitàJava, Oracle vuole rifondare la communityIl colosso dei database annuncia importanti cambiamenti in vista di un nuovo inizio per la community di Java. Con tanto di maggiore trasparenza e partecipazione di tutti nel processo di standardizzazione
  • TecnologiaE venne il tempo di Java 7La piattaforma di sviluppo Oracle si aggiorna dopo cinque anni di complicata gestazione ma compie solo un mezzo passo in avanti. Pronta la Release Candidate di una major solo a metÓ
59 Commenti alla Notizia Java SE 7, il primo figlio di mamma Oracle
Ordina
  • Aho,

    credevo sti fenomeni di fanatisco esistessero solo tra tifosi di calcio, adepti di Scientology o fanatici Apple/Microsoft/AntiApple/GNu/etc.

    Non immaginavo che anche per un linguaggio di programmazione il livello del coinvolgimento emotivo arrivasse al rispodere a opinioni e commenti su un oggetto con attacchi alla persona (sei un troll, sei una checca, evidentemente non sei uno sviluppatore, non sai, sei ignorante, etc etc), che pena.

    Tornando ai fatti e agli oggetti.

    La storia del "pseudocodice efficiente come un compilato" si e' sentita tante volte. Eppure mi consta che tutti gli ambienti runtime e le librerie su cui si poggiano le implementazioni di Java siano scritte...ehmm.. in C. Ci sara' un motivo se Tomcat non e' scritto interamemte in Java ?

    Ora sia chiaro: lungi da me dire che al mondo tutto dovrebbe essere compilato in codice nativo, per l'80% del layer "applicativo" questo non si giustifica; ma dire che la JVM e' efficiente come il codice nativo mi sembra un po' esgerato.

    Veniamo alle fature del linguaggio: si sostiene spesso che il java e' realmente un linguaggio a oggetti. Scusate ma per me che vengo dallo SmallTalk un linguaggio a oggetti e' qualcosa in cui "a = b+1" invia all'oggetto b il messaggio "+" con parametro "oggeto intero di tipo uno".. eccetera.

    Mi chiedo: In Java posso forse definire una classe "complex" in cui sommo un numero complesso a un altro con la sintassi "a = b+c" ? Potrei sbagliare ma mi pare di no. Non serve a niente ? Possibile, questione di opinioni, qualcuno (tra quelli che crearomo SmallTalk) disse che era possibile programmare a oggetti in assembler volendo, e' questione di comodita' e convenzioni... "syntactic sugar".

    Dunque, Java non e' un linguaggio a oggetti "Puro", come qualsiasi linguaggio ragionevole scende a compromessi, "int a" non e' un oggetto, gli operatori non possono essere ridefiniti, non esiste erediterieta' multipla (altro "syntactic sugar", daccordo, rileggere prima). Se scende a compromessi perche' alcune cose sono state sacrificate e altre no ?

    Per me fare si che quella classe "complex" definisca l'operatore "+" come un template e non come un metodo a binding dinamico e' importante ai fini delle performance. Provate a implementare una DFT e poi venitemi a raccontare che i template non fanno differenza. Provate ad usare lo stesso codice con cui avte scritto la DFT per fare una NTT (che e' una DFT che usa i campi di galois invece che i numeri complessi) e poi venitemi a dire che avreste lo stesso risultato con una Interface.

    Ora sia chiaro: sto facendo degli esempi su un ambito applicativo specifico. Nessuno nega che per scrivere la business logic di un applicativo gestionale Java potrebbe essere la scelta migliore (li va in competizione con .NET ASP e porcherie simili e... e anche facile vincereA bocca aperta ), ma se dovessi scrivere una interfaccia utente partendo da zero *OGGI* la scriverei in JavaScript e la fare girare in un browser (eh si.... Google docet), quando scrivo software scientifico lo scrivo in C++ (e si, uso solo STL e al piu' le API strictly posix di C), se dovessi scrivere un *server*... perdonatemi... ho bisogno di cosette come kqueue(), i posix threads, la shared memory tra processi... cose un po' piu' a basso livello di quello che puo' fare l'interprete JVM.

    Nel sostenere che Java e' strategicamente morto non auguro a nessuno di restare senza lavoro (che poi... non sono senza lavoro nemmeno i programmatori Cobol, che hanno tutta la mia stima, se non altro eprche' il primo "lavoro informatico" che feci fu in Cobol e mi ci vollero degli psicofarmaci per riprendermi.. quindi bravo chi riesce a sopravvvivere). Intendevo dire che se fosse diventato un oggetto "Vendor independent" avrebbe avuto la possibilita' di diventare uno "standard".

    Gli standard, perdonatemi, non devono appartenere a nessuno, per definizione.

    A.
  • Mi permetto di dissentire su alcune cose.

    "ma se dovessi scrivere una interfaccia utente partendo da zero *OGGI* la scriverei in JavaScript e la fare girare in un browser"
    Mai sentito parlare di GWT? Scrivi in Java e compili in Javascript. No non è stato fatto per il motivo che pensi tu (incapacità dei programmatori di usare un altro linguaggio). Un codice scritto in Javascript è poco manutenibile e più il progetto si amplia e più le cose peggiorano. Questo costa e tanto.
    No, se parti "*OGGI*", usi GWT.

    "se dovessi scrivere un *server*.." Mai sentito parlare di JBOSS? Se scrivi in server, lo scrivi in Java per buone ragioni. Se scrivi un serverino che serve solo a te, scrivile con quello che ti pare. In Java fai prima.
    Tra l'altro sempre Google offre soluzioni in Java (e non solo) che sono scalabili al massimo. In pratica se segui la loro filosofia (e le loro restrizioni) hai un applicativo che può lavorare indifferentemente con 1 persona o con tutta l'umanità. E google probabilmente ne sa più di te.

    Passiamo alla ridefinizione degli operatori con un esempio banale:
    A, B e C sono matrici. Senza passare da trasformate di Fourier o quant'altro:
    se scrivo A = B + C ridefinendo l'operatore + per la classe matrice... il risultato dove lo metto? in A, B o C?
    Se lo metto in A, ho fatto una new non necessaria che porterebbe il programma a richiedere troppa memora con matrici grandi.
    Se metto il risultato in B o in C vado ad alterare matrici che non dovrei toccare.
    E' meglio quindi rinunciare a ridefinire gli operatori (che tra l'altro può essere elegante, ma sicuramente NON NECESSARIO) e usare delle classi e dei metodi con nomi espliciti.

    Per quanto riguarda il calcolo scientifico mi sembra di ricordare un nome... Matlab... che dimostra che anche in questo caso il liguaggio scelto dipende dalle esigenze e non dall'ambito.

    Alcuni criticano Java dicendo che non è un linguaggio ad oggetti puro. E' vero, ma affinchè sia una critica ci dovresti spiegare perché dovrebbe esserlo.

    Infine analizziamo le performance:
    http://www.javaworld.com/javaworld/jw-02-1998/jw-0...
    http://keithlea.com/javabench/

    Un giorno scoprirete che Java non è interpretato... forse.
    non+autenticato
  • - Scritto da: poiuy
    > A, B e C sono matrici. Senza passare da
    > trasformate di Fourier o
    > quant'altro:
    > se scrivo A = B + C ridefinendo l'operatore + per
    > la classe matrice... il risultato dove lo metto?
    > in A, B o
    > C?

    L'esempio mi ha fatto ricordare un'altra cosa di java della quale non capisco la ragione: l'assenza della const-correctness esplicita.

    Forse per questo in molti linguaggi esistono i tipo "const reference".

    L'operatore "+" non modifica l'lvalue e restituisce una reference a un nuovo oggetto (che viene assegnata atomicamente all'oggetto a), l'operatore "+=" somma in place. Sono due cose diverse.

    Questa assenza ha conseguenza anche gravi: immagina che un oggetto contenga una lista di stringhe e che un metodo debba ritornare questa lista, in assenza di una esplicita dichiarazione const ho due scelte: copia la lista e ritornarne la copia (evviva l'efficienza!), oppure restituire l'oggetto lista che dovrebbe essere "nascosto" nell'oggetto e non modificabile da fuori (evviva l'incapsulamento).

    Anche in questo non e' che C++ sia perfetto (devo per forza fare un getter che mi restiuisce una "const std::list <std::string> &", sintatticamente sarebbe molto piu' pulito, nella mia opinione, avere una dichiarazione di visibilita' decicata che dice "questo attributo e' accessibile dall'interfaccia in read only").

    Non critico Java per non essere un linguaggio ad oggetti "puro", come ho detto i linguaggi ad oggetti puri hanno probabilmente poca utilita' pratica (l'ultimo che ho visto era appunto SmallTalk).

    Java fa delle scelte che non lo rendono un puro linguaggio OOP, C++ ne fa altre che hanno lo stesso effetto da questo punto di vista.

    Le scelte di C++ le capisco perche' giustificate dal voler avere un linguaggio comunque "compilabile" (analoghe furono le scelte fatte da oggetti come Dylan, Ada90, eccetera), quelle di Java non le capisco, that's it.

    A.
  • "Questa assenza ha conseguenza anche gravi: immagina che un oggetto contenga una lista di stringhe e che un metodo debba ritornare questa lista, in assenza di una esplicita dichiarazione const ho due scelte: copia la lista e ritornarne la copia (evviva l'efficienza!), oppure restituire l'oggetto lista che dovrebbe essere "nascosto" nell'oggetto e non modificabile da fuori (evviva l'incapsulamento)."

    In questo esempio specifico puoi procedere in vari modi:
    ritorni un iteratore (e quindi non puoi modificare i valori, il remove dell'iteratore può essere inibito).
    Oppure wrappi la lista e ritorni una lista non modificabile (esistendo l'interfaccia sia List che Collection puoi wrappare senza problemi). Non server crearsi il wrapper, ci sono i metodi di Collections.

    " sintatticamente sarebbe molto piu' pulito, nella mia opinione, avere una dichiarazione di visibilita' decicata che dice "questo attributo e' accessibile dall'interfaccia in read only"
    In java esiste la parola chiave final che tra le altre cose fa anche questo. Se scrivo "static final String MY_CONSTANT = "PIPPO"" questa è una stringa leggibile da tutti ma non modificabile.
    Il problema di final è che rende immodificabile il riferimento. Quindi se rendo final una Collection (List se vuoi) in realtà la posso modificare, ma non posso assegnare al riferimento una altra collection.

    Per quanto riguarda l'esempio delle matrici, quello che ti è sfuggito è che allocare una nuova matrice A solo per fare A = B + C è pericoloso (oserei dire concettualmente scorretto). Le matrici possono essere molto grosse e per fare i calcoli potrei aver bisogno solo di una matrice di appoggio. Per cui è molto meglio qualcosa tipo MatrixOperations.sum(A,B,Result) dove Result può essere utilizzata per tutte le operazioni di cui ho bisogno.
    Questo caso mostra come la ridefinizione di "+" sembra una buona idea, ma non lo è.

    Le scelte del C++ sono in linea con la filosofia: posso fare tutto (compreso quello che non dovrei fare). La fiolosofia Java è: non puoi fare alcune cose, perché non devi. Ecco perché volutamente non c'è l'ereditarietà multipla, la ridefinizione degli operatori, la garbage collection e altre cosette. Perché questa è la loro proposta di come si programma.
    In pratica hanno ritenuto che alcune cose permesse dal C++ portassero a più danni che benefici. La ridefinizione degli operatori porta più danni che benefici. Stessa cosa per l'ereditarietà multipla.
    non+autenticato
  • - Scritto da: poiuy
    > In java esiste la parola chiave final che tra le
    > altre cose fa anche questo. Se scrivo "static
    > final String MY_CONSTANT = "PIPPO"" questa è una
    > stringa leggibile da tutti ma non
    > modificabile.

    On oggetto dichiarato final non lo modifichi nemmeno nella classe stessa, e' un concetto diverso da fare un "cast a const" (che non e' un cast, e' solo "questa e' un'ombra del mio oggetto che e' read only").


    > Per quanto riguarda l'esempio delle matrici,
    > quello che ti è sfuggito è che allocare una nuova
    > matrice A solo per fare A = B + C è pericoloso
    > (oserei dire concettualmente scorretto).

    Se quello che vuoi fare e' la somma di B+C e mettere il risultato in un altro oggetto che e' A non e' ne pericoloso ne scorretto: e' l'unico modo.

    Se quello che vuoi fare e' fare la somma in place: A += B.

    > Questo caso mostra come la ridefinizione di "+"
    > sembra una buona idea, ma non lo
    > è.

    No, se rispetti la semantica. Certo se non la rispetti (come con qualsiasi overload, non solo degli operatori).

    Fatto sta che l'overloadability degli operatori non e' un fatto a se stante, e' semplicemente consistenza OO: un operatore e' un metodo come gli altri.

    > Le scelte del C++ sono in linea con la filosofia:
    > posso fare tutto (compreso quello che non dovrei
    > fare).

    Questo e' vero solo per chi programma in C usando un compilatore C++.

    Anche in Java puoi essere cosi' cane da lasciare tutto public, mettere tutti i metodi in una classe e magari la maggior parte delle variabili membro nella classe stessa: otterrai quello che fa chi sta provando la prima volta a scrivere un programma in C o Pascal (lasciando piu' roba possibile nel namespace globale).

    Nessun linguaggio di programmazione puo' difendere il programmatore da se stessoSorride

    > La fiolosofia Java è: non puoi fare alcune
    > cose, perché non devi. Ecco perché volutamente
    > non c'è l'ereditarietà multipla, la ridefinizione
    > degli operatori, la garbage collection e altre
    > cosette. Perché questa è la loro proposta di come
    > si
    > programma.

    Ok, e questione di opinioni.

    > In pratica hanno ritenuto che alcune cose
    > permesse dal C++ portassero a più danni che
    > benefici. La ridefinizione degli operatori porta
    > più danni che benefici. Stessa cosa per
    > l'ereditarietà
    > multipla.

    De gustibus.... a me continua a non piacere.

    (Che poi sia chiaro: ci sono cose di Java che mi piacciono tantissimo come i costruttori che possono chiamarsi in cascata, la gestione delle eccezioni che e' sintatticamente pulitissima e altro...).

    A.
  • "No, se rispetti la semantica. Certo se non la rispetti (come con qualsiasi overload, non solo degli operatori).

    Fatto sta che l'overloadability degli operatori non e' un fatto a se stante, e' semplicemente consistenza OO: un operatore e' un metodo come gli altri."

    Niente di più sbagliato.
    Per fare la somma tra A e B non serve assolutamente allocare memoria. Puoi usare un buffer. E di sicuro non vuoi scrivere in A.
    Ergo A = B + C con overloading dell'operatore '+' può portare a scrivere formule carine e che mangino una marea di memoria.
    Né l'operatore '+' né l'operatore '+=' portano a scrivere su un buffer il risultato della somma tra A e B. Certo puoi copiare in C (buffer) A e poi fare C += B. A questo punto perché non fare allora dei metodi espliciti che dicono quello che fanno?
    A questo punto vedo come è facile cadere in tentazione scrivendo C = A + B invece che qualcosa del tipo: MatrixOperations.sum(A,B,C).
    Con una piccola differenza, che se lo fai con l'ultima versione non allochi alcuna memoria per fare l'operazione di somma.
    Se hai una sommatoria, con la seconda versione usi solo la memoria già allocata, con l'overloading hai bisogno di una ulteriore matrice ad ogni somma. Se A e B sono matrici grosse, le formule che scriveresti con l'overload rischiano di occupare troppa memoria.
    non+autenticato
  • - Scritto da: poiuy
    > Per fare la somma tra A e B non serve
    > assolutamente allocare memoria.

    Ti garantisco che se vuoi fare una operazione tra due oggetti di un tipo X e il risultato (anche esso di tipo X) non deve sovrascrivere uno dei due oggetti ti serve della memoria per salvare il risultato.

    Che poi questa memoria sia statica, sia sullo stack o sia nello heap... da qualche parte il risultato lo devi mettere.

    Se invece credi che gli "oggetti" possano solo essere nello heap, i "buffer" e i tipi nativi solo sullo stack... eccetera... credo che tu dia per scontate delle cose che appartengono solo a Java, non al resto del mondo.

    #include <complex>

    void cippalippa(const complex &a, const complex &b)
    {
    complex c = a+b;
    std::cout << c << std::endl;
    }

    ... pregasi compilare e cercare nel codice assmebler una chiamata a mallocSorride

    A.
  • "Ti garantisco che se vuoi fare una operazione tra due oggetti di un tipo X e il risultato (anche esso di tipo X) non deve sovrascrivere uno dei due oggetti ti serve della memoria per salvare il risultato."

    Ti garantisco che se vuoi fare 10 operazioni tra 2 oggetti di tipo X, non ti serve allocare 10 volte la memoria per il risultato.

    Cosa che non puoi fare con l'overloading degli operatori.
    non+autenticato
  • - Scritto da: poiuy
    > Ti garantisco che se vuoi fare 10 operazioni tra
    > 2 oggetti di tipo X, non ti serve allocare 10
    > volte la memoria per il
    > risultato.
    > Cosa che non puoi fare con l'overloading degli
    > operatori.

    Sono certo che conosci molto bene i compilatori di tutti i linguaggi che consentono l'overload degli operatori per affermarlo.

    Nel mio deve esserci un bug:

    #include <complex>
    #include <vector>

    double cippa2(std::vector <std::complex<double> > &a)
    {
        std::complex <double> tmp(0.0, 0.0);
        for(std::vector <std::complex<double> >::const_iterator i=a.begin(); i != a.end(); ++i)
            tmp = tmp + *i;
        return arg(tmp);    
    }

    ... l'ho chiamata con un vettore di 100000 elementi sotto dtrace e nada de nada... non mi ha fatto nessun malloc().

    Inutile dire che comunque e' scritta da cane, la forma sensata sarebbe stata tmp += *i; (che e' un altro operatore overloaded).

    A.
  • E quando fai tmp = tmp + *i; cosa pensi che succeda?
    Chiedi allo stack lo spazio per una ulteriore tmp. Questo non è necessario.
    E se tmp invece di occupare poca memoria, ne occupa tanta?
    il comando malloc() non c'entra niente. Quello serve per chiedere memoria all'heap.

    Non a caso ho parlati di matrici. E più volte ho specificato di grandi dimensioni.
    non+autenticato
  • Ti rispondo più precisamente, altrimenti non ci intendiamo.
    Se A e B sono matrici di grandi dimensioni, nello stack non ci stanno.
    Non solo: se A entra di poco nello stack, A + B fallisce perché non c'è abbastanza memoria.

    Fare C = A + B implica cadere in questa limitazione.

    Non che sia un grosso problema da risolvere. Rimane dubbia però l'utilità di aver ridefinito il "+" sulle matrici, quando è sconsigliabile usarlo.
    non+autenticato
  • Le inefficienze della pseudocompilazione
    Gli obrobri del linguaggio in se (dov'e' l'ereditarieta' multipla? e i template? e il binding ibrido?)
    La falsa portabilita' (se un programma non ha bisogno di una GUI lo scrivi in C++ ISO usando solo STL ed e' la cosa piu' portabile del mondo, se ha bisogno di una GUI la *vera* portabilita' te la scordi)
    Il fatto che non esistano implementazioni veramente open
    Il fatto che non sia uno standard vendor-independent

    Adesso che e' in mano a Oracle poi diciamocelo: Java e' morto. Non lo sa e cammina ancora ma e' uno zombie, dategli quattro anni di tempo e si decompone.

    A.
    -----------------------------------------------------------
    Modificato dall' autore il 30 luglio 2011 18.43
    -----------------------------------------------------------
  • - Scritto da: Pinco Pallino

    > ...

    Beh, che dire, io non ho mai amato il c++ perché è un finto linguaggio di programmazione ad oggetti; non ha un runtime che si possa dire tale e che di fatto lo rende un linguaggio statico, cosa che ne limita molto le possibilità (prova a fare inspection sugli oggetti C); è abbastanza facile rompere la compatibilità binaria modificando le interfacce delle classi; eredita dal C molte caratteristiche primitive che avevano senso nei primi anni '70.

    Potrei continuare. Però, ciò che conta è e quello che scegli è uno strumento adatto al lavoro che fai. E questo può esserlo il c++ come Java. E java se java è uno dei linguaggi più usati al mondo (informati meglio la prossima volta) vuol dire che in molti lo hanno preferito.
    FDG
    10946
  • Un linguaggio ha due vite, quella di mercato, dove il Java è più vivo che mai, e quella tecnologica, dove è morto ormai da tempo.

    Il mercato arriva in ritardo, quindi mi aspetto di sentire parlare del Java ancora per molti anni... ciò non toglie che sia un linguaggio tecnologicamente obsoleto.

    Le alternative esistono, basta usarle.
    non+autenticato
  • > Le alternative esistono, basta usarle.

    Per esempio ?
    non+autenticato
  • - Scritto da: Andreabont

    > Un linguaggio ha due vite, quella di mercato,
    > dove il Java è più vivo che mai, e quella
    > tecnologica, dove è morto ormai da tempo.

    Beh, lo sviluppo del linguaggio è normale che ad un certo punto si stabilizzi. Le idee alla base di Java sono quelle e nessuna evoluzione le può modificare.

    > ciò non toglie che sia un linguaggio
    > tecnologicamente obsoleto.
    >
    > Le alternative esistono, basta usarle.

    A quali ti riferisci?
    FDG
    10946
  • Certo Java non é perfetto. Peró se sono riusciti a farci applicazioni potenti e ben strutturate tanto schifo non fa. Se la maggior parte del software che costituisce il backend delle aziende é stato scritto in Java un motivo c'é.

    Non mi preoccupano i troll che danno Java per morto. Primo perché conosco altri linguaggi di programmazione, secondo perché so quanto sofware e quanto lavoro basato su Java sta andando avanti ancora oggi e terzo perché il COBOL era stato dato per morto all'inizio degli anni ottanta eppure sta ancora in circolazione.

    Scommetto che non ti interessa sapere che anche Microsoft si é dovuta arrendere. Per attirare clienti nei servizi cloud di Azure ha dovuto migliorare il supporto di Java e ha introdotto Hadoop.

    Forse veramente Java morirá nei prossimi anni, ma le aziende per sostituirlo stanno considerando Scala, Groovy e altri linguaggi. Non certo C++. Da come parli mi sa che rischi piú te di rimanere senza lavoro in quanto obsoleto che Java di sparire dalla circolazione.

    http://www.corp-corp.com/it-jobs-trend-2011Q1.aspx
    non+autenticato
  • - Scritto da: Javista
    > e terzo perché il COBOL era stato
    > dato per morto all'inizio degli anni ottanta
    > eppure sta ancora in
    > circolazione.

    E rimarra' vivo e vegeto per moltissimo tempo ancora Sorride
    non+autenticato
  • >
    > E rimarra' vivo e vegeto per moltissimo tempo
    > ancora
    > Sorride

    Non esageriamo. Magari trovi ancora lavoro con il COBOL, ma ti fai due palle grandi come una casa a forza di fare manutenzione.
    non+autenticato
  • - Scritto da: Javista
    > Certo Java non é perfetto. Peró se sono
    > riusciti a farci applicazioni potenti e ben
    > strutturate tanto schifo non fa.

    Lasciamo perdere. E' da anni che mi scontro con applicazioni java sul lavoro. E' da poco che il tipico pc aziendale riesce a far girare queste applicazioni in modo semidecente. E dato che tipicamente il parco macchine di un azienda è costituito da pc con windows non si capisce la necessita di utilizzare un linguaggio multi piattaforma.

    Java ha senso sui cellulari, java a senso sul web ma un' applicazione di contabilità aziendale in java è una emerita cazzata sia 15 anni fà quando per farla girare semidecentemente serviva un pc super, sia oggi.
    .poz
    206
  • > Lasciamo perdere. E' da anni che mi scontro con
    > applicazioni java sul lavoro. E' da poco che il
    > tipico pc aziendale riesce a far girare queste
    > applicazioni in modo semidecente. E dato che
    > tipicamente il parco macchine di un azienda è
    > costituito da pc con windows non si capisce la
    > necessita di utilizzare un linguaggio multi
    > piattaforma.
    >

    I software SAP funzionano da anni, cosí come eclipse. Se il tuo capo compra le applicazioni dall'azienda pizza e fichi non te la puoi prendere con Java.

    > Java ha senso sui cellulari, java a senso sul web
    > ma un' applicazione di contabilità aziendale in
    > java è una emerita cazzata sia 15 anni fà quando
    > per farla girare semidecentemente serviva un pc
    > super, sia
    > oggi.

    Anche il pizzicagnolo adesso é capace di mettersi su un server Linux in una rete windows risparmiando parecchio. Se tu non ne sei capace non ti lamentare.
    non+autenticato
  • - Scritto da: Javista

    > I software SAP funzionano da anni

    Un esempio di usabilita', di friendlyness, di apertura e soprattutto di strategi di difesa dal vendor lock-inSorride

    Gli utenti che usano SAP sono notoriamente molti felici, i CIO lo sono davvero... per i primi 4-5 anni.

    A.
  • quando la mamma si accompagna a molti partner, poi e' sempre difficile dare un cognome al bastardo...
    non+autenticato
  • Bacchettone ?
    non+autenticato
  • - Scritto da: vaadin
    > Bacchettone ?

    no, ironico.
    non+autenticato
  • Non hai aggiunto niente di interessante. Si tratta del bug giá citato nell'articolo. Solr e Lucene vanno in crash perche l'ottimizzazione della VM crea problemi al loro sistema di indicizzazione. Non mi stupisce che una azienda che si basa su quei prodotti dica di non usare Java, spingono perché venga accelerato il lavoro per risolverlo.

    Gli altri intanto possono benissimo iniziare a provarlo per familiarizzarsi con le nuove funzionalitá
    non+autenticato
  • - Scritto da: vaadin

    > Gli altri intanto possono benissimo iniziare a
    > provarlo per familiarizzarsi con le nuove
    > funzionalitá

    Faccio un paragone: JBoss AS 7: una rivoluzione. Figo! Bello! Ma non mi sognerei mai di proporlo in produzione. M'è bastato poco per accorgermi di un primo bug. Ciò non toglie che continuerò a studiarlo e a sperimentare, in attesa del 7.1.

    E questo vale per qualsiasi altro strumento software. Se puoi permetterti qualche problema, aggiorna subito. Altrimenti aspetta.
    FDG
    10946