Newsgroup: it.comp.java
Titolo: Nuove features per Java

Ho appena letto questo articolo
(
http://www.onjava.com/pub/a/onjava/2002/07/31/java3.htm
, datato 31 Luglio)
e mi trovo abbastanza in accordo con l'autore... voi che ne pensate?
Java ha veramente bisogno di tutte queste modifiche (io per la maggior parte
risponderei
si soprattutto per la questione che tutto dovrebbe derivare da Object..) ?
Ci sono altre modifiche da fare? Cosa reputate inutile?
ciao
Rhymes
--------------------------------
Inviato via 
http://usenet.libero.it

 e mi trovo abbastanza in accordo con l'autore... voi che ne pensate?
Sembra che il link non funzioni...
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Please contact the server administrator, 
webm...@oreillynet.com
 and inform
them of the time the error occurred, and anything you might have done that
may have caused the error.
More information about this error may be available in the server error log.


scusate il link è .html e non .htm
http://www.onjava.com/pub/a/onjava/2002/07/31/java3.html



Secondo me eliminare l'AWT non e' sufficiente: bisogna eliminare _anche_ Swing e passare
ad un protocollo di dialogo con la GUI molto + disaccoppiato, con una metafora e un
funzionamento simile a quello del mondo web. XUL ne e' un buon esempio.
Per il resto concordo abbastanza.
Ciao,
    Bruno.
---
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
|
| Membro del JUG Torino - 
http://www.jugtorino.it
| 

 funzionamento simile a quello del mondo web. XUL ne e' un buon esempio.
Ah, se potessi ti nominerei seduta stante "Java restyling chief architect"
:) Non so voi ma a me nessuna delle due GUI ufficiali di Java è mai piaciuta
sia per la difficoltà intrinseca dei layout che anche solo per il feeling
estetico :(
Quali altre librerie grafiche buone ci sono pe Java?
Ciao


 wrote in message
news:3e01aa33...@news.it.colt.net...


 estetico :(
La difficoltà intrinseca dei Layout?!?
Per quanto riguarda il feeling estetico a me piace molto (questione di
gusti). Tieni conto comunque della completa flessibilità del Look And
Feel....


Feel....
Niente a che vedere con altre GUI ma come hai detto tu è questione di
gusti
Rhymes


Hai acceso la mia curiosità... Quali altre GUI?

Hai acceso la mia curiosità... Quali altre GUI?
Delphi, QT, wxWindows
Rhymes

 pensate? 
L'idea di eliminare i tipi primitivi non mi suona. Tutto sono tranne che 
performance-ad-all-costs, ma non ho tutta questa fiducia negli 
ottimizzatori a compiletime - per quel tipo di cose.
Anche, la frase "XML is clean, easy to edit, easy to parse, and easy to 
debug." non mi potrebbe trovare in maggior disaccordo. XML ha senso solo 
dove c'e' (tanta) struttura, ma vuoi mettere la leggibilita', e la minore 
predispozione ad errori di
property1=...
property2=...
...
con 
<?xml version="1.0" encoding="ISO-8859-1"?>
<java:blahblahbla xmlns:java="
http://java.sun.com/blablahblah
" 
xmlns:javax...">
<property name="property1">...</property>
<property name="property2">...</property>
...
</java:blahblahblah>
e per cosa poi? L'idea di scrivere *tutto* in XML fa il paio con quella di 
usare *un* linguaggio di programmazione per tutto. E' naive - e purtroppo 
come tante cose naive una di quelle che ha un periodo di intenso successo 
prima che le persone si accorgano che e' una cavolata.
Addirittura, vuole usare XML come sintassi per la serializzazione di 
oggetti.. da pazzi. :)
Buttare AWT? E' l'unica GUI che uso :) Swing e' troppo lenta e ancora piena 
di bug, imho. Buttar via entrambe per una soluzione tipo SWT non sarebbe 
una cattiva idea. La GUI e' *il* posto dove la velocita' di risposta conta 
terribilmente. Una GUI dev'essere _sia_ efficiente _che_ esteticamente 
piacevole, oggidi'. 
Alcune note su File e l'I/O sono semplicemente diverse idee di design: File 
come "oggetto" File e' semplicemente un'astrazione diversa del "File" java 
(che incapsula un pathname: ed effettivamente avrebbero potuto chiamarlo 
meglio); e l'idea di attivare Buffered I/O per default e' un design 
centrato su file-based stream, invece che - come l'idea originale - su 
stream generici in cui quello file-based e' solo un caso particolare. 
Un'idea di stream un po' all programmatore C, insomma.
Per il classpath/classloader - tutto sta a conoscere il meccanismo e ad 
applicarlo alla lettera. L'unica cosa che aggiungerei al classloader e' un 
meccanismo per richiedere a runtime *quale* classpath sta usando per 
caricare ogni specifica classe - e' una black-box troppo black oggidi' :); 
e magari rendere accessibile l'implementazione del meccanismo di base, 
file-based. Per il resto, ogni problema di ClassLoader deriva solo dal 
fatto che il programmatore non ha capito bene come funziona.
Per il resto, sono idee accettabili.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Come gia' mi dissero tempo fa, dai un'occhiata anche a XUL per avere un'idea di cosa
intendo per "cambio di metafora". Anche SwingML, seppur basata su Swing :-) e troppo
sbilanciata sul web, implementa lo stesso shift di prospettiva: da una GUI embedded
nell'applicazione (e nel caso di java anche nel linguaggio) a una GUI esterna e
disaccoppiata completamente.
XUL:      
http://www.xulplanet.com/
SwingML:  
http://swingml.sourceforge.net/index.html


