Why I Will Not Use Java

This post is quite old. I wrote it back in 2010, when I realized Java's main drawback is its verbosity. I didn't expand my thoughts, 'cause I was too engaged at work with C, Objective-C and Python. But in these days I read some articles about Java 8 and I felt very disappointed, 'cause it lacks some features, some snippets and doesn't resolve Java's main drawbacks.

Java Language is Verbose

Java Language is verbose, in the worst way you can say it, mainly for two reasons.

The End of Multi Threaded Programming

I warn you: this is a provocation. I really want to have replies to this post. Because I'm talking about one of most famous themes for computer-science students: threads and multithreading programming.
A special thanks to Andrea "MEgrez" Talon whom solved some doubts I had about Node.js

The Apache which leaved the reunion

Apache is flown away

Me and Mix (a friend of mine) have a very different opinion about Java: he totally dislikes it, but I think it's good on servers.
Two days ago, Apache leaved Java Community Process, because it disagree Oracle's decision to don't release for free tools to check a Java implementation compatibility. This is an ugly decision, because it will make very difficult (or impossibile?) to check if (e.g.) Apache Harmony is a Java compliant implementation.
Oracle is handling Java as a colony, ignoring what the Java Comunity did in these years. Oracle is pressing to morph Java into a "personal language".

When Mix sent me this news, I throws my hand in the sky saying «well, we will program in python or PHP» and I was serious. I used Java in few projects in these years and no-one end successfully. In the low-medium market, where I work and where work at least 70% of programmers, Java is never used because:

1. it's more difficult to write a JSP than a PHP page
2. it's more difficult to use Hibernate than Ruby on Rails
3. Swing is slower than QT or than WXpython or than TKinter
4. it's harder to use an XML as configuration file than using a python/ruby/php/lua dictionary/hash

Many big competitors use Java for their work and they have many powerfull tools, such as JUnit, Log4J, Ant, Geronimo, Batik, Cayenne, Cocoon and many more, developed by Apache Foundation.

I am tired to talk about Java: Oracle, Apache, IBM and Google are playing with it in a very boring way. C/C++ didn't have all Java troubles because the language and the standard library were free to be developed by everybody. Java was once strictly managed by Sun and now by Oracle. This decision cut off necessary freedom from Java to transform it as "language of choice". People still use C/C++ because they're faster; use Ruby or Python because they're easier; and because people aren't interested to portability.

Maybe Java, as we know it, is going to dead. Maybe we'll see two branches, the one "official" made for servers (supported by Oracle, IBM and RedHat) and the "mobile" one, supported by Apache and Google for Android platform.
Future's unknown. Until the next "big" revolution, let's script.

Chainsaw with Jigsaw

«Groovy!»

