Sito sul Java: ditemi cosa ne pensate

[cionci]

Processori che sono compatibili in hardaware con l'istruction set della JVM ci sono...ma non so se diffusi sui cellulari attualmente in commercio...

[theClimber]

Originariamente inviato da homero
[b]link di buone applicazioni java

Best Java Applications By Java Developers Journal:

http://www.sys-con.com/java/readersc...at=Application

Molte sono applicazioni abbastanza specifiche, specie nel campo Business to Business.
Alcuni sono Tool di sviluppo e/o deployment.


In effetti è difficile trovare un applicazione da diffusa da personal computer scritta in Java, in questi casi infatti è possibile ed economicamente conveniente, dato l'elevato numero di clienti sul mercato svilupparla con linguaggi come il c++.

Java da il meglio nel campo dello sviluppo software su commissione, dove il cliente è unico, con esigenze specifiche di Business logic ma senza bisogno di performance velocistiche. In questo caso è fondamentale la rapidità di sviluppo e di debugging e la riduzione dei costi.

Comunque non mancano le eccezioni, che potrebbero divenire + frequenti con le nuove librerie per Games e 3D:
http://www.roboforge.net

[cionci]

L'applicazione Java + "complessa" che ho usato è ArgoUML...e mi ci sono trovato pure male (certo non è colpa di Java )

[theClimber]

Originariamente inviato da cionci
[b]Processori che sono compatibili in hardaware con l'istruction set della JVM ci sono...ma non so se diffusi sui cellulari attualmente in commercio...

Sembra che motorola disponga di una JVM per Java2ME software e la venda su licenza:

http://e-www.motorola.com/webapp/sps...eId=01MyZn8X9F


Per UML in Java ti consiglio Together Control Center. Và bene anche per progetti in C++

[kingv]

Originariamente inviato da homero
[b]link di buone applicazioni java

Guarda che Control Center e JDeveloper sono scritti in java, se non sono applicazioni complesse...

[Fabrizio73]

Considero Java un linguaggio eccezionale. E' vero, il suo punto debole sono le prestazioni velocistiche, ma permette di realizzare applicazioni stupende in tempo brevissimo.

Io ho dovuto sviluppare un simulatore multi-thread di Griglie Computazionali per la mia Tesi di Laurea. Senza che conoscessi Java sono riuscito a realizzare la mia applicazione in poco più di un mese. Ho provato a realizzarla il C++, ma dopo aver dato un'occhiata alla MFC (per il multi-threading) ho deciso di lasciar perdere.

Trovo Java un linguaggio di una linearità che il C++ se la sogna, come del resto Java si sogna le prestazioni velocistiche del C++.

Così come la Sun ha realizzato una JVM per ogni piattaforma, potrebbe realizzare anche dei compilatori che generino codice macchina! Perché non lo fanno ancora?

Un ottimo sito su Java, tutto in italiano, è http://www.mokabyte.it.

Bye...

[theClimber]

Originariamente inviato da Fabrizio73
[b].....

Così come la Sun ha realizzato una JVM per ogni piattaforma, potrebbe realizzare anche dei compilatori che generino codice macchina! Perché non lo fanno ancora?

E' una scelta ben precisa, per preservare la portabilità del bytecode e anche del codice.
Se facessero veramente dei compilatori per varie architetture tutte le librerie dovrebbero essere implementate per ogni versione, con il grosso rischio che inizino a diversificarsi su ogni piattaforma.


Ciao

[Fabrizio73]

x theClimber:

Ma limitando la portabilità al solo codice potrebbero comunque mantenere le stesse librerie per ogni piattaforma e si guadagnerebbe qualcosa in velocità d'esecuzione... o mi sbaglio?

[cionci]

Originariamente inviato da Fabrizio73
[b]x theClimber:

Ma limitando la portabilità al solo codice potrebbero comunque mantenere le stesse librerie per ogni piattaforma e si guadagnerebbe qualcosa in velocità d'esecuzione... o mi sbaglio?

