Sun promette: presto Java sarà open-source

Sun promette: presto Java sarà open-source

Jonathan Schwartz annuncia che a breve Java verrà distribuito con licenza open-source

di pubblicata il , alle 18:05 nel canale Programmi
 
102 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
cheng19 Maggio 2006, 06:15 #91
mmhhh...sn quasi completam. ubr..ick
cmq, sì vero..sicuramente l'algoritmo del GC è piuttosto complesso..sul fatto che non lo sapremo mai con certezza..beh, il fatto che Java stà per essere rilasciato open source direi che è un'ottima risposta
(ps..probabilmente quello che sto per dire è dettato dalle mie condizioni psicofisiche non proprio brillanti, diciamo, cmq.. malediz!! voglio le reflection in C++ (e non ditemi "c'è pure il dynamic cast", io voglio un oggetto "method" ) ..bah, farfugliazioni di un pazzoide )
ErPazzo7419 Maggio 2006, 09:43 #92
Originariamente inviato da: Azaroth
Gli algoritmi di GC di java e .NET sono l'unica cosa tenuta segreta perchè molto complicati (anche se forse adesso quello di java è pubblicamente accessibile, non saprei)
Non si basano certo su una sola metrica, possono anche essere incrementali o generazionali. Fatto sta che non lo sapremo mai con esattezza


Uno dei primi algoritmi di GC era stato fatto da un Prof. di Pisa poi è stato sostituito con un algo migliore da java2 in poi.....che io mi ricordi non era niente di difficile....ma potrei sbagliarmi era tanti anni fa.
Io cmq al momento ho sulla mia macchina i sorgenti di Java (e mi son tornati pure utili per risolvere 1 "bug" di javacomm), basta registrarsi e scaricarseli solo che ovviamente al momento non sono modificabili (come tipo di licenza)......credo che questo diventare open-source
presupponga la possibilita di modificarli a piacimento o lo possibilita di scaricarli e distribuirli senza doversi registrare.
Stavo guardando java RTS e ho visto che forse solo i sorgenti di j2se son scaricabili, forse j2ee no e questa forse sarà la novita del diventare opensource.
fabry7419 Maggio 2006, 10:31 #93
Originariamente inviato da: dupa
System.gc()
http://java.sun.com/j2se/1.5.0/docs....html#finalize()

Comunque Java e C non hanno nulla in comune, se ti han messo a programmare i n Java senza prima spiegarti basi di OOP e Ingegneria del software, non usi nemmeno il 10% delle potenzialità di java


hai mai provato ad usare quella chiamata in un programma complesso ???

sai cosa comporta ?? una Full GC... una ricerca globale e meticolosa di tutti gli oggetti non referenziati a prescindere dalle aree "eden" e "tenured". disastrosa in termini di performance...

Il nostro server si ferma per 4 (QUATTRO !!) secondi: non risponde piu' a niente e a nessuno, nonostante il GC viene eseguito in un altro thread...

sul sito della Sun e' parecchio sconsigliato usare chiamate esplicite alla GC

il peggiore dei mali e lasciare alla JVM di decidere quando fare una GC: di solito non esegue una Full GC, e il server almeno "sopravvive".
dupa19 Maggio 2006, 10:34 #94
Originariamente inviato da: fabry74
hai mai provato ad usare quella chiamata in un programma complesso ???

sai cosa comporta ?? una Full GC... una ricerca globale e meticolosa di tutti gli oggetti non referenziati a prescindere dalle aree "eden" e "tenured". disastrosa in termini di performance...

Il nostro server si ferma per 4 (QUATTRO !!) secondi: non risponde piu' a niente e a nessuno, nonostante il GC viene eseguito in un altro thread...

sul sito della Sun e' parecchio sconsigliato usare chiamate esplicite alla GC

il peggiore dei mali e lasciare alla JVM di decidere quando fare una GC: di solito non esegue una Full GC, e il server almeno "sopravvive".