XUL:      
http://www.xulplanet.com/
Interessante! Anche se da quanto ho capito devi avere installato
Mozilla. Per ora non so che farmene dato che le mie conoscenze
dell'XML rasentano lo zero :( Ad ogni modo non sembra male
Rhymes


Lo sto provando per un progetto di cui non posso parlare :-), trattasi comunque di un
sistema distribuito a componenti, ma e' ancora presto per dire qualcosa. Comunque, se jxul
e' veramente morto, sto pensando di scrivermi un motore io: quello di Mozilla e' veramente
incasinato, e il componente se ne porta dietro altri n :-)



Vabbe', dai, e' oggettivamente incasinato, basta passare fra le varie release di Tomcat
per farsene un idea. Decisamente da rifare, troppo difficile da usare: si possono ottenere
gli stessi risultati con una complessita' inferiore.


si possono ottenere gli stessi risultati con una  complessita' inferiore. 
Come? ;-)



Con un design + semplice, come dice giustamente l'articolista, "piu' a misura d'uomo che
di macchina". Be speaking! Se avessi il tempo... no, farei decisamente qualcos'altro,
lascio l'osso alla Sun :-)


 farei decisamente qualcos'altro, lascio l'osso alla Sun :-)
Guarda, dico quel che dico anche perche' di classloader ne ho scritti, per 
un motivo o per l'altro, un bel po' - e non mi e' mai venuto in mente un 
meccanismo migliore - che avesse, beninteso, la stessa generalita' di 
applicazione. Ora, puo' benissimo essere che sia impedito io - e non mi ci 
sono mai effettivamente *concentrato* - pero' questo mi lascia un po' 
perplesso davanti ad affermazioni lapidarie come "si possono ottenere gli 
stessi risultati con una complessita' inferiore" come quella 
dell'articolista, ammenoche' non mi si dica un come concreto, ben definito 
e che possa sostituire quello originale in tutti i casi in cui viene usato. 
:)
In mancanza, anch'io lascio volentieri l'osso alla Sun :)


 JBoss :), ma meno facili per chi deve usarlo.
Ops! credo di conoscere il tizio ;-D...
Comunque di casini ne ho avuti di più su weblogic... :-/

 Comunque di casini ne ho avuti di più su weblogic... :-/