Concordo pienamente....quasi quasi mi metto a farlo

[Fabrizio73]

x Cionci:

Hai trovato il tuo primo acquirente... io

Lo sai... siamo (quasi) colleghi...

[theClimber]

In linea di principo si.

Il punto è che Java non è un linguaggio con una standardizzazione internazionale (es. ANSI C e C++), ma rimane proprietà di Sun.

Quello che intendevo è che per garantire la perfetta portabilità del codice, le librerie (ed anche i tipi di dato) dovrebbero essere identiche su ogni piattaforma e ciò dovrebbe essere garantito da Sun, che NON vuole farlo. In particolare ci sarebbe il rischio che per sfruttare le caratteristiche di alcune piattaforme si introducano delle caratteristiche aggiuntive che non possono essere supportate su altre piattaforme.

Nella situazione attuale invece Sun può semplicemente eseguire i test di conformità sulla JVM delle varie architetture. (E comunque si noti che con la stessa versione di JVM su architetture diverse si riscontrano alcune incongruenze dovute a bachi)

Comunque provo a fare qualche ricerca per vedere meglio quale è la posizione di Sun dal punto di vista tecnico e di politica aziendale. Appena trovo qualcosa vi aggiorno.....

bye

[Fabrizio73]

x theClimber:

Magari... mi interesserebbe molto conoscere la posizione di Sun...

[theClimber]

Come primo risultato della ricerca, il progetto GNU GCJ !!!

http://gcc.gnu.org/java/

Sembra che comunque il supporto delle librerie sia solo parziale, al momento ed è ferma al Java 1.1.

[cionci]

Sun se lo tiene molto stretto Java...pensate che dopo la sentenza del processo contro Microsoft, Sun deve approvare le JVM di Microsoft prima di renderle pubbliche...

[theClimber]

Interessante Thread sul forum Sun:
http://forum.java.sun.com/thread.jsp...e=false&q=

Si discute su come compilare codice Java.

Riassumo in ordine sparso i punti principali della discussione:

- Sun non distribuisce compilatori le già dette ragioni del 'Write once, Run anywhere' e rimanda a compilatori di terze parti. Comunque non è facile trovare una posizione di Sun ben precisa, tendono ad essere sfuggenti --> IMHO qualcosa bolle in pentola.....

- Il bytecode java è comunque compilato (tecnologie JIT, Hotspot) al momento dell'esecuzione, ma :
* Senza produrre un exe in linguaggio macchina rimane soggetto a reverse engineering
* In alcuni casi le prestazioni della compilazione run time sono insufficienti

