English (UK)

Tratto da programmazione.it scritto da Antonino Salvatore Cutrì 

Scott Guthrie, General Manager del .NET Framework presso la Microsoft Developer Division, ha annunciato che dopo aver analizzato i feedback ricevuti sia dai clienti che dalla comunità di sviluppatori, l’azienda ha deciso di rilasciare il codice sorgente di riferimento del suo .Net Framework sotto la Microsoft Reference License.

Essa può essere considerata come una specie di licenza open source a "sola lettura", infatti il codice coperto da questa licenza può solo essere visionato, ma ne è impedita qualunque modifica o ridistribuzione. Ad ogni modo con questa mossa, che fa parte degli sforzi di Microsoft mirati a fornire la massima trasparenza sulle sue tecnologie, gli sviluppatori avranno la possibilità non solo di conoscere in maniera più approfondita la piattaforma .NET, potendone studiare finalmente la composizione interna, ma grazie ad una funzionalità integrata nel futuro Visual Studio 2008, sarà possibile anche effettuare il debugging delle applicazioni passando in maniera trasparente dal proprio sorgente a quello del .NET Framework per vedere esattamente cosa succede e come si comportano le API di Microsoft.

Scott Guthrie ha inoltre aggiunto che il piano iniziale di Microsoft prevede il rilascio del codice sorgente delle seguenti tecnologie completamente commentato: NET Base Class Library (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, ecc.);

  • ADO.NET (System.Data);
  • ASP.NET (System.Web);
  • Windows Forms (System.Windows.Forms);
  • Windows Presentation Foundation (System.Windows).

A questi seguiranno altri package più avanti nel corso del prossimo anno. L'accesso al sorgente del .NET Framework inoltre servirà a rassicurare gli sviluppatori, che si sentiranno sicuramente più garantiti avendo la possibilità di visionare il codice delle tecnologie che utilizzano, senza contare che questa mossa del colosso di Redmond ha anche una valenza educativa visto che permette non solo di vedere come è stato scritto il codice del frame work, ma anche di imparare le tecniche di programmazione usate all'interno di Microsoft ed impiegarle nei propri progetti. Il rilascio del codice sorgente con la possibilità di visionarlo o scaricarlo sarà permesso più avanti durante il corso dell'anno, quando verranno rese disponibili le release definitive del .NET Framework 3.5 e di Visual Studio 2008.

Tratto da programmazione.it scritto da Davide Panceri

John O'Conner mostra in un articolo sul sito ufficiale di Sun Microsystems come usare le caratteristiche di Java SE 6 per la creazione di applicazioni estensibili, in grado cioé di aggiornarsi con nuove funzionalità senza bisogno di modificare alla radice l'applicazione originaria, ad esempio riscrivendo e ricompilando il codice sorgente.

In effetti, se si aggiungono nuove librerie ad un programma Java è possibile utilizzarle in modo relativamente semplice, accodando alla variabile classpath il percorso di installazione; Java 6 ha introdotto l'API ServiceLoader, che permette di definire un'interfaccia service provider, che viene successivamente implementata in file aggiunti all'applicazione in seguito.

Naturalmente i dettagli richiedono una lettura attenta dell'articolo, che presenta due esempi: il primo è un editor di testo a cui si può aggiungere poi un dizionario o un correttore ortografico nuovo, creato da altri sviluppatori o dagli utenti stessi del programma; l'altro esempio, molto noto, è l'IDE NetBeans, al quale si possono aggiungere svariati moduli a seconda del bisogno.

A quanto sembra, questo contributo di O'Conner potrebbe essere l'ultimo da dipendente Sun, stando almeno al post di SDN Program News del 27 settembre, che parla di tagli dovuti a riduzione dei costi per motivi di bilancio e altre amenità del genere.

Questo racconto tratto da Roumen è troppo bello per non riportarlo.

How to kill a dragon with various programming languages