Oh, non c'e' dubbio - le stramaledizioni che gli ho dato quando se ne sono 
arrivati con xerces contenuto nel server - e non aggiornabile, e 
naturalmente una versione con un bel po' di bug *esattamente* nelle feature 
che usavamo noi.. pero' per il classloading, no, non ho avuto nessun 
problema. 



Per molti sistemi tanta di quella generalita' e' sprecata: sicuramente esiste un modo per
scrivere quelle classi in modo che possano essere sfruttate a "livelli di potenza"
diversi.


 problema.
I problemi che ho avuto io erano proprio sui classloader (e sono quelli che
fanno perdere un sacco di tempo, se poi si trovasse anche documentata la
gerarchia dei classloader non sarebbe male: in quel caso non fu immediato
trovare lo schema, tanto che adesso ho provato a cercarlo e dinuovo non lo
trovo).
In particolare... era un casino impacchettare gli EAR. Pare che per gli EAR
il classloader della web application fosse figlio di quello degli EJB-JAR...
(o viceversa... non mi ricordo più) Comunque il fatto è che in un ear ci
beccavamo un bel po' di classcast exception e/o classnotfoundexception
quando in realtà l'applicazione era impacchettata correttamente (secondo gli
standard j2ee). Mi sembra che, alla fine, abbiamo dovuto rimuovere le
remote/home interfaces dal war, per far funzionare le cose...

Se non erro... il petstore bisogna "adattarlo" a weblogic per poterlo
deployare, e in questi adattamenti rientra proprio un pasticcio sulle
home/remote interface. Almeno cosě mi ha riferito un collega... (ma di piů,
non so...)

 Delphi, QT, wxWindows
GTK (un paio di progetti, se non ricordo male).
E considerando che GNOME2 sarà la GUI di Solaris... ;-)
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.ods.org/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

E considerando che GNOME2 sarà la GUI di Solaris... ;-)
Sarà ma io preferisco QT e KDE ma come abbiamo già detto...questione
di gusti :)
Rhymes

 sfruttate a "livelli di potenza" diversi.
Questo e' vero. Pero' se ci pensi, i meccanismi introdotti dai vari Tomcat, 
Jboss, eccetera sono proprio "specializzazioni". "metti il tuo jar li', e 
sara' caricato automaticamente"; "il tuo jar viene caricato da un 
classloader che e' figlio dello zio della cugina del classloader di 
sistema, ma solo se sta sul filesystem"; :) eccetera. E non e' che siano 
riuscite troppo bene. E la mia assunzione e' che la gente che ha scritto 
quei pacchetti sia *in gamba*. 
Certamente ci sono casini: ad esempio, ho appena risolto un pasticcio 
piccolo piccolo dovuto al fatto che il DriverManager JDBC usa il 
classloader di sistema per caricare classi, e nel "riconoscere" un driver 
testa se il classloader che lo ha caricato e' lo stesso che ha caricato se 
stesso (!) - mentre io ne uso uno dinamico. Ma ancora, qui il problema e' 
che chi ha scritto il DriverManager non ha documentato 'sta cosa..
E l'idea che java possa dinamicamente agganciare classi al runtime a me 
piace parecchio. Comunque l'idea di rivedere il meccanismo e' interessante. 
Ci pensero' un po' su. Ad esempio, come vorresti specificare "umanamente" 
dove trovare le classi, mantenendo allo stesso tempo la possibilita' di 
modificare 'sto posizionamento a runtime?


 war, per far funzionare le cose... 
Eh, infatti, spesso il problema a cui mi riferivo e' proprio quello: chi 
sviluppa un pacchetto/framework inventa un meccanismo di classloading, o 
definisce una gerarchia) e _non lo documenta_. "documenta" imho in casi 
come questi significa mettere cartelli grandi cosi' con scritte cubitali in 
rosso - dato che il meccanismo di classloading e' alla base di tutto.