- Se il problema è solo la facilità di deployment, esistono comodi tool di installazione (Install Anywhere - www.zerog.com , molto bello, l'ho provato ). Installano automaticamente i JRE necessari sulle varie piattaforme.

- ragioni per compilare:

Consider carefully why you want to compile to a native executable, and whether there is a Java way to accomplish your goal. There may be a good reason for compiling to native code, but it needs to be thought through. The potential advantages of compilation to native code are speed increase, less RAM use, and better protection from reverse engineering. As always, measure your results to see if you got what you wanted.

- Alcuni compilatori (oltre al già citato GCJ):

http://www.naturalbridge.com/
http://www.symantec.com/
http://www.excelsior-usa.com/jet.html
http://www.twr.com/



- Se si utilizzano classi delle librerie del JRE (Quindi la libreria NON è stata riscritta per la piattaforma specifica) è necessario includere il tutto JRE in base alla licenza SUN (Fatta apposta per evitare il caso di VJ++ in cui Microsoft utilizzava alcune cose e ne cambiava altre) . Questo comporta che un applicazione tipo "Hello World" possa anche occupare 7-8 MBytes,

Sarebbe interessante scrivere una bella FAQ su questo argomento.

Ciao

[soalle]

Scusate se mi intrometto: sapete dirmi qualcosa di più sui JIT...
Quando lancio una applicazione con
java <nomeapplicazione>
il programma java è un JIT?
Comunque ricordatevi che adesso con C# anche la Microsoft ha scelto i bytecode con un compilatore JIT.

[theClimber]

Quanda usi il comando Java, stai lanciando la Virtual Machine che interpreta il byte code. Questa è scritta in Java e contiene una reference al tipo di compilatore da utilizzare (nessuno, JIT, Hotspot). Il tipo di compilatore lo scegli in base ai parametri di configurazione del comando Java, ma di default mi sembra sia utilizzato Hotspot.

Il Problema principale del JIT è la scarsa efficienza nell'ottimizzazione della compilazione che deve essere eseguita praticamente in Real Time.

La tecnologia Hotspot (Che non è stata inventata da Sun, ma tratta da progetti preesistenti) tende ad ottimizzare la compilazione dei punti critici del codice e migliore le prestazioni mentre il codice viene eseguito. Vi sono due principali possibili problemi:
- Non esiste 1 solo o pochi punti critici --> Ottimizzazione non riesce a capire cosa ottimizzare
- Per ottimizzare in modo consistente il programma DEVE girare per moltissimo tempo. Inoltre ogni volta che rilancio il programma le ottimizzazione della run precedente sono perse.

Si dice che su applicazioni server che viaggiano per settimane senza interruzzioni la tecnologia Hotsspot fornisca prestazioni superiori a codice C ottimizzato (Questo quando il codice C è ottimizzato senza adattarsi ai dati in escuzione).

Vi è un altro vantaggio legato al riutilizzo del codice:
se riuso dei componenti di codice in condizioni diverse, magari il punto critico dell'ottimizzazione cambia e il compilatore Hotspot se ne accorge. Una compilazione statica non è in grado di adattarsi in questo modo.

Spero di essere stato chiaro, se c'è qualche punto critico fammelo sapere che magari ricerco e approfondisco.

Ciao

[soalle]

chiarissimo.... e molto gentile. Una domanda però: un compilatore JIT (e dimmi se sbaglio) una volta "interpretato/compilato" il bytecode crea di fatto un eseguibile per cui se devo rieseguire lo stesso codice (senza chiudere l'applicazione) non deve reinterpretarlo, giusto? Come lavora invece un HotSpot (oltre ad ottimizzare le sezioni critiche? Dove posso trovare in rete materiale comprensibile a riguardo?

[theClimber]

Allora, il JIT deve ricompilare il codice ogni volta. E' proprio questa la ragione per cui molti vogliono il compilatore che generi codice macchina. Sun non lo fornisce e sembra che non lo VOGLIA fornire; comunque ne esistono alcuni che ho citato sopra.

L'hotspot in raltà è una specie JIT + moderno, che cambia il codice compilato in base ai bottleneck trovati durante l'esecuzione (Ad esempio puo' rinunciare ad ottimizzare alcune aree di codice inutilizzate a favore di quelle attraversate + di frequente). il JIT classico compilava tutto indifferentemente.

Se ti interessa approfondire i discorsi su come funziona la VM e la compilazione guarda i link che ho postato sopra e specialmente quello relativo alla discussione sul forum sun che è veramente ricco di informazioni (da prendere comunque con le pinze e verificare in quanto è una semplice discussione).

Non penso sia facile trovare un sito di livello introduttivo su queste cose.

Ciao

[theClimber]

Pardon, avevo letto male.

con il JIT se NON chiudi l'applicazione e ripassi dallo setsso codice, lo dovresti trovare già compilato.
Uso il 'dovresti' in quanto mantenere traccia del codice compilato occupa chiaramente memoria RAM in aggiunta a quella della JVM usata per interpretare il codice --> a questo punto il comportamento esatto penso che dipenda dall'implementazione della specifica JVM.