This funny text comes from Ibon from the dream team who got it from a Spanish blog. There's a beautiful princess, prisoner in the highest tower of a castle, guarded by a mighty dragon, and a fearless knight must rescue her… This is how each language would manage to rescue the princess from the hands of the dragon

  • Java - Gets there, finds the dragon, develops a framework for dragon anihilation with multiple layers, writes several articles about the framework… But doesn't kill the dragon.
  • .NET - Gets there, sees the idea of the Java developer and copies it. Tries to kill the dragon, but the monster eats him.
  • C - Arrives, looks down at the dragon, pulls out his sword, beheads the dragon, finds the princess… And ignores her to see the last checkins of linux kernel cvs.
  • C++ - Creates a basic needle, and gathers funcionality until he has a complex sword that he can barely understand… He kills the dragon, but gets stuck crossing the bridge because of memory leaks.
  • COBOL - Arrives, sees the dragon and thinks that he is too old to kill a monster that big and rescuing the princess, so he leaves.
  • Pascal - He prepares for 10 years to create a dragon anihilation system… When the moment comes, he discovers the program can only take lizards as an entry.
  • VB - Builds a dragon destruction weapon based on several components, jumps to the back of the dragon and in the most critical time he discovers that the sword works only on rainy nights…
  • PL/SQL - Gets data from other dragon slayers, creates tables with n ternary complexity relations, tridimensional data, OLAP, takes 15 years to process the information… And by then, the princess became a lesbian.
  • Ruby - Arrives with massive fame, saying he is the best at anything and when he faces the dragon, he shows a lame motion picture of himself killing a dragon… The dragon eats him out of boredom.
  • Smalltalk - Arrives, analyzes the dragon and princess, turns around and leaves, they are way too inferior.
  • shell - Creates a very powerful dragon slaying weapon… But in the moment of truth, he can't remember how to use it.
  • shell(2)- The guy approaches the dragon with a two line script that kills, cuts, disembowels, impales, chops to pieces and packs the beast, but when he runs it the script grows, it fattens, irritates and puts alcohol in the fire of the dragon…
  • Assembler - He thinks he's doing the right and most efficient things… But he writes an A instead of a D and kills the princess to end up f***ing the dragon.
  • Fortran - Arrives and develops a 45-thousand-code-line-solution, kills the dragon, meets the princess… But she calls him a weakling and runs after the Java programmer who was elegant, and also rich.
  • FOX PRO - Develops a dragon killing system. It's gorgeous and works on the outside, but it's really patched inside, so when he runs the dragon anihilator, he realizes he forgot to index the DBFs.
  • PROCESS ANALYST - Approaches the dragon with two tons of documentation, develops the unified dragon-killing process, he develops a DFD to free the princess and marry her, convinces the dragon that it's the best for him and it won't hurt. When he executes the process, he estimates the effort and the damage he will cause with a plan signed by the Pope, Buddha and Michael Jackson. Then he buys a couple of nukes, 45 cannons, an aircraft carrier and hires 300 heavily armed men… When all he needed was the sword he was holding in his hand in the beginning…
  • CLIPPER: Sets up a routine that loads a codeblock array to insult the dragon, serenade the princess, load the sword in memory, beat the crap out of the dragon, clean the mess, prepare a raspberry milkshake for the princess, make love to her, take a bath, start the car, put it some gas and come back home. When he runs it, he gets a "Bound Error: Array Access" and the dragon eats him with fries.
  • Lisp, where the famous knight-errant, after speaking with numerous experts in dragon-killing, and modeling the knowledge they posess, he programs the system, and when he runs it he realizes he forgot a bracket (bender the offender).
  • HTML: Mounts a web on famous swords used to kill dragons, but he ignores the W3C standards. When he meets the dragon, he finds out the code isn't compatible with his browser, so he's left swordless. The dragon eats him as an appetizer.
  • Prolog: Thinks he needs a weapon to kill the dragon. Searches in a catalog for 182014 weapons. By the time the princess dies of her age, he's achieved to know how to make every weapon starting with A: Atomic Bombs, Anti-Air Weapons, Arches, Ammunition, Axes...
  • PHP: Creates a web page that when he executes it would eliminate the $dragon selecting from a weapons databese in MySQL over an Apache server. Nevertheless he forgot the WHERE in the DELETE query and kills the princess, the dragon, the peasants, the witch, the sorceror and the programmer himself.
  • JavaScript: The programmer tries to kill  the great green dragon that spits fire throug his mouth. He creates a script that will delete the dragon when he loads a webpage, to create seconds after, some damsels to throw him flowers and make clapping sounds. Unfortunately he didn't take into account the DOM structure of the lizard, also known as Mozilla, and the only thing he gets is to fill his console of errors and that the Book of Mozilla tells how he was devoured.
  • ActiveX: The programmers create a tunnel to enter the dragon's lair from the castle and run a program that will kil the dragon from a safe and prudential distance. The dragon discovers the tunnel, eats the workers who dug, the dragon slayers, and enslaves every servant in the castle. The castle becomes a dragon-breeding place, full of little dragons that the dragon sends in pop-ups to other castles. The untasty remains of the knights are put in cans of Spam and sent to other castles as well as a warning. (aquelquesiente)
  • Basic. He creates a weapon able to kill paper dragons, but no matter how they improve it, they discover it's not good enough to kill any dragon bigger than a baby poodle.
  • Matlab: They create a loop that calculates the trajectories to shoot a giant arrow at the dragon. The program works flawlessly. What they need now are the voluntaries caoable to launch tha arrow with the necessary strength and accuracy.
  • Videogame Programmer : Spends two years programming a state-of-the-art sword with shaders and all. When the time comes to kill the dragon, he finds that half the knights aren't strong enough to raise the sword. Then someone programs a patch that reveals the sex scenes with the princess and Hillary Clinton makes it a scandal.

