|
MokaByte
Numero 04 - Gennaio 1997
|
|||
 |
|
|
|
|
|
|
|
|
Massimo Carli |
|
|
|
|
|
|
|
MokaByte
Numero 04 - Gennaio 1997
|
|||
|
|
|
|
|
|
|
|
|
Massimo Carli |
|
|
|
|
|
|
Le
novità del JDK1.1 Finalmente, dopo lunga attesa, il giorno 9 Dicembre
1996 è stato reso disponibile, presso il sito della Sun, il JDK
versione 1.1. Non piu' un sacco di directory sparse per l'hard disk ed
un CLASSPATH lungo un metro ma tutte le classi RMI, JDBC ed altro in un
unico classes.zip. Finalmente il mio hard disk è diventato piu'
"umano". Forse qualcuno di voi non sa cosa sono le classi RMI quelle JDBC
ecc. Lo scopo di questa serie di articoli è proprio quello di illustrare
le caratteristiche del JDK1.1 e le sue nuove (mica poi tanto date le numerose
beta e betine) potenzialità. In questo articolo farò una
panoramica di queste nuove potenzialità riservandomi, nelle prossime
puntate, di spiegare nei dettagli come si
utilizzano i numerosi package
che appaiono nel JDK1.1. Diciamo subito che le novità non sono solo
nella qualità delle classi ma anche nella quantità. Nel JDK1.02
erano presenti 8 package e 201 classi mentre nel JDK1.1 sono presenti 21
package ed addirittura 478 classi. Lo scopo di questa serie di articoli
sarà proprio la esposizione di ognuno dei package presenti, nel
miglior modo possibile. Ma vediamo in maniera generale quali sono queste
novità. Dico subito che la compatibilità tra il JDK1.1 ed
il JDK1.02 non è, purtroppo, del 100% ma del 90% ed è molto
facile capitare nel 10% in quanto, come vedremo, la gestione degli eventi
è quella parte che ha subito le maggiori modifiche che si possono
vedere anche nelle JavaBeans. Andiamo, comunque, per ordine.
Internationalization
Come sappiamo Java è un linguaggio che permette facilmente la realizzazione
di applicazioni distribuite. Con l'avvento di Internet il concetto di applicazione
distribuita si è molto allargato nel senso che le varie parti dell'applicazione
non sono residenti in diversi computer della stessa stanza o palazzo ma
possono risiedere dall'altra parte del mondo. Si rende, allora necessario
un metodo per rendere le applicazioni sensibili alle differenti culture
e linguaggi dei vari popoli. Se noi creiamo un applet costruiremo l'interfaccia
utente in italiano oppure, per avere un maggiore mercato, in inglese. Ma
se in Cina c'è un potenziale utente che non conosce l'inglese e
tantomeno l'italiano come si fa? La corrispondenza tra i nostri caratteri
ed i loro non è certo tra le più semplici. La Sun ci viene
incontro con il concetto di Internationalization. Questa è basato
sulla codifica del caratteri con Unicode 2.0 e permette l'adattamento di
testo, numeri, date ed altro al paese utente. Vedremo, proprio il prossimo
mese, come questa operazione avviene. Per ora diciamo che per gestire l'internationalization
sono stati aggiunti un nuovo package java.text, il package
java.io è stato ampliato per gestire il caricamento di font
non Unicode 2.0 ed il package java.util contiene la classe
Local che è la classe fondamentale per tutto il processo.
Sicurezza ed Applet firmati Come sappiamo Java è stato concepito
come linguaggio sicuro. La sicurezza di Java era però intesa solo
nel senso di protezione da accessi non consentiti sul client attraverso
la scrittura di files con applet. La sicurezza in Java è raggiunta
dal fatto che il linguaggio stesso è sicuro, cioè non contiene
i puntatori che possono "sporcare" zone di memoria pericolose, dal Bytecode
Verifier che verifica che all'interno del compilato non ci siano operazioni
che possono dare problemi tra cui conversioni non autorizzate o overflow,
e dalle caratteristiche del SicurityManager che non permette di caricare
gli strumenti per accedere al disco locale attraverso la rete. Con il JDK1.1
java inizia a trattare anche la sicurezza intesa come riservatezza dei
dati. Sono presenti, nella beta2, solo un sottoinsieme delle classi previste
dalla versione definitiva, ma che permettono di ottenere già buone
cose. Vi sono strumenti per la firma digitale, criptazione dei messaggi,
controllo della lista degli accessi ed altre utility. Nel proseguo del
corso tratteremo anche questi concetti spiegando il funzionamento dei nuovi
package java.security java.security.acl java.security.interfaces.
Estensioni
nell AWT (Abstract Window Toolkit) Se prendiamo il JDK1.1, ricompiliamo
le classi di un nostro lavoro ed eseguiamo il programma, noteremo una certa
differenza con la versione precedente. Se si è in ambiente Windows95
la cosa appare ancora con maggior risalto. Le finestre, i frame e gli oggetti
quali i TextField assumono una apparenza piu' professionale. Nel caso del
Windows95, infatti, tutto l'AWT è stato rifatto dalla Sun, lasciando
inalterate le principali caratteristiche (ovviamente e per fortuna). In
generale, comunque, le modifiche sono state fatte relativamente alle prestazioni.
che sono indubbiamente migliorate. Sono stati aggiunte, però, alcune
classi che rendono la programmazione più semplice. Vi sono, per
esempio, le API per la stampa, per realizzare facilmente oggetti "scrolling",
popup menu, le famose operazioni di cut&paste ma soprattutto una migliore
gestione degli eventi. Dedicheremo un'intera puntata alla gestione degli
eventi in quanto è quella che ha subito le maggiori modifiche. Se
guardiamo la documentazione ci accorgiamo, per esempio, che i metodi relativi
alle azioni del mouse (mouseUp,mouseDown,ecc) non sono più considerate
(anche se presenti per mantenere, almeno per ora, la compatibilità)
ma esiste una opportuna interfaccia che, gli oggetti che gestiscono tali
eventi, devono implementare. Vedremo, comunque, a suo tempo tali concetti.
Notiamo subito, però, la presenza di altre due package java.awt.event
e java.awt.datatransfert.
Estensioni
del Networking Come vedremo, per la gestione del networking, il JDK1.1
offre maggiore flessibilità permettendo un supporto anche per i
socket BSD. Le classi Socket e ServerSocket non sono più classi
final ma possono essere affinate. Inoltre sono stati corretti vari bug
come quello della utilizzazione di un socket a partire dall'indirizzo IP
attraverso la InetAddress. Vedremo, anche queste cose, a
suo tempo.
Estensioni
nell'IO Il package relativo alle operazioni di io non ha subito notevoli
modifiche se non quella relativa alla serializzazione che vedremo più
avanti in questo articolo. Oltre ad offrire dei metodi per la serializzazione,
vi è la possibilità di gestire un nuovo tipo di stream relativo
ai caratteri che permette il salvataggio degli stessi com 16-bit Unicode
piuttosto che come semplici byte. Questo si adatta bene con il concetto
di internazionalizzazione.
JAR
files I programmatori della Sun hanno pensato anche ad un altro problema
che si ha quando si scarica un applet dalla rete. Di solito un applet è
costituito da varie classi. La classe il cui nome mettiamo nel campo CODE
del tag APPLET è solo quella principale che utilizza altre classi
che non è detto siano tutte del JDK. Questo significa che tali classi
devono essere scaricate dal browser per poter essere interpretate. Il browser
scarica prima la classe principale, ma quando vi è il riferimento
ad un'altra classe, utilizzata dalla precedente, deve provvedere al suo
caricamento. Se questa è già presente nel JDK (o in altro
CLASSPATH) non ci sono problemi in quanto la carica localmente, ma se non
è presente deve scaricarla da cui un'altra connessione HTTP con
il server. Si hanno tante connessioni con il server, per il solo applet,
tante quante sono le classi non localmente in memoria. Si è pensato,
allora, di offrire uno strumento per raccogliere in un unico file tutto
quello che deve essere scaricato dal browser per l'esecuzione dell'applet,
suoni ed immagini comprese. Tutto questo viene salvato, con un opportuno
strumento, un un file di estensione .jar (Java ARchive). In questo modo
tutto il necessario viene scaricato con una sola connessione HTTP. A questo
punto fatto 30 si è pensato di fare 31 permettendo anche la compressione
dei dati nel file Jar ed ancora di mettere, eventualmente in esso, anche
dei meccanismi di protezioni quali chiavi elettroniche ed altro. Per esempio
il file jar viene scricato ed eseguito solamente se il browser possiede
la chiave elettronica per il suo utilizzo. Per la gestione dei file jar
esiste il nuovo package java.util.zip.
Serializzazione
Spesso capita di costruire una determinata struttura dati e di doversi
preoccupare di poterla salvare in qualche modo e di poterla ripristinare
in un tempo successivo. Da qui il problema di studiare una specie di protocollo
con cui salvare le informazioni su un file tentando talvolta pericolose
conversioni in stringhe ed utilizzazioni avventate di token vari. Con il
JDK1.1 salvare una determinata struttura dati per poterla ripristinare
successivamente è cosa naturale. Attraverso l'uso di opportune interfacce,
che non presentano metodi da sviluppare ma che servono solo a segnare o
marcare la classe che le implementa, ed utilizzando le nuove classi del
package java.io ObjectInputStream e ObjectOutputStream
,la cosa viene fatta in maniera automatica. Tutto il procedimento è
ovviamente personalizzabile ed impostato in maniera da gestire anche nuove
versioni di quello che si è salvato. Vedremo questo argomento in
maggior dettaglio in una prossima puntata.
Reflection
Per dire che cosa è la reflection dobbiamo accennare a cosa sono
i JavaBeans. Un Bean è un qualunque componente software riutilizzabile
che può essere manipolato in modo visual da un tool opportuno. Se
si conosce il VisualBasic (perdonatemi la citazione al rivale della Sun)
si nota che quando si inserisce un oggetto nel Layout appare un frame con
le proprietà, editabili o meno, dell'oggetto stesso. Un oggetto
di questi è un Bean. Se consideriamo il tool di editazione del Bean
esso serve per editarne le caratteristiche. Ma come fa a sapere il tool
quali sono queste caratteristiche, quali sono editabili, di che tipo sono
i corrispondenti valori ed altro? Nell'oggetto stesso vi devono essere
memorizzate tutte le informazioni. Nelle specifiche JavaBeans sono descritti
due procedimenti con cui il tool riconosce le proprietà del Bean.
Il primo è scontato ed è dato da opportune interfacce che
il Bean deve implementare, che prevedono la definizione di metodi che descrivono
le proprietà dei Bean stessi. Il tool, allora, chiamerà tali
metodi e vedrà subito quali sono le proprietà, quali editabili,
il loro tipo ecc. Questo metodo di introspection (introspezione) è
detto esplicito. Le risorse per poter implementare questo procedimento
sono proprio quelle relative alla reflection che dispone di strumenti per
scoprire informazioni circa i campi, i metodi ed i costruttori delle classi
caricate e di utilizzare campi, metodi e costruttori riflessi per agire,
secondo le norme di sicurezza implementate, su essi. Per completezza diciamo
che il secondo metodo di introspezione è legato alla struttura stessa
della classe. Per esempio se un campo public ha il metodo set..
significa che può essere cambiato, se ha il metodo get..
significa che può essere letto, ecc. Dalla presenza o meno di metodi
di forma standard si stabilisce la configurazione della classe e quindi
dell'oggetto stesso. Vedremo approfonditamente questi concetti in un articolo
opportuno.
JDBC
Una delle applicazioni più importanti è sicuramente quella
che permette la consultazione di DataBase remoti. Si vuole rendere possibile,
attraverso un applet per esempio, la consultazione dei valori presenti
in un DB. Questo è reso possibile dalle classi del package java.sql
che permettono di inoltrare operazioni in SQL a DB che dispongono di opportuni
driver. Il più comune è il driver ODBC. Il JDK1.1 dispone
anche del bridge JDBC-ODBC per poter dialogare con un DB che dispone dell'interfaccia
ODBC. Ovviamente è possibile utilizzare driver opportuni per ogni
tipo di DB. Vedremo come questo sarà possibile.
Inner
Classes Sappiamo che in un file .java può contenere molte classi
di cui una sola pubblica. Sappiamo anche che, con il JDK1.02, non è
possibile utilizzare classi innestate. La cosa diviene possibile con il
JDK1.1 attraverso le inner classes. Infatti è possibile limitare
ulteriormente la visibilità di una classe. E' possibile dichiarare
una classe all'interno di un blocco di un'altra classe. La classe sarà
visibile solamente all'interno del blocco stesso. Ci sono vantaggi legati
alla limitazione dello scopo della classe ma anche al fatto che la classe
definita in un blocco (quello tra { e }) vede le variabili visibili al
blocco stesso. Vedremo approfonditamente questi concetti e l'uso che se
ne può fare.
RMI
(Remote Method Invocation) Questo è forse l'argomento più
affascinante trattato previsto nel JDK1.1. Sappiamo che nella programmazione
distribuita è necessario utilizzare risorse non presenti localmente
(appunto distribuite) e che ci sono vari metodi per accedere a queste risorse.
Uno di questi metodi è l'utilizzo dei Socket. Attraverso essi è
possibile scrivere su uno stream che sarà letto da un'altra VM remota.
Java permette però, anche un procedimento simile al RPC (Remote
Procedure Call) cioè all'invocazione di procedure remote che consiste
nell'avere l'impressione di richiamare oggetti residenti localmente che
invece sono in sede remota. Il RMI è una cosa analoga al RPC con
la sola differenza di essere adattata a Java. Essa prevede l'esclusiva
comunicazione tra VM (Virtual Machine) Java con il vantaggio di poter disporre
del modello ad oggetti di Java. La RMI, che si basa sulla serializzazione,
sarà approfondita in più di un articolo per la sua importanza
e, perchè no, per il suo fascino.
Java
Native Method Interface Essa rappresenta una interfaccia di programmazione
standard per la scrittura di metodi nativi Java. Questo argomento non mi
attrae molto per il fatto che considero un punto di forza di Java la sua
portabilità. Penso quindi alla creazione di nuovi strumenti Java
piuttosto che creare librerie adatte ad una sola macchina. Comunque, questa
interfaccia descrive quelle che sono le regole per creare librerie portabili
relativamente a JVM diverse implementate su una stessa piattaforma. Oltre
a nuovi package, il JDK1.1 ha introdotto anche altri tool che vedremo nelle
puntate dedicate al RMI , al JAR ed alla sicurezza. Ho quindi descritto
le principali novità introdotte dal JDK1.1 riservandomi di descrivere
in profondità ciascuno degli argomenti descritti, nelle prossime
puntate.
 |
|
|
|
|
||
 |
MokaByte ricerca
nuovi collaboratori
|
 |
|
|
||