Sun promette: presto Java sarà open-source

Jonathan Schwartz annuncia che a breve Java verrà distribuito con licenza open-source
di Fabio Boneschi pubblicata il 17 Maggio 2006, alle 18:05 nel canale ProgrammiJonathan Schwartz annuncia che a breve Java verrà distribuito con licenza open-source
di Fabio Boneschi pubblicata il 17 Maggio 2006, alle 18:05 nel canale Programmi
102 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infocmq, 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++
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.
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".
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?
E' proprio con questa visualizzazione che mi sono accorto del modo abominevole di usare la RAM di Java...
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
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...
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...
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.
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".