Quando ci si avvicina a un nuovo linguaggio come Java, è normale commettere errori. Tuttavia, secondo David Reilly, autore dell'articolo "Top Ten Errors Java Programmers Make", ci sono errori più comuni che tendenzialmente vengono ripetuti nel tempo. Della stessa opinione anche Neal Ziring, come emerge dal suo articolo "Novice Java Programmers' Favourite Mistakes".

Da queste due fonti, a cui potrei aggiungere anche "Common Java Coding Errors", ritroviamo elementi realmente comuni. Potrebbe essere che tutti gli autori hanno poca fantasia, o che in realtà l'ideatore sia solo uno e gli altri hanno preso spunto; tuttavia sembra più plausibile pensare che i novizi si dimenticano sul serio che Java è zero-indexed e che l'operatore di uguaglianza è == e non =.

Non posso però biasimare chi commette "infrazioni" come la denominazione del file in modo differente rispetto al nome della classe (se pubblica): chi viene da altri linguaggi sottovaluta certe piccolezze, soprattutto se non ne comprende il senso. Distrazioni come un "tentato overriding" con nome del metodo da sovrascrivere sbagliato possono essere passate, ma non lo possono essere noncuranze come la scrittura di gestori di eccezioni vuoti tipiche dei "furbetti in erba".

Per altre questioni forse la causa sta nella superficialità di insegnamento; ad esempio il concetto banale di passaggio di valore e passaggio di riferimento può essere tanto semplice da indurre il "maestro" ad assumere un atteggiamento sbrigativo senza porre la giusta enfasi. Si può notare anche come certi errori derivino da una incompleta o comunque insufficiente conoscenza (pragmatica) della programmazione orientata agli oggetti; per fare un esempio, l'accesso a membri d'istanza in contesti statici non ha molto senso.

A mio parere è ora di aggiornare la lista, oggigiorno non c'è più un passaggio da linguaggi come Pascal o C a Java, per cui forse (spero) c'è un aggiustamento di rotta su più fronti. In ogni caso la lista è interessante o quantomeno simpatica.

Tratto da www.javastaff.com Autore originale Dmitry Leskov Tradotto da Luca Mattei

E' possibile creare un file exe a partire da un'applicazione java? Solitamente, alcuni problemi possono essere risolti senza creare un file EXE.