Il senso di chiamare a mano il gc() è quello di chiamarlo quando sai che il tuo server è scarico.
Non è che avete qualche finalize particolarmente complessa?
fabry7419 Maggio 2006, 10:36 #95
Originariamente inviato da: ErPazzo74
Avete provato a fare la visualizzazione verbose delle GC, aiuta molto vedere quanta ram viene allocata e liberata anche per ridurre eventuali sprechi (certo un bel profiler è molto meglio) e quanto spesso vien chiamata la GC e quanto tempo impiega ogni volta....


E' proprio con questa visualizzazione che mi sono accorto del modo abominevole di usare la RAM di Java...
k0nt319 Maggio 2006, 11:13 #96
Originariamente inviato da: Azaroth
Gli algoritmi di GC di java e .NET sono l'unica cosa tenuta segreta perchè molto complicati (anche se forse adesso quello di java è pubblicamente accessibile, non saprei)
Non si basano certo su una sola metrica, possono anche essere incrementali o generazionali. Fatto sta che non lo sapremo mai con esattezza

non penso.. se fosse complicato costerebbe troppo eseguirlo
fabry7419 Maggio 2006, 11:31 #97
Originariamente inviato da: dupa
Il senso di chiamare a mano il gc() è quello di chiamarlo quando sai che il tuo server è scarico.
Non è che avete qualche finalize particolarmente complessa?


vabbe', ma vedi che vieni al mio discorso: se fosse fatto in C, per ogni richiesta il servere allocherebbe e DEALLOCHEREBBE ram e non avremmo MAI disservizio. Visto che e' in Java l'occupazione sale fino al 65% dell' heap definito e poi la JVM si spupazza una GC per deallocarla.

se la forzi tu e' ancora peggio, con disservizi vari (ed in questo caso il disservizio significa perdere soldi...)

La gestione della RAM in Java non e' adatta a programmi Server.
(mi fa' ridere che c'e' pure l'opzione -server nella JVM... )
The Son of Krypton19 Maggio 2006, 12:09 #98
>
Non credo proprio perche' il C e' un linguaggio compilato e quindi ha prestazioni migliori del java che e' interpretato.
Il java va comunque bene per programmi semplici.
<

Si ma Java viene anche usato per applicazioni realtime: controlli di processo ecc...
maxithron19 Maggio 2006, 12:14 #99
Originariamente inviato da: fek
Non userei Java o .NET per fare grafica 3d in tempo reale, ma non per le prestazioni che sono ottime. Il problema e' il controllo sul ciclo di vita degli oggetti, che in Java e .NET non e' sotto controllo del programmatore, ma dipende dal garbage collector, mentre in C++ e' sotto diretto controllo.



Con la premessa dell'indeterminabilità di 'quando' il gc interverrà sugli oggetti creati, nei limiti del possibile, in C# ci si può assicurare comunque una chiamata a IDisposable in questa maniera:

[code]
using(Object object = new Object())
{
object.SimpleTest()
}
[/code]

All'uscita dal blocco la chiamata a Dispose() è garantita.

E' scontato che l'oggetto non dovrà essere utilizzato alla fine del blocco.

Per quanto riguarda il mondo 3d, non ho nessuna cognizione ne esperienza in merito, ma, considerando la rigidità di cui si parla per l'assoluta precisione in fase deterministica per il ciclo di vita degli oggetti, effettivamente non credo che, al momento, ci siano modi diversi dal C++ per affrontare il problema.
bist19 Maggio 2006, 12:59 #100
Originariamente inviato da: sari
Dipende da ciò che devi fare. Usare il concetto che sta alla base degli oggetti in C può essere utile in molti casi. L'OOP è un "modo di pensare" che facilità la stesura e la pulizia dei programmi, non è una proprietà esclusiva di C++, Java, Python e compagnia.

Comunque C è un linguaggio di ALTO livello con pochi costrutti e parole.

Tutto giusto ma... tanto vale usare un linguaggio di più alto livello che ha questi concetti radicati nella stessa sintassi, è sicuramente più semplice e veloce.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^