The Jigsaw Project is "java kernel"'s offspring: the idea of cutting off pieces from the JVM and from classpath to obtain a small "java kernel" able to download and install by itself all necessary packages and libraries.
We'll get Java with a 1M installer, no more. It will runs some small programs, such as a telnet client and clones of ls, cat, more, ecc. utilities. When you will create a Java application, the new JVM will automatically download all missing libraries.
I don't believe Jigsaw will resurrect the Java desktop, but there's some scenarios we must reflect about. In these days Apple is trying to integrate its desktop with its mobile solution. The Mac App Store and the iPhone App Store are similar ideas; the Mac Book's trackpad is the same multitouch device of iPhone's display; Mobile Me's services work as a glue between your different Apple devices. In this "extremely dynamic scenario", informations (e-mails, photos, music, calendars, ecc.) are always in your hand. Why no expand this scenario to applications? Why no expand this scenario to your copy and scores of Angry Birds, or your copy and save games of Rage, they'll runs everywhere, downloading just the necessary informations from the network? It's true you can't have a Crysis written in Java, but a «Monkey Island Series» yes. This concept of «Buy Once, Run Everywhere» could potentially kill a set of market stores (where's the difference between a PS3 and a XBOX 360 and a WII if a donwloaded game runs everywhere?) and makes me doubtful about this prospective. But there's some players that could be interested on platform indipendence.
I introduce you an example: I buyed "Diablo 2" some years ago for PC. Blizzard gives me the opportunity to dowload a version for Mac OS X spending no money. They did a good work and I appreciate its honesty. Porting a game is an hard work, but in Java is trivial. Game's world is moving from power-players to casual-gamers and casual games don't need high performances or fancy graphics.
Java Jigsaw Platform could be a big opportunity some years ago. Now, with this commercial pressure oriented to kill every kind of portability, I am non very confident that Java will emerge from desktop sea.

The power of a "Singleton"

«Please, excuse me if I didn't update my blog in these days. I was so busy in some activities, both at work and for my movie. Yesterday, with Fabio, I looked for a good place to realize some scenes. We were lucky!»

A singleton doesn't need 1.5 GW

In this post I'll talk about singletons, last design-pattern I found. If they're necessary in Cocoa, they're also usefull in other programming contexts. What's a singleton, exactly? On wikipedia it's defined as «the instantiation of a class to one object» and well, it's right.By a programming point of view it looks like (in Java):

class MySingleton{
    private static MySingleton shared_singleton=null;
    private int counter;

    
/**
     * Private constructor
     */
private MySingleton(){
        counter=0;
    }

    
/*
     * Increment counter
     */
private void Increment(){
        counter++;
    }

    
/*
     * get the singleton
     */
private static MySingleton getSharedSingleton(){
        if (shared_singleton==null)
            shared_singleton=new MySingleton();
        return shared_singleton;
    }
}

You see, when you're using a singleton, you have just one instance of this object (here it's called shared_singleton). You can get a reference to this object with the getSharedSingleton static method.
In Cocoa touch, singletons are the most confortable way to have a shared resource; global variables, (very used in C) aren't good as a singleton. In Java you can insert them easily in a multithreaded context, just adding the synchronized keyword. Singletons are very good to share read-only data and they can be used in every object-oriented programming language.

Singletons could be dangerous, because (if they're not well designed) they could know too much about other objects, can grow in functions if they're not well designed a can give throubles in a multi-threaded environment. A detailed description about dangers of singletons abuse is Use your singletons wisely by J. B. Rainsberger, employed at IBM. It's an interesting lecture if you are a programmer. Another good lecture is Singleton Pattern description, where there's also some example of "Singleton Abuse".

The Last of the Patriots

The Game
Paul Davis is a game designer and a programmer. He worked on "Manhunt" and "Grand Theft Auto" as level designer. Two years ago, following a link, I found his site, «Lastofthepatriots.com» (unlucky, now it's a dead-link), where mr. Davis hosted the omonimous project. In «Last of the Patriots» (I and II), he created a game engine from scratch, using OpenGL and Audiere as base. His main objective was to write a game focused on story, moral decision and player involvment. The result was «Last of the Patriots», which can be defined as a "Visual novel with a Zelda-Like visualization": you will not shot so much and there's no special-FX or 3D graphics. Last of the Patriots has a story, based on a movie script. You will be surprised about how your feelings will change playing with this game. "Last of the Patriots" is an interesting game experience and I suggest you to give it a try.

The Technical Notes
After a while, I sent an e-mail to Paul Davis, asking him some technical informations. I was really interested about indipendent video-game development and I recived his reply with enthousiasm. I was not disappointed: mr. Davis was exaustive and well prepared.
First: he used OpenGL for graphics and Audiere for the audio parts. A port to other operating systems, anyway, shouldn't be easy, because the input is managed by the win32 API (OpenGL hasn't a great input manager). All the graphics was realized using a 3D program to modelize and animate. Every frame is a shot done to this animated models.
Game logic is realized with an embeded scripting engine written by Davis. I can't say so much about that, because I didn't find any script.
The whole game engine it's coded using C (no C or Objective-C) for personal choice (he prefear to use C). He admits, anyway, for a similiar game, Java could work well.

Conclusion
I encurage to play with with «Last of the Patriots» and its sequel, because some misteries (first of all, the title) are explained. I don't know if the official website will go online again, but you can still download the binary from this link.
Last of the patriots is a very particular game. Give it a try: it could open to you new interesting prospectives. Mr. Davis said he write it to focusing on story instead on graphics.
He did it.

Oracle's short vision

Mr. Magoo, you are more fun

News of the day (october 29 2010). From Computer World I read «Oracle: Google 'directly copied' our Java code». In this article is exposed how and where Google did copy Java's code. From the article we read

«The infringed elements of Oracle America’s copyrighted work include Java method and class names, definitions, organization, and parameters; the structure, organization and content of Java class libraries; and the content and organization of Java’s documentation»

I organize this declaration in the following list

1. Java's methods names;
2. Java's class names, definitions, organization;
3. Java methods' parameters;
4. the structure, organization and content of Java class libraries;
5. Content and organization of Java’s documentation;

Pay attention, this statements aren't so unfamiliar. Do you know where I (and probably you) did hear them before? When SCO accused Linux of copyright infringement. SCO was more prepared, saying mr. Torvalds copied directly UNIX code into his kernel (Linux). In the final chapter of this ridiculous theatre, SCO showed this famous pieces of code: few macro definitions of the errno.h header file. These macros look similar to this:

#define PI 3.14159265

The SCO-Linux controversies was more complex and still continue. Anyway, SCO showed some code and, on a computer-science lawsuit, gave some material to think about.
Let's return to Oracle's assertions. How much are they real? As a programmer with some knowledge in law and licensing, they seem ridicolous.

1. You can't set a copyright for a "Function Name". Neither for a class name or a declaration. They're not "trademarks". The only trademark could be the "java" prefix in some cases (such as java.*), but I have doubts, because there are placed to grant the Java Standard Definition;
2. Look point 1;
3. Look point 1;
4. As I say on point 1, I can understand Oracle dislikes the word "java" in a whole classpath, but this is placed to follow the Java Standard Definitions;
5. This is more difficult: as you can read here, Oracle's documentation distribution isn't released under the GNU Free Documentation License.

If you think well, there's something else to say: Android is based on 3 things: a Virtual Machine (Dalvik), a language (Java) and a classpath (Harmony). Google never said Android runs Java and they're right, because Dalvik is very different to Hotspot; Harmony is a java classpath reimplementation released under the Apache License.
By the way, "Java" was released under GPL by Sun Microsystems just before it was purchased by Oracle and just some pieces are still under a non-free license. So, Oracle's charges to Google seems inconsistent to me. If the problem is documentation, then Google can pay a team to rewrite it.

I think the main reason to start this lawsuit campaign is the lesser importance of the Java Micro Edition platform. How Oracle (a server provider) could be afraid on losing the mobile market? The answer is Oracle feels threatened by the decreasing importance of selling licenses to use the Java Micro Edition. Sun Microsystems earned selling to smartphone producers (Nokia, Erikson, Motorola, ecc.) the autorization to include a JME on their products. I think this was the only profittable Java client platform. Now that JME is going out  of market (killed by iOS and Android), maybe Oracle is playing dirt to give new life to this project.

Gosling's Reply

«Ok guys... I've something to say...»

James Gosling is one historical True Hacker. He's famous for his version of EMACS (Gosmacs), for its work at Sun Microsistem and to be known as "Java's Father". Soon after Sun aquisition by Oracle, Gosling resign, because he didn't like Oracle's politics.
Yesterday (october 26 2010), I read from an italian site Gosling's reply to Steve Jobs' declaration about Java remotion from the new Mac OS X (Lion). Googling a bit, I found the original article  at Gosling's blog.

In few words, Gosling said that if Apple is going to remove Java is because Apple wanted to write on their own the official Mac OS X JRE, compliant to Sun's standards. Apple's programmers worked hard and well, but some old design decisions make development a hell. Simply it's hard to continue to support a full Java implementation. Apple has lost interest on Java in a moment where its Macintosh starts to increase in popularity together with its development platform (Objective-C and Cocoa).

Gosling also accused Apple to say a lie when Jobs declare that «Sun (now Oracle) supplies Java for all other platforms». As I said before, there's no version of Java for Mac OS X on Oracle's site.

What to say about? If Apple supported its Java Runtime was mainly because they belived it would become the standard client platform (in a era when converting applications from Windows to Macintosh looks improbable). When Macintosh became more widespread (since 2002), Apple's forces on their Java Runtime were moved elsewhere.

But the Apple development model for Java was right: a JRE wrote from the same software house who write the OS as part of a stack wich starts from hardware, proceed to kernel, continue with OS's APIS and ends with an optimized virtual machine and a well integrated classpath. Apple followed this road, giving us the fastest and best integrated Java experience. Microsoft did the same, but soon started to change some features of Java, making Java programs written on windows incompatible with other Java implementations (who said Embrace, Extend, Extinguish?). Maybe, if Sun would has thought seriously about a politic of openess in Java development (maybe involving IBM and Oracle to define Java new features, standards, ecc.), we would have a Java Kernel, a small and efficient JRE (just 3 Megabyte), a more efficient Java GUI (a DirectX-based Swing? Something similiar to SWT?) and a set of tools to deploy more easily a Java application (Java jar could appear as a Setup.exe on Windows, a .DMG in Mac OS X, a .deb on Debian...).

Let's think about Android: Java is Android's standard development platform. If you look where are located Android applications you'll see the "ideal" situation I described.

Android's architecture. Runtime have the same role of JRE

Unluckly, on desktop systems, a Java client means less differences among various platforms. Can you realize what this means for a market where you want to gain monopoly?

Yeah, you know the answer.

HipHop: emotions no-stop

Mhh... there's something strange....

Some months ago, Facebook annunced its new "HipHop" technology, used to speedup its servers. HipHop is a translator: when a page is requested for first time, HipHop transforms PHP source code in to a C++ source and then compiles it into native code with g++.The executable then is launched:its output is passed to the webserver.
Haiping Zhao, senior engeneer and HipHop chief, said HipHop speeds up to fifty percent Facebook servers. No bad, really. So, will we start to develop with HipHop in mind? I don't think so.

HipHop born with a specific target: to increase performances of one of most visited sites on earth. But, after thinking about it for some weeks I realized that better solutions could exist. Assuming as fundamental requisite that is impossible to rewrite ALL Facebook in another language and that most of programmers involved knows only PHP we can:

   1. write a PHP-to-Bytecode interpreter. JVM on server side is great: it's scalable and it has a JIT.
   2. create a front-end to LLVM. LLVM is a Virtual Machine AND a compiler. Apple is founding LLVM project, probably to use it as default compiler for its systems. LLVM supports multithreading.

HipHop technology seems to me as a return to the CGI. After ten years of mod_php (created to avoid CGI), Zope and other ways to reduce the use of CGI, we return to the root of web programming.

In my humble opinion, HipHop looks like more as a "patch" than an "entire solution". Facebook's engineers know well their work and they developed Cassandra DB from ground to up. A great work, well designed and well implemented (Java for scalability and fault-tollerance; replication; choice of a non-relational schema, ecc.). It sounds strange that Cassandra and HipHop came from the same home, because they seem too different. I think Apache Foundation is more coherent: Apache developers work on server-side with Java, with some exceptions in client and C/C  (such as Xerces and log4cxx).

I have no doubts that Facebook's administrators know well what's better for their business and I have no doubts they studied with attention to choose the best solution for their problem. But their solution seems very strange to me, and I would like to understand why they choose to create HipHop.

There's no lions in Java

Alea iacta est

Just after a week of blogging, I decided to start writing in english, to expand my user base. It's a hard decision, because this means to face my ability with this language. But I decided: there aren't more excuses to don't write in english. If I'll do a mistake, I'll learn from it and I'll continue to write my opinions on computer-science and cinema.


Today I'll talk about new Mac OS X (Lion) and its new features: in the last "Mac Event", Steve Jobs presented the Mac App Store (interesting), full-screen applications (less interesting), Mission Controll (a enhanced Exposè), Launchpad (a way to visualize your applications) and... Java remotion.
Well, it's no completly correct: Java now it's "just" deprecated and this means, sooner or later, Mac OS X will be shipped without a pre-installed JVM. This means all Mac users will have to download and install a Java Runtime Environment, exactly as for Windows or Linux.
Jobs justifies this decision saying



«Sun (now Oracle) supplies Java for all other platforms. They have their own release schedules, which are almost always different than ours, so the Java we ship is always a version behind. This may not be the best way to do it.»



Well, looking on Oracle site I see there are JVM just for Linux, Solaris and Windows; FreeBSD have a Java package on its repository of "BSD Ports".
If you can get it for BSD, you can get also on Mac OS X. In worst case, we can compile it from source code (Java is released under GPL).
But tell me the truth: do you really feel the lack of Java on your macintosh? It's about a five months I don't use Netbeans on my MacBook Pro; I haven't installed yet Vuze (Transmission works well too); Runescape... maybe one day I'll play with it.
I said on a precedent post Java habitat is on the server side: clients use AJAX and Flash when you're on web-context; they use C/C++/ObjC on heavy client applications; they use Python, Ruby and Visual Basic for non-intensive CPU applications.
Java on Mac OS X was a wonderful idea, and was the ONLY version of Java shipped on a successful desktop system. The lack of real useful client software was tolerated too long. If Oracle is really interested on Java client, then it must to redesign Java to transform it on a fast, comfortable and elegant development platform.
And if you are concerned about the fate of fussy Macintosh sysadmins, don't panic: they're "pro" enough to install a java runtime environment by themself.

Intanto, nell'isola di Java....

Il garbage collector osserva attento l'heap di sistema

Apparso nel 1995 col motto di «write once, run everywhere», Java s'è diffuso in diversi dispositivi, con fortune alterne: sui telefonini ha avuto un timido successo eclissato dalla corazzata Android; sui client lo usano pochi coraggiosi e gli sviluppatori che utilizzano Netbeans; le celebri Applet son morte attorno al 2001.
E su server? Beh, Apache Foundation lo usa per praticamente per tutti i suoi progetti; IBM e Oracle lo usano come base delle loro soluzioni software.
Insomma, un successo o un flop?
Dipende. Che Java sia usato è indubbio (i numeri ci sono), ma la destinazione è completamente diversa da quella prevista: nato come piattaforma per i client, Java ha successo solo nell'ambito server. Se pensate a quali sono i VERI programmi client Java, quelli che si usano seriamente, cosa troviamo? Eclipse, Netbeans, Vuze e Runescape. Programmi belli e potenti, ma troppo poco per parlare di un successo. Dal lato server, invece, cosa vediamo? Dando una sbirciatina al sito della Apache Foundation trovo:

• Abdera
• Ant
• Cassandra
• Cayenne
• Click

e un'altra decina almeno di progetti open che, nel 90% dei casi è scritta in Java.

La celebre Java Virtual Machine
"Java" è il nome "ombrello" sotto cui son raccolte tre cose:

1. un linguaggio
2. una Virtual Machine
3. il classpath (la libreria standard)

La Scimmia Cattiva odia la JVM

 Il linguaggio e il classpath sono apprezzati e ammirati, tant'è che Android usa come piattaforma di sviluppo il linguaggio Java e il classpath reimplementato da Apache (progetto Harmony). Ma se chiedete a uno sviluppatore cosa non gli piace di Java, egli punterà il dito contro l'odiatissima Java Virtual Machine. Nessuno ha mai avuto difficoltà a SCRIVERE un programma in Java, ma quasi tutti si son lamentati della velocità di esecuzione.
In realtà, una volta avviata, la Virtual Machine realizzata da Sun (nome in codice "Hotspot") lavora discretamente bene, con prestazioni generalmente non distantissime a quelle C++, grazie soprattutto alla presenza del JIT. Dai benchmark ricaviamo che i calcoli trigonometrici sono ancora molto lenti, quindi eviteremo di usare Java per applicazioni di calcolo scientifico.
Però vediamo cosa dicono i benchmark di Jake 2, una reimplementazione in Java del motore grafico di Quake 2. Sembrerebbe che Java ne esca con le ossa meno rotte del previsto rispetto al C/C++ dal punto di vista della velocità. Davvero non male, visto e considerato che si può stimare che il codice sia almeno del 20% meno complesso (niente header files e niente puntatori).
Un altro articolo interessante è fatto da uno degli sviluppatori dell'Irrlicht Engine: questi ha scritto un'interessante analisi sulle differenze tra Java e C++ per vedere se poteva essere conveniente scrivere un mototre grafico per la piattaforma di Oracle. I risultati, come dice lui, danno C++ vincitore «anche se Java gli si è avvicinato»; l'autore considera anche che, ricorrendo a ottimizzazioni qui e là, si possono rovesciare i risultati a favore o a sfavore di uno o dell'altro linguaggio; inoltre (onesto e imparziale) ammette che probabilmente i calcoli sarebbero stati più favorevoli per Java se non avesse considerato il tempo di avvio della Java Virtual Machine e avesse utilizzato l'ottimizzazione -server per fare le prove. Le sue conclusioni le trovate sul link che vi consiglio di leggere perché è scritto bene: quel che volevo mostrare è che tutto sommato, le differenze di velocità in esecuzione son sicuramente migliorate.


Alla SUN facevano i server (e si vede)
Sun Microsystems era celebre per i suoi sistemi server di cui curava tutto: il processore (lo SPARC) era progettato da loro; il sistema operativo (Solaris) idem; il sistema di condivisione di file in rete (NFS) l'hanno fatto loro. Insomma, quando si trattava di server, la Sun sapeva perfettamente il fatto suo. E lato client? Non conoscete CDE, NeWS o il progetto Looking Glass? Guardateli bene e forse li troverete familiari. Forse perché

• le idee di CDE sono riprese e migliorate dal desktop environment XFCE, uno dei più famosi nel panorama open-source.
• il funzionamento di base NeWS è molto simile al window manager da Mac OS X (che usa PDF anziché postscript)
• Looking Glass sicuramente ispira uno degli ultimi brevetti registrati da Apple sulle interfacce utente

Insomma, grandi idee, ma forse gestite male. Dopotutto Sun faceva i soldi con i server e l'assistenza. Nel 1993, l'anno in cui si inizia a pensare a CDE, Microsoft stava diventando il colosso che noi tutti conosciamo e Apple, anche se in cattive acque, aveva comunque un nome con cui fare i conti. Questa mentalità da "progettisti software" si riflette anche sulle interfacce utente per la piattaforma Java: se guardate la documentazione di Java2D, vedrete che questa ha una ricchezza e una varietà di classi e di funzioni da far impallidire chiunque; se guardate come è progettata Swing vedrete che è ingegnerizzata così bene che è possibile integrare routine OpenGL come icona di un bottone (guardate qui).
Tecnicamente si tratta di cose impressionanti, ma se lanciate un programma grafico che usi Swing noterete una lentezza imbarazzante (forse Netbeans è l'unico che si salva); se avete programmato con Swing conoscerete bene l'inferno dei suoi layout. Se poi realizzate che abbiamo dovuto aspettare il 2008 e Netbeans 6 per avere un editor delle interfacce visuale (Matisse), quando Mac OS X, Windows e QT ne hanno avuto uno fin dal loro rilascio, non vi stupirete di sapere che Swing lo usano quattro gatti.
Alla Sun, evidentemente, avevano la passione per le interfacce testuali.

Facciamo un server
Se provate a scrivere un server multithread in Java avrete una gradita sorpresa: con meno di cento righe di codice sarà pronto un echo server funzionante che gestisce eccezioni e timeout. Impegnandovi potete fare un server IRC discreto in mezza giornata. Non dovrete preoccuparvi dei memory leak, sarà affidabile grazie al tanto bistrattato garbage collector (sapete che potete sceglierne sei a seconda delle esigenze?). Se poi il vostro hardware non regge e volete affiancarlo con un altro, non dovrete reimplementare niente: la JVM è scalabile, ossia sa bilanciare automaticamente il carico in maniera trasparente. Nel calcolo parallelo c'è il problema delle sezioni critiche; se in C o C++ bisogna ricorrere a semafori o mutex e fare un attentissimo debug (con più thread/processi è più difficile ricreare le condizioni di errore) in Java basta chiudere la sezione critica in una classe che abbia i metodi specificati con synchronized e il problema è risolto.

Il Domani dell'Isola di Java

Dal 1995 di strada ne è stata fatta e di cose ne sono cambiate: il grunge non va più e internet è in tutte le case. La rivoluzione client promessa da Java è stata fatta prima da Flash e poi da AJAX e Sun ha pagato le sue sviste venendo assorbita da Oracle.
La piattaforma Java è ancorata ai grandi server aziendali che devono macinare migliaia di richieste su più macchine, in maniera affidabile e scalabile. Il database NoSQL Cassandra ne è l'esempio perfetto. Ci sarà sicuramente qualcuno che continuerà a far programmi client in Java, ma piattaforme alternative più comode come Python e Ruby probabilmente gli saranno sempre più preferite. Android, che pure usa il linguaggio e il classpath, sicuramente non rifiuterà in un prossimo futuro interpreti python ottimizzati e, magari dotati di JIT.
Non sono in grado di fare previsioni: molti sistemi bancari usano Java come backend e difficilmente abbandoneranno anni di sviluppo e di test in favore di qualcos'altro (un fenomeno simile c'è in ambito scientifico con il Fortran). Tutto è nelle mani di Oracle e, in parte, della comunità Java: a loro il compito di rendere l'isola un centro frequentato, un parco naturale o una riserva.