Il motivo principale della necessità di solito è semplificare la distribuzione di un'applicazione Java. Java compila le classi in bytecode proprietario (i file .class), che non è supportato direttamente dall'hardware dei PC. Quindi un programma Java ha bisogno della Java Runtime Environment (JRE) per essere eseguito, che so occupa di interpretare le istruzioni in bytecode e compilarle in codice nativo "on the fly". Questo obbliga l'autore del programma a richiedere che la corretta versione della JRE sia installata nei computer degli utenti finali. Generalmente, però, non si può assumere che gli utenti finali sappiano cosa è una JRE, o come verificare la versione di quella posseduta , o come installarne una versione diversa, senza creare problemi alle altre applicazioni java o alle applet visualizzate spesso. Se poi se anche si è sicuri che la versione corretta della JRE sia installata sulla macchina dell'utente finale, che su alcune classi di utenti è possibile, il comando da eseguire per richiamare l'applicazione è probilmente lungo:

java -Xmx200m -cp whatever.jar -Dsome.property MyApp

Sì, si può scrivere un file batch con il comando, del tipo: runme.bat, ma è molto più comodo distribuire la nostra applicazione, magari ad un collega o ad un insegnante o ad un amico, come un unico eseguibile da lanciare con un doppio click. O, magari, prevedere un processo di installazione (e di disinstallazione) nativo, che non crei conflitti con altre applicazioni. Per questo non è una sorpresa sapere che che il principale motivo del desiderio di convertire i programmi java in exe nasce dalla necessità di rendere più semplice e sicuro il deploy su utenti windows. La vera sorpresa, per i newbie, è che il JDK non offre una funzionalità del genere. Prima del J2SE 1.4 tutto quello che si poteva fare era:

JAR eseguibili: E' possibile rendere eseguibile una applicazione java attraverso un doppio click, racchiudendola in un jar eseguibile. per farlo bisogna specificare la classe principale della applicazione e ogni altro jar da includere nel file manifest contenuto:

Main-Class: MyAppMain Class-Path: mylib.jar

Quindi utilizziamo il tool "jar" contenuto del SDK, specificando l'opzione m e il nome del file manifest appena creato:

jar cvfm MyApp.jar MyApp.mf *.class *.gif

Ora per eseguire l'applicazione possiamo digitare:

java -jar MyApp.jar

e verrà letto nel file manifest il nome della classe della quale invocare il metodo main. Allo stesso modo, se la JRE è ben installata, basterà cliccare due volte sul jar per avviare la applicazione. Nota: Da J2SE 5.0, i file jar sono associati al launcher windows javaw, che non apre la finestra nera con la consolle. Quindi, se ne avete bisogno, dovrete far partire il jar da riga di comando o da un file batch. Se la vostra applicazione è composta da più jar, potete utilizzare il tool One-JAR per riunirli in un unico jar. Il maggior problema di questo metodo è la compatibilità con la JRE. La JRE di default potrebbe essere infatti troppo vecchia e non avere i necessari Java Optional Packages (conosciuti prima come Standard Extensions). Per esempio, se la vostra applicazione usa il package java.nio introdotto dalla versione 1.4.2, non funzionerà con la JRE versione 1.3.x. Allo stesso modo, se usa JavaMail 1.3, e la JRE installata ha JavaMail 1.2 o non la possiede affatto, il jar non verrà eseguito.

PRO:

  • Non si usano tool di terze parti.
  • Multipiattaforma

CONTRO:

  • Le applicazioni non partono se non si ha una JRE correttamente installata.
  • Le applicazioni non funzionano se le APIs utilizzate non sono presenti nella JRE di default.
  • Bisogna informare gli utenti che i file JAR sono cliccakabili.

RISORSE:

  • The Java Archive (JAR) File Format

TOOLS:

  • One-JAR

Java Web Start Fortunatamente, per risolvere questi problemi di compatibilità, dal SDK 1.4 è presente un tool che facilita la vita allo sviluppatore. Java Web Start (JWS) e il suo protocollo Java Network Launch Protocol (JNLP) permette la distribuzione delle applicazioni java direttamente da un webserver standard. L'utente finale può iniziare l'installazione semplicemente cliccando su un URL. Se Java Web Start non è presente nel sistema, verrà proposto il download e l'installazione del tool. Se necessario, JWS provvederà poi ad avviare download ed installazione della JRE corretta e di eventuali package aggiuntivi. L'applicazione viene quindi lanciata e rimane pronta e nascosta nel sistema dell'utente finche' l'utente non la richieda nuovamente dall'URL associato, senza reinstallarla a meno che la versione della applicazione non sia obsoleta. In tal caso verrà aggiornata. Un'altra caratteristica interessante di Java Web Start è la capacità di far girare le vostre applicazioni in una SandBox, un container "sicuro". Ma a differenza della SandBox delle Applet, l'applicazione può accedere alle risorse native, come filesystem, stampanti e alla memoria degli appunti attraverso le JNLP Api, dopo aver chiesto il permesso all'utente, ovviamente. Java WebStart è disponibile per piattaforme Windows, Linux, Solaris e Mac OsX a partire dalla versione 10.1. Ci sono anche implementazioni di terze parti del protocollo JNLP ed alcune includono tool per la preparazione di un package adatto a JWS. Ma passiamo ai difetti. Innanzitutto il WebServer che ospita le applicazioni deve supportare il tipo mime associato a Java Web Start:

application/x-java-jnlp-file

Alcuni providers potrebbero non permetterlo. Inoltre per utilizzare le funzionalità di versioning e il supporto agli updates, c'è bisogno di un webserver in grado di supportare servlets, cgi-bin scripts, etc. Lato client, non ci dovrebbero essere problemi nel riconoscere il MIME type, per lo meno nei browser più popolari. In alcuni browser più di nicchia invece potrebbe essere necessario configurarli manualmente. Abilitare JNLP in un'applicazione dovrebbe richiedere modifiche minime e la creazione di un set di files jar. Prima della J2SE 5.0, JWS aveva veramente poco da offrire, in termini di integrazione desktop, limitandosi a creare una icona sul desktop e/o un collegamento nel menu Start. In Windows, l'applicazione non apparirà nelle entry in "Installazione Applicazioni", quindi l'utente dovrà lanciare Java Web Start per disinstallare l'applicazione. Infine, si vede la necessità di una interfaccia utente più pulita per JWS. Allo stato attuale (J2SE 5.0) gli utenti si trovano a interagire con orribili finestre con messaggi incomprensibili. Lato client, non ci dovrebbero essere problemi nel riconoscere il MIME type, per lo meno nei browser più popolari. In alcuni browser più di nicchia invece potrebbe essere necessario configurarli manualmente. Abilitare JNLP in un'applicazione dovrebbe richiedere modifiche minime e la creazione di un set di files jar. Prima della J2SE 5.0, JWS aveva veramente poco da offrire, in termini di integrazione desktop, limitandosi a creare una icona sul desktop e/o un collegamento nel menu Start. In Windows, l'applicazione non apparirà nelle entry in "Installazione Applicazioni", quindi l'utente dovrà lanciare Java Web Start per disinstallare l'applicazione. Infine, si vede la necessità di una interfaccia utente più pulita per JWS. Allo stato attuale (J2SE 5.0) gli utenti si trovano a interagire con orribili finestre con messaggi incomprendibili. Riassumento, JWS può essere valida una opzione in ambienti controllati, come le intranet, ma non è pronto per il mercato consumer, per il quale sono preferibili le soluzioni seguenti.

Java Launcher e Wrappers custom Quando un programma Java è invocato utilizzando uno dei metodi discussi sopra (file batch, jar eseguibile, JWS/JNLP), il sistema operativo esegue un lancher java fornito dalla JRE. La versione windows della JRE ha launchers separati per le applicazioni command line e quelle grafiche, rispettivamente java.exe e javaw.exe. Come risultato, tutte le applicazioni java in esecuzione hanno lo stesso nome nel Task manager e la stessa icona nella taskbar o nel pannello "alt-tab". Se si hanno più di un applicazione java in esecuzione, non si ha modo di distinguere fra le diverse istanze di java nel task manager. Praticamente, questi launchers sono solamente piccoli programmi nativi che caricano la JVM da una dll (shared library) ed eseguono le tue applicazioni usando le Invocations API. Queste api fanno parte delle Java Native Interdace (JNI), quindi standard, e molto semplici. Questo rende relativamente semplice scrivere un nostro launcher con un nome e un'icona unici. Quello che bisogna fare è trovare una JRE disponibile sul sistema dell'utente (o includerne una nell'applicazione), caricare e inizializzare la JVM e far girare l'applicazione su di essa.

Tool Java per creare Setup Se si necessita solo di installare una copia privata della JRE insieme alla propria applicazione e creare un collegamento che la esegua su tale JRE, si può utilizzare qualsiasi generatore di setup. Comunque, utilizzare un tool basato su java potrebbe avere dei benefici:

  • Rilevare al momento dell'installazione eventuali JRE presenti ed eventuale download
  • Generazione di un launcher nativo
  • Parametri JVM editabili dall'utente
  • Redirezione degli stderr e stdout per salvare log ed eccezioni
  • Registrazione delle applicazioni Java come servizi Windows o demoni Unix

Questa categoria è la più diversificata in termini di prezzo e funzionalità. Le differenze sono spiegate qui sotto: I tool Windows centrici, come Advanced Installer for Java permettono di creare installativi MSI. I tool multipiattaforma possono generare installativi per più piattaforme: Windows, Linux, Mac OS. Install4j è uno di questi. Ci sono anche Tool che permettono di creare installativi unici che girino su più piattaforme. Tali installativi sono essenzialmente jar eseguibili con logiche specifiche per gli ambienti nativi, riconosciuti a runtime. InstallAnywhere è forse il più conosciuto della categoria, ma se il suo prezzo è oltre il vostro budget, considerate il più economico JExpress o IZPack, Open Source. Infine, c'è un tool che li racchiude tutti, InstallShield che può creare sia MSI per Windows che installativi closs-platform,anche per server o dispositivi mobili, per qualsiasi tipo di applicazione e per una moltitudine di sistemi operativi. E sì, supporta il riconoscimento della JRE, l'installazione in bundling, i launcher nativi e così via.. Comunque, per le installazioni semplici e dirette, InstallShield è un peso inutile. Ricordate anche che InstallShield e InstallAnywhere mirano agli sviluppatori enterprise ed i loro prezzi sono conseguentemente elevati. Tutte queste soluzioni non risolvono il problema fondamentale menzionato nella prima sezione di questo articolo. Sia creando un jar eseguibile o un sofisticato installativo, l'applicazione continua ad essere distribuita come bytecode platform-indipendent. Nei primi giorni di Java, l'unico modo di eseguire un programma java su di un comune PC, era di interpretare tale bytecode. Oggi, qualsiasi implementazione J2SE decente contiene un compilatore Just-in-Time (JIT) che compila i metodi eseguiti frequentemente in codice nativo. Così è abbastanza naturale passare un passo avanti e compilare tutta l'applicazione prima di distribuirla. Vediamo quali tool ci permettono di farlo.

Compilatori Ahead-Of-Time I compilatori AOT sono conosciuti anche come "compilatori statici" o "compilatori di codice nativo". Quest'ultima denominazione è la più usata e, come spesso succede, la meno corretta dal punto di vista tecnico, dato che anche i compilatori JIT producono codice nativo. Un compilatore Ahead-Of-Time (AOT) prende in input i vostri file jar o class e produce un eseguibile convenzionale in linguaggio nativo, come un EXE Windows o un binario ELF per Linux. Così come qualsiasi altra soluzione tecnica, anche questa ha i suoi vantaggi e svantaggi.

Vantaggi:

  • Performance. Un compilatore JIT funziona come una applicazione in background e condivide la cpu e le risorse di memoria con l'applicazione che compila e con qualsiasi altra applicazione in esecuzione. Un compilatore AOT gira sul sistema dello sviluppatore senza vincoli di tempo o di risorse. Per questo può, potenzialmente, utilizzare ottimizzazioni di risorse più potenti, rendendo il codice migliore.
  • Protezione della proprietà intellettuale. Il bytecode Java è molto facile da decompilare, basta cercare "download java decompiler" per ottenere il codice sorgente di qualsiasi applicazione java in 5 minuti. Sì, è possibile offuscare i nomi delle classi e dei metodi pubblici ai quali non si accede via reflection, ma l'offuscamento del controllo di flusso può rendere il bytecode non verificabile dalle future JVM e rendere impossibili le ottimizzazione implementate dai compilatori JIT. Infine, criptare il bytecode non lo protegge del tutto, qualsiasi algoritmo di criptaggio si usa. D'altra parte, il codice nativo prodotta da un compilatore AOT ottimizzante è troppo complesso da essere sottoposto a reverse engineering, quanto quello di applicazioni sviluppate in C++. Inutile da dire, non ci sono prestazioni perse. Se si è interessati a proteggere la propria proprietà intellettuale, si dia uno sguardo alla compilazione nativa.
  • Percezione dell'utente. Le applicazioni Java Client soffrono spesso della cossidetta sindrome del ciclo di riscaldamento. Avviare un programma java richiede l'interpretazione del bytecode, la sua profilazione e la compilazione JIT. Per questo i programmi Java tendono a partire più lentamente dei loro rivali nativi e l'iniziale tempo di risposta di una applicazione grafica Java è molto peggiore di quello effettivo dopo che è stata usata parecchie volte, che sono le due maggiori ragioni per cui Java è ancora percepita come lenta da molti utenti. Un eseguibile nativo gira direttamente sull'hardware, senza l'overehad interpretazione-profilazione-compilazione, così può avviarsi più velocemente ed ottenere migliori tempi di risposta.

Svantaggi:

  • Peso sul disco. Il bytecode del Java è stato progettato per la compattezza, a un livello molto più elevato del set di istruzioni macchina. Si pensi che un eseguibile prodotto da un compilatore AOT sia 2-4 volte più grande dell'originale file jar.
  • Applicazioni dinamiche. Le classi che l'applicazione carica dinamicamente a tempo di esecuzione possono essere non disponibili al sviluppatore. Queste librerie possono essere plugin di terzi, proxy dinamici ed altre classi generate a tempo di esecuzione e così via. Così il sistema deve includere un interprete di bytecode Java e/o un compilatore JIT. Inoltre, generalmente solo le classi che sono caricate dal sistema o dal classloader dell'applicazione possono essere precompilate in codice nativo. Così le applicazioni che usano i classloaders custom possono soltanto essere parzialmente precompilati.
  • Ottimizzazioni per Hardware specifico. Un compilatore JIT presenta un vantaggio potenziale rispetto ai compilatori AOT in quanto può selezionare pattern di generazione di codice secondo la reale configurazione hardware su cui sta girando l'applicazione. Per esempio, può utilizzare le estensioni Intel MMX/SSE/SSE2 per velocizzare i calcoli in virgola mobile. Un compilatore AOT deve o produrre codice per il minor comun denominatore oppure diverse versioni per i più metodi più CPU-intensivi, aumentando il volume di codice.

C'è anche un comune pregiudizio che la compilazione AOT uccida la portabilità Java. Questo non è il caso, dato che il codice sorgente non necessita di essere modificato e si può sempre distribuire il bytecode per le piattaforme per cui non esiste un compilatore AOT. (Si perderebbe ovviamente il vantaggio di protezione del codice). Per quanto riguarda i tools, nel 2000 ne erano presenti una mezza dozzina, ma solo un paio sono sopravvissuti, si tratta di Excelsior JET e di GCJ (Gnu Compiler for Java). (Se siete interessati al campo embedded, date un'occhiata a NewMonics PERC, che si indirizza a J2ME CDC ed ha anche un supporto limitato a J2SE 1.3.

Tratto da programmazione.it scritto da Dario Guadagno

In questa ultima parte si analizzerà come utilizzare le classi fornite per importare o esportare scene in VRML. Le due classi relative all’interfacciamento con file e creazioni in VRML sono: VRML97Saver e VRML97Loader.

La prima, come si può intuire dal nome, consente di salvare gli ambienti creati in Java3D come file VRML, mediante una conversione che, attraversando tutto lo scene graph, individua i nodi rilevanti e li trasforma in istruzioni VRML (a loro volta scritte sotto forma di nodi, che generano un albero che descrive una scena tridimensionale). La sintassi da utilizzare è la seguente:

import cv97.j3d.*;
...
BranchGroup j3dBranchGroup = ...
VRML97Saver saver = new VRML97Saver();
saver.setBranchGroup(j3dBranchGroup);
saver.save(“nomeScena.wrl”);

Il codice indicato consente di esportare in formato standard VRML la scena corrispondente al content branch radicato nel j3dBranchGroup. L’ambiente salvato sarà visibile con qualunque strumento in grado di aprire file VRML.

Funzionamento analogo, ma chiaramente inverso, è quello della classe VRML97Loader, che consente di aprire un file VRML, convertirne il contenuto in un insieme di nodi Java3D, e trasformarli in un content branch radicato in un unico BranchGroup, che quindi può essere utilizzato per le normali operazioni previste da Java3D relative agli ambienti tridimensionali. La sintassi per utilizzare la suddetta classe è la seguente:

import cv97.j3d.loader.*;
...
Canvas3D c3d = ...
VRML97Loader wrlLoader = new VRML97Loader(c3d);
Scene s = wrlLoader.load(“nomeScena.wrl”);
BranchGroup sgGroup = s.getSceneGroup();

Il loader viene inizializzato con la Canvas3D, che contiene l’universo in cui si sta lavorando per la creazione di un ambiente 3D. L’importazione di una scena descritta in VRML avviene in due fasi: dapprima, utilizzando il metodo load(), si carica il file .wrl che rappresenta la scena e si ottiene così una com.sun.j3d.loaders.Scene corrispondente al file caricato; poi, utilizzando il metodo getSceneGroup(), si ottiene il BranchGroup in cui è radicato il content branch, che descrive la scena sotto forma di istruzioni e nodi in Java3D.

L’oggetto sgGroup ottenuto potrà, quindi, essere utilizzato nel codice Java che segue la sua istanziazione come un qualsiasi BranchGroup, per cui potranno essere aggiunti ulteriori nodi come suoi figli, potrà essere associato ad un nodo gruppo (BranchGroup o TransformGroup) padre, o potrà essere inserito nell’universo su cui si sta lavorando, per consentire la visualizzazione della scena che sgGroup rappresenta.

Lo scorso settembre è stato annunciato che, finalmente dopo ben otto anni di silenzio assoluto, verrà rilasciata la versione aggiornata del linguaggio HTML. Si passerà quindi dalla release 4 del 1999 alla release 5. La nuova versione aggiungerà nuovi comandi al linguaggio, per venire incontro alle esigenze degli sviluppatori di integrare materiale multimediale e altro nelle pagine web. Ciò nonostante la vecchia versione sarà ancora valida al 100% e rimane alla fin fine la struttura portante di ogni pagina. Pubblichiamo qui una quick reference guide del linguaggio, per avere sempre a portata di mano comandi e parametri disponibili nella vecchia versione.

Solitamente, dopo aver scaricato ogni sorta di ben di dio da poter caricare nel proprio cellulare, sorge la fatidica domanda: e se ora facessi qualcosa io? Il proposito è lodevole, ma non privo di ostacoli. Per scrivere un gioco java per cellulari bisogna cimentarsi con la j2me, che volenti o nolenti, significa programmare. Ciò nonostante java è stato realizzato con due obiettivi principali: funzionare su qualsiasi dispositivo ed essere di facile apprendimento. Senza essere ipocriti, java è e rimane un linguaggio di programmazione a tutti gli effetti, ma con qualche buon esempio anche chi non è un buon programmatore ma è armato di pazienza e impegno è in grado di ottenere qualche soddisfazione.

Per poter apprendere in modo rapido i rudimenti di Java consiglio di leggere la guida che presenta HTML.it. Qui trovate invece una guida specifica per J2ME.

Il compilatore Java2, necessario per lo sviluppo dell'applicazione si scarica gratuitamente dal sito di Sun Microsystems. Similmente il pacchetto aggiuntivo J2ME. Scrivere dal Blocco Note di Windows è possibile, ma non è il massimo per chi si avvicina a Java per la prima volta. Ci si deve quindi appoggiare a degli IDE, dei programmi che ci assistono nella stesura del codice. Se vogliamo restare in casa Sun possiamo scaricare NetBeans, altrimenti anche Eclipse fa al caso nostro. Infine abbiamo bisogno di avere qualche esempio pronto da sviscerare per vedere come funziona il tutto. Qui trovate qualcosina che per iniziare è certamente d'aiuto.


© 2017 Bruno Tessaro. My life in the web. All right reserved.