View Full Version : Problemi con Java ... non sò più che cavolo fare ..
Giorni fa installai l'ultima versione Java 6 update 31, ma poi sul sito Fineco ho avuto problemi ed ho rilanciato con firefox l'aggiornamento automatico e si è aggiornato qualcosa.
Oggi doveva seguire un video corso su una piattaforma java e non riuscivo a partire, così ho disisntallato tutto con non pochi problemi ... :muro:
Ho scaricato le versiono offline sia 29,30 e 31 .. ora dopo aver fatto diversi tentativi, non riesco ne ad installare ne a disinstallare nulla :muro:
Se lancio qualcune installer mi dice che la versione è già installata e/o che non trova il pacchetto .msi .... :muro:
Ho provato ad usare anche JavaRa, ma non ci salto più fuori!!!
Anche reinstallando da firefox la versione specifica proposta 29 ... ma anche qui non funziona e si blocca l'installazione :mad:
Ho bisogno di risolvere il problema urgentemente!!! :cry: :cry: :cry:
Ho già provato con ccleaning, con System Mechanc ... e sembra che non ci siano chiavi e file da ripulire ...
C'è modo di eliminare a fondo i residui Java? e riuscire ad installare la versione funzionante??
:help: :help: :help:
cdimauro
28-02-2012, 08:06
E' capitato anche a me al mio ex-lavoro: ho provato ad aggiornare una versione (non ricordo quale, forse la 24) con la successiva, ed è successo un macello.
La precedente non si è rimossa del tutto, la nuova non s'è riuscita a installare, e mi sono ritrovato sommerso dalla merda, visto che anche i miei tentativi di cancellazione delle chiavi del registry di Windows sono state infruttuose (chissà quante e quali chiavi piazza sparse in giro).
Risultato: format della macchina, e reinstallazione di TUTTO il software che mi serviva (ed era parecchio). Un giorno di lavoro buttato.
dio maledica Sun, Gosling e tutti quelli che hanno collaborato a questo strumento del diavolo.
Ah, dimenticavo: ODIO profondamente il sistema di aggiornamento automatico di Java. "c'è una nuova versione di Java". OK, non me ne frega una mazza, chiudo il popup, faccio Annulla, e sparisce la fastidiosa icona. Salvo poi ripresentarsi puntualmente a OGNI login.
Il prossimo test sull'atomica di Akmadinecoso dovrebbe farlo a Santa Clara, anche se ormai è troppo tardi.
P.S. Se qualcuno conosce un tool che elimina dalla faccia della terra Java, mi faccia sapere, per favore. In alternativa mi basterebbe che lo eliminasse completamente dai miei PC.
Il pc ha solo 2 mesi di vita … devo ancora risolvere alcuni problemi di assestamento e subito se ne ripresentano altri!!! Mi girano veramente i cog:mad:
Non ho voglia di rifare tutto…. anche perché uso un SSD e meno riscrivo tutto meglio è…
Prima i problemi con il ramdisk, poi con XP mode … poi risolvo “forse” il ram disk, poi risolvo xp mode, poi no mi funziona più un altro software di grafic e mi perde login e forse giorni e giorni di configurazione ….poi faccio casino con java, poi non funziona più xp mode … CHE PALLE !!! IN 2 MESI non sono riuscito ancora a fare assestare correttamente il pc e fare un backup ufficiale!!!! :mad:
JAVA la odio, ma è indispensabile per quello che ci faccio con il pc ,…. :banned:
:help:
Questi giovani che si perdono in un bicchier d'acqua calma.
La piattaforma Java è un insieme di programmi standalone. L'installer non è un programma Java, è un programma nativo e come tutti i programmi nativi fa casino e basta.
In più non installa un bel niente: è un estrattore. Nell'exe c'è un cab e in quel cab c'è... la cartella jre. In quella cartella i jar sono compressi con Pack200, quindi dopo avera copiata bisogna decomprirli ulteriormente (con il pack200 nella cartella bin).
Prova a scaricare e installare il JDK, dovrebbe andare anche se il tuo registro è a ramengo perchè il JDK non richiede chiavi di sistema. Installa solo il JDK, non il JRE incluso.
Altrimenti se hai un altro PC con windows, copia semplicemente la cartella del JRE da lì a qui.
A questo punto hai la tua piattaforma java. Diciamo che ce l'hai in
x:\jre
I problemi arrivano quando entrano in gioco i browser. Siccome java è standalone il browser non ha bisogno di andare a vedere il registro, basta che sappia dove sta il jre, giusto?
Giusto. Però il browser va lo stesso a guardare nel registro. Non si sa perchè, è uno dei grandi misteri dell'informatica pedestre. Probabilmente perchè quando scrivi un programma in realtà non sai bene quello che fai, vai un po' alla cavolo di cane. Un chilo e venti, che faccio, lascio? Ecco, questa è l'informatica.
Sia come sia, ti serve la chiave di registro. Che dipende dal browser. Per Chrome/firefox è in:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\@java.com/JavaPlugin
I valori (tutte stringhe) sono:
"GeckoVersion"="1.9"
"Path"="x:\jre\bin\plugin2\npjp2.dll"
"Version"="170_3"
Ho fatto una prova volante e solo questi sembrano necessari (a dire il vero ho anche impostato i valori del JRE in un'altra chiave ma non dovrebbe avere effetti).
Comunque devi dare una pulita al registro prima perchè è facile che ti ritrovi con una marea di chiavi duplicate.
cdimauro
28-02-2012, 18:03
Avevo installato il JDK, e i disastri ci sono stati lo stesso.
Se in 20 anni un'azienda come Sun, che fatturava miliardi di dollari ogni anno, non è riuscita a realizzare una sistema di aggiornamento solido e funzionale (persino Opera, che è un microbo in confronto, ci riesce benissimo), è giusto che sia arrivata sull'orlo della bancarotta e sia stata acquisita.
Si dice che la sfiga ci veda benissimo. Io ho installato java dalla versione 1.1 su linux, windows, chiavette, server e chi più ne ha più ne metta e non ho mai avuto problemi.
cdimauro
28-02-2012, 18:12
Se si trattasse soltanto di sfiga, cercando "problemi aggiornamento java" non si troverebbero così tante pagine.
Altra cosa, in una macchina con XP se provo ad aggiornare con un utente limitato anziché con l'amministratore parte l'aggiornamento, e poi si blocca con un errore (che non ricordo adesso purtroppo).
Vista avrebbe dovuto insegnare da un pezzo il concetto di account limitato e amministratore (in realtà è dai tempi di NT che è così, ma tant'è).
Sun è assolutamente indifendibile su queste porcate da dilettanti allo sbaraglio.
Basta solo ricordare del bug dell'installer di questa meraviglia di SUN, si dimenticava solo di disinstallare le vecchie versioni ..... :rolleyes:
Eh be', Sun era nota per essere un'alcova di dilettanti. Specialmente tra i programmatori ci lavoravano proprio Jhonny Nessuno e Francisco Vattelapesca.
E poi per un'installer ci vuole un pozzo di scienza.
Massuvia, sistematevi il registro di windows e fate doppio click su sto' exe.
Fossero qui i problemi dell'informatica saremmo a cavallo.
SOLUZIONE
1) Scaricato questo: http://majorgeeks.com/Windows_Installer_CleanUp_Utility_d4459.html
2) Eliminate con il sw le versione residenti nel pannello di controllo (con windows risultava impossibile disinstallarle)
3) Scaricato la versione full: jre-6u31-windows-i586.exe
4) Lanciata l'installazione e portata a termine (senza problemi) :eek:
5) Aperto Firefox, acconsentito all'installazione della nuova versione del plug-in
6) ORA FUNZIONA TUTTO :sofico:
7) DISATTIVATO L'AGGIORNAMENTO AUTOMATICO JAVA :ciapet:
Mi restano solo da ripulire su firefox, nei "Componenti Aggiuntivi", la voce "JAVA Console 6.0.29" in quanto superata dalla ovviamente nuova estensione "Java Console 6.0.31"
Come elimino questa estensione obsoleta??
:mbe:
cdimauro
28-02-2012, 21:08
Eh be', Sun era nota per essere un'alcova di dilettanti. Specialmente tra i programmatori ci lavoravano proprio Jhonny Nessuno e Francisco Vattelapesca.
E poi per un'installer ci vuole un pozzo di scienza.
Massuvia, sistematevi il registro di windows e fate doppio click su sto' exe.
Fossero qui i problemi dell'informatica saremmo a cavallo.
Sono problemi anche questi, visti i danni che provocano, e sono tutt'altro che rari.
Inoltre ci sono tantissimi applicativi che non hanno alcun problema con l'installazione e gli aggiornamenti.
Java sì.
Questi sono dati oggettivi.
Fra l'altro avevo provato inutilmente a sistemare il registry con CC Cleaner (mi pare si chiami così), senza sistemare il danno.
Non so dalle tue parti, ma dalle mie il tempo vale qualcosa, specialmente quando si è a lavoro.
Verificando il registro e cercando chiavi e stringhe Java con il "Trova", ho visto che ci sono una marea di chiavi e mi sembrano tutte uguali ... :confused:
Ora con cccleaner e System Mechanic non risulta nulla di anomalo al registro od avrebbero ripulito le chiavi obsolete, non è che c'è un software in grado di pulire il registro dalle chiave doppie o triple od infinitesimali in eccesso?? :doh:
Ad esempio, tutte le voci che fanno riferimento alle versioni 29 e 30 ... cancello tranquillo?? :eekk:
I dati oggettivi qui sono che a te non si installa a me sì. Pari e patta.
Anzi, adesso clicco su java.com...
... voilà, installato. 2 dati oggettivi a 1. Vinco io.
Come lo spieghi?
Ad esempio, tutte le voci che fanno riferimento alle versioni 29 e 30 ... cancello tranquillo?? :eekk:
Togli manualmente tutte le installazioni di java che hai sul disco (i jre e i jdk, dovrebbero essere in c:\program files e in c:\program files x86), dopodichè vedi subito quali chiavi di registro fanno riferimento a cose che non ci sono più. Tutto il java che c'è è in quelle cartelle.
Non togliere i riferimenti a JavaScript.
Ho controllato e nei programmi non c'è nulla in eccesso, solo la directory
C:\Program Files (x86)\Java\jre6 (circa 89MB di dati)
e mi sembra tutto ok!
Invece nel registro ci sta un bel pò di cartelle tutte con la medesima stringa ..
http://img849.imageshack.us/img849/54/register1w.png (http://imageshack.us/photo/my-images/849/register1w.png/)
Magari è normale ... o forse no :mbe:
E queste invece ...
http://img862.imageshack.us/img862/2934/20120228220244.png (http://imageshack.us/photo/my-images/862/20120228220244.png/)
:fagiano:
i CLSID lasciali che a toglierli tutti ci metti una vita.
Javaplugin, javawebstart, jarfile, via tutti.
Elimina anche la cartella
C:\Program Files (x86)\Java\jre6
con tutto quello che ha dentro.
i CLSID lasciali che a toglierli tutti ci metti una vita.
Si infatti è un casotto, se non c'è un sw in grado di farlo automaticamente senza fare danni meglio evitare :rolleyes:
Elimina anche la cartella
C:\Program Files (x86)\Java\jre6
con tutto quello che ha dentro.
VERAMENTE?? :eek: :eek:
Ma la maggior parte delle chiavi che ho visto in Regedit puntano proprio in questa cartella ... :mbe:
Se non riesci a disinstallarlo dal pannello di controllo devi per forza cassarlo a mano.
Poi lo reinstalli quando hai pulito tutto.
Tranquillo che Windows non dipende da quello che c'è lì dentro.
Dopodichè il problema di non riuscire a rimuoverlo non dipende da quella cartella. Secondo me la chiave di registro che corrisponde al java che hai nel pannello delle applicazioni punta ad un jre che non c'è più o a quel jre lì ma con una versione diversa: s'è incriccato qualcosa lì insomma.
Continua a pulire.
:mbe:
Mi stai dicendo di disinstallare nuovamente tutto per vedere se il registro si ripulisce correttamente ... :confused:
Scusa ma ora inizio ad essere stanco e mi sto perdendo ... :stordita:
La disinstallazione totale credo di averla già fatta prima, come ho indicato nella guida fai-da-me che ho scritto sopra ed ora ho in c/programmi solo l'ultima versione installata quindi dovrebbe essere corretto ...
Restano solo chiavi in eccesso nel register probabilmente ed una Console su firefox doppia.
Ora stacco perchè non connetto più tanto bene!
Grazie 1000 per l'aiuto :ave:
Be', sì.
Io sono rimasto al "non riesco a installare/disinstallare" e "mi dice che non trova il msi".
Se non riesci a buttar via quel che c'è con il pannello di gestione delle applicazioni devi toglierli a mano.
Se vuoi si può anche far andare il JRE che hai già però prima o poi dovrai aggiornarlo, tanto vale sistemare tutto una volta e via.
Ballantine
29-02-2012, 00:21
Per togliere i vari residui delle vecchie installazioni di Java utilizzo da un po' di tempo JavaRa (http://singularlabs.com/software/javara/), oltre alla classica passata con CCleaner (con Winapp2.ini) che male non fa :)
Li ha provati entrambi senza successo. Con CCleaner io ho notato che non rimuove le chiavi dei plugin dei browser anche se fanno riferimento a versioni di java non più presenti.
Ballantine
29-02-2012, 00:31
Con CCleaner io ho notato che non rimuove le chiavi dei plugin dei browser anche se fanno riferimento a versioni di java non più presenti.
Nemmeno JavaRa riesce a togliertele?
Ha provato anche quello.
Il "problema" è che adesso gli funziona ma nel registro ha delle chiavi che non dovrebbero esserci: ha tre plugin e due javawebstart (e nessuno dei due fa riferimento all'ultima versione del JRE6)... secondo me al prossimo aggiornamento è punto e a capo.
cdimauro
29-02-2012, 08:14
I dati oggettivi qui sono che a te non si installa a me sì. Pari e patta.
Anzi, adesso clicco su java.com...
... voilà, installato. 2 dati oggettivi a 1. Vinco io.
Come lo spieghi?
Semplice: Java è un applicazione non deterministica. :asd:
A parte gli scherzi, il fatto che a te funzioni non vuol dire che gli altri non abbiano problemi. Basta una rapida ricerchina per rendersene conto, se non ti bastano la mia testimonianza e i tentativi che sta facendo l'utente Zino.
Usare la statistica per giustificare Java & compagnia mi pare una banalità bella e buona.
E' come il classico pollo di Trilussa: se tu ne hai mangiato due e io nemmeno uno, statisticamente ne avremmo mangiato uno a testa. Soltanto che io continuo ad avere lo stomaco vuoto e ad avere fame...
Ciò detto, il problema rimane. Provare a cancellare la cartella di JRE dai programmi oppure quella che ha creato in Documents and Settings (o Users/App ecc. insomma, ci siamo capiti) è perfettamente inutile, anche perché Java da qualche parte conserva il file .msi usato nell'installazione, per cui se provi a disinstallarlo s'incazza pure.
La causa di tutti i mali è il registry. Non si sa quante e quali chiavi abbia inserito l'installazione. Se fosse possibile eliminarle tutte, saremmo a posto.
Risponderei per le rime se non avessi dovuto portare in discarica duecento quintali di rottami informatici, accumulati in una vita di consumo e san giuseppe sa quante altre macchinate dovrò fare per smaltire tutto quanto. Ma sebbene stremato OCCHIO, che potrei ancora sudarti adosso.
Devo essere un acquirente compulsivo di tastiere: continuo a trovare tastiere.
cdimauro
29-02-2012, 13:10
Se sudassi tutte le chiavi del registry che inserisce Java te ne sarei grato. :D
No niente, volevo solo dirvi che portate sfiga.
Dovevo fare dei test per un'applicazione importante e il tecnico dell'azienda cliente con il quale sono in contatto ha appena avuto problemi con un aggiornamento del jre che gli ha mandato a puttane il setup.
Test rimandati a più tardi.
cdimauro
29-02-2012, 14:10
ROFL. Chiedi a PGI di prestargli il PC, che a lui Java funziona sicuramente. :D
banryu79
29-02-2012, 14:19
Al limite gli presto il mio: anche io non ho mai avuto problemi con l'installer, fino ad ora.
ROFL. Chiedi a PGI di prestargli il PC, che a lui Java funziona sicuramente. :D
A questo punto metto su un'azienda. 5000euro e vi installo Java. Ci faccio una fortuna ci faccio.
23 milioni di buzzurri hanno installato java per giocare a minecraft e voi niente.
EnricoHU
29-02-2012, 16:28
non voglio difendere i programmatori di sun, ma il motivo per cui le nuove installazioni non cancellano le vecchie è per mantenere la compatibilità di alcuni programmi che funzionano solo in presenza di una particolare versione ... :rolleyes:
cdimauro
29-02-2012, 18:46
Non è così. Stiamo parlando di aggiornamenti (chiamati update, appunto) della stessa (major) versione.
@PGI: 23 milioni vs 1 miliardo di PC. :D
In ogni caso i problemi sono tangibili, e non rari. E visto che perdurano, sarebbe stato meglio per Sun/Oracle rilasciare un tool per la rimozione completa di Java. ;)
Fatti, non pugnette.
http://www.java.com/en/about/
Un po' di parte ma considerato che dell, hp e acer vendono tutti i pc con java preinstallato penso si possa tranquillamente dire che per ogni desktop c'è un java.
cdimauro
29-02-2012, 21:37
Sì, lo so: dovevano proprio essere fatti per tirare fuori una roba così. :D
Comunque Java è molto diffuso, mai negato questo, anche se la speranza è che il lento declino acceleri un po'. :Prrr:
Be', sì.
Io sono rimasto al "non riesco a installare/disinstallare" e "mi dice che non trova il msi".
Se non riesci a buttar via quel che c'è con il pannello di gestione delle applicazioni devi toglierli a mano.
Se vuoi si può anche far andare il JRE che hai già però prima o poi dovrai aggiornarlo, tanto vale sistemare tutto una volta e via.
Si hai ragione, meglio cercare di ripulire bene tutto una volta e non procrastinare ..
Nel week-end mi faccio il backup del registro,
poi disinstallo l'ultima java update 31 (reinstallata ieri :rolleyes: ),
poi faccio girare tutti i software che conosco :D :
- JavaRA
- CCleaning
- System Mechanic
- ME NE CONSIGLIATE ALTRI?? :confused:
poi devo eliminare anche in FIREFOX i plug-in?? SI, MA COME?? :confused:
poi mi guardo tutte le chiavi restanti in Regedit usando la funzione TROVA con "java" ed ELIMINO TUTTO QUELLO CHE TROVO??? :confused:
A questo punto altro backup del registro, riavvio e reinstallo l'ultimA Java disponibile.
Riuscirà il nostro eroe a sconfiggere la terribile banda malefica SUN?? :Prrr:
Sì, lo so: dovevano proprio essere fatti per tirare fuori una roba così. :D
Comunque Java è molto diffuso, mai negato questo, anche se la speranza è che il lento declino acceleri un po'. :Prrr:
Mah, io al momento non vedo alternative. Anche perchè di piattaforme multi-language, general-purpose, noiovolevamsavuarlindiriss ce ne sono solo due, non c'è da impazzire per la varietà.
poi mi guardo tutte le chiavi restanti in Regedit usando la funzione TROVA con "java" ed ELIMINO TUTTO QUELLO CHE TROVO??? :confused:
Spulciando il mio registro direi che devi eliminare le chiavi "javasoft" (che sono quelle in cui è riportato il JRE), javawebstart e javaplugin.
Se usi firefox o chrome, guarda anche in Mozilla ed elimina le voci del plug-in java.
Ballantine
29-02-2012, 22:51
Siccome mi sono accorto solo oggi dell'uscita della versione 7u3 ne ho approfittato per vedere come "reagivano" CCleaner e JavaRa (versione 1.16).
Innanzitutto ho ovviamente disinstallato la versione 7u2. Eseguendo CCleaner non ho trovato voci residue, mentre JavaRa ha tolto una chiave di registro solo a seguito di una delle sue "Operazioni Addizionali" (credo fosse "Rimuovere Java IE BHO"). Per sicurezza ho anche aperto Firefox per controllare che non fossero rimasti dei plugin residui, ma fortunatamente era tutto a posto. Poi ho installato la versione 7u3 e ho rieseguito CCleaner e JavaRa: il primo non ha nuovamente trovato nulla, mentre il secondo ha rimosso parecchia roba (tra cui varie chiavi "javasoft" e "javaplugin", mentre per quanto riguarda "javawebstart" non ricordo... purtroppo ho già cancellato il log).
cdimauro
01-03-2012, 08:04
Mah, io al momento non vedo alternative. Anche perchè di piattaforme multi-language, general-purpose, noiovolevamsavuarlindiriss ce ne sono solo due, non c'è da impazzire per la varietà.
:mbe: Due? Quali sarebbero?
P.S. Sono serio.
cdimauro
01-03-2012, 19:52
Mah. Java multilanguage lo è diventato, e di certo non per volontà della casa madre (che nemmeno supporta i linguaggi dinamici).
.NET è tutt'altra cosa. Anche perché ha messo alla base il supporto a più linguaggi e, soprattutto, l'interoperabilità fra di loro.
Posso creare una classe in VB.NET, estenderla in C#, e utilizzarla in IronPython: roba difficilmente realizzabile coi linguaggi che si appoggiano (perché questo fanno) alla JVM.
Comunque alla fine, sì, entrambe le piattaforme sono multilinguaggio e abbastanza generali, anche se .NET, per le possibilità che offre (non dimentichiamo anche il supporto al codice unmanaged/unsafe, e C++/CLR) è decisamente avanti e, a mio avviso, preferibile alla piattaforma Java.
Francamente non riesco a trovare un'affermazione sostenibile in quel che hai detto.
A parte il "a mio avviso preferibile" ma... voglio dire, anche a me piace la pizza ma chi se ne frega.
cdimauro
01-03-2012, 22:15
A parte il "a mio avviso" ho riportato fatti oggettivi.
Singolare che l'unica cosa che ti stia bene sia l'unica parte soggettiva... :stordita:
Tu menti sapendo di mentire.
Dici "difficilmente realizzabile" ma sai che non solo è realizzabile ma è già realizzato. Quindi mi ficchi lì il "difficilmente". E in NET sarebbe facilmente? Ecco la confutazione: per me sarebbe difficile scrivere un nuovo linguaggio NET.
Confutazione del ciùla a teoria del mènga.
"Nemmeno supporta i linguaggi dinamici" è oggettivo. Ma è falso. O no? E non cercare di girarmi la frittata adesso.
cdimauro
01-03-2012, 23:37
Tu menti sapendo di mentire.
Vedremo.
Dici "difficilmente realizzabile" ma sai che non solo è realizzabile ma è già realizzato.
E perché non l'hai riportato allora?
Quindi mi ficchi lì il "difficilmente". E in NET sarebbe facilmente?
In .NET non è soltanto facile: è naturale. Vatti a vedere cosa significa CLR.
Ecco la confutazione: per me sarebbe difficile scrivere un nuovo linguaggio NET.
Confutazione del ciùla a teoria del mènga.
Vabbé, caliamo un velo pietoso.
"Nemmeno supporta i linguaggi dinamici" è oggettivo. Ma è falso. O no? E non cercare di girarmi la frittata adesso.
Dimmi quali funzionalità/bytecode offre la JVM appositamente dedicate all'implementazione e/o uso di funzionalità dinamiche.
Se mi chiedi perchè non l'ho riportato mi fai venire il dubbio che tu non lo sappia veramente. Be', si può.
Io posso tranquillamente scrivere una classe Java, estenderla in Scala e riestenderla in Ruby. Per via del bytecode... gesù non farmi fare una lezione sui formati intermedi, lo sai anche tu: qualsiasi linguaggio per la jvm può, nei limiti delle sue regole sintattiche, interagire con il prodotto di qualsiasi altro linguaggio per la jvm. Perchè non interagiscono a livello di linguaggio ma a livello di bytecode: che venga da Java o che venga da Javascript, sempre quello è.
E poi giri la frittata. Prima dici che non li supporta. Però ci sono linguaggi dinamici che girano sulla jvm. Allora mi dici che non li supporta perchè non ha istruzioni dedicate. Io ti direi che han messo invokedynamic. E tu mi diresti che una non basta. Non puoi aggiungere pezzi alla frase ad libitum.
Tu dici che la piattaforma java non supporta linguaggi dinamici, io ti dico che sulla piattaforma java gira Ruby, se Ruby è un linguaggio dinamico tu hai detto il falso.
Il CLR l'ho visto qualche tempo fa e me sembra la stessa cosa della somma delle specifiche della jvm più il bytecode più JNI. Ti dico sinceramente che a me sembra esattamente la stessa cosa.
cdimauro
02-03-2012, 07:30
Se mi chiedi perchè non l'ho riportato mi fai venire il dubbio che tu non lo sappia veramente. Be', si può.
Io posso tranquillamente scrivere una classe Java, estenderla in Scala e riestenderla in Ruby. Per via del bytecode... gesù non farmi fare una lezione sui formati intermedi, lo sai anche tu: qualsiasi linguaggio per la jvm può, nei limiti delle sue regole sintattiche, interagire con il prodotto di qualsiasi altro linguaggio per la jvm. Perchè non interagiscono a livello di linguaggio ma a livello di bytecode: che venga da Java o che venga da Javascript, sempre quello è.
Java classes can't inherit from a JRuby class (http://kenai.com/projects/jruby/pages/CallingJavaFromJRuby#Java_classes_can_t_inherit_from_a_JRuby_class)
E poi giri la frittata. Prima dici che non li supporta. Però ci sono linguaggi dinamici che girano sulla jvm. Allora mi dici che non li supporta perchè non ha istruzioni dedicate. Io ti direi che han messo invokedynamic. E tu mi diresti che una non basta. Non puoi aggiungere pezzi alla frase ad libitum.
OK, ho visto in giro e quindi finalmente si sono decisi con la JDK 7 ad aggiungere qualche supporto. Bene.
Ritiro quello che ho detto.
Tu dici che la piattaforma java non supporta linguaggi dinamici, io ti dico che sulla piattaforma java gira Ruby, se Ruby è un linguaggio dinamico tu hai detto il falso.
Eh no, io avevo detto un'altra cosa. Adesso non rigiriamo la frittata.
Non mi pare che abbia mai negato che sulla JVM girassero linguaggi dinamici (non per volontà di Sun, comunque).
Ho detto che la JVM non offriva supporto ai linguaggi dinamici, intendendo con ciò la presenza di bytecode specifici.
Hanno aggiunto invokedynamic? Mi sta bene.
Il CLR l'ho visto qualche tempo fa e me sembra la stessa cosa della somma delle specifiche della jvm più il bytecode più JNI. Ti dico sinceramente che a me sembra esattamente la stessa cosa.
A livello astratto magari sì, ma l'IL è molto diverso.
Inoltre, come dicevo prima, il CLR supporta l'esecuzione di codice unmanaged/unsafe. Infatti c'è il C++/CLR. Ora, come avrai visto con la storia di invokedynamic, non sono aggiornato sulle ultime evoluzioni della JVM, ma non ricordo che questa supporti nulla del genere.
Se l'hanno aggiunto ritiro nuovamente quello che ho detto, mi cospargo il capo di cenere, e vado a ristudiarmi la JVM.
Internet è un libro e i libri sono eventi temporalmente limitati.
Se prendi il titolo "Java classes can't inherit from JRuby class" e lo astrai dal contesto storico ottieni un'affermazione falsa.
class MyRubyClass
def doSomething(p)
p + " ...ruby"
end
end
public class Test extends MyRubyClass {
public static void main(String[] args) {
Test test = new Test();
System.out.println(test.doSomething("java?"));
}
public Object doSomething(Object param) {
Object superValue = super.doSomething(param);
return superValue.toString() + " java!";
}
}
Ma cosa c'è scritto nel paragrafo che hai linkato?
"Hopefully this feature will be added in the planned re-write of the Java integration layer in a future release of JRuby."
E così è stato.
Ma non è cambiata la piattaforma Java, è cambiato il modo in cui JRuby viene tradotto al fine di interoperare con Java.
Tra l'altro è anche significativo il fatto che a parità di piattaforma esistano implementazioni di uno stesso linguaggio che sono compatibili e incompatibili con un altro. E' significativo perchè testimonia l'irrilevanza della piattaforma: una volta che la jvm è turing completa, il resto dipende dalla sintassi delle lingue.
Sul supporto non condivido assolutamente la tua definizione ma mi chiedo se nel post originale il tuo "che nemmeno li supporta" fosse riferito a Sun o alla piattaforma.
cdimauro
02-03-2012, 15:29
Internet è un libro e i libri sono eventi temporalmente limitati.
Se prendi il titolo "Java classes can't inherit from JRuby class" e lo astrai dal contesto storico ottieni un'affermazione falsa.
class MyRubyClass
def doSomething(p)
p + " ...ruby"
end
end
public class Test extends MyRubyClass {
public static void main(String[] args) {
Test test = new Test();
System.out.println(test.doSomething("java?"));
}
public Object doSomething(Object param) {
Object superValue = super.doSomething(param);
return superValue.toString() + " java!";
}
}
Ma cosa c'è scritto nel paragrafo che hai linkato?
"Hopefully this feature will be added in the planned re-write of the Java integration layer in a future release of JRuby."
E così è stato.
Ma non è cambiata la piattaforma Java, è cambiato il modo in cui JRuby viene tradotto al fine di interoperare con Java.
OK. D'altra parte l'avevano anche scritto.
Tra l'altro è anche significativo il fatto che a parità di piattaforma esistano implementazioni di uno stesso linguaggio che sono compatibili e incompatibili con un altro. E' significativo perchè testimonia l'irrilevanza della piattaforma: una volta che la jvm è turing completa, il resto dipende dalla sintassi delle lingue.
Se così fosse non ci sarebbe alcun bisogno di estenderla: la prima versione, con lo stretto indispensabile in termini di bytecode messi a disposizione, la si potrebbe impiegare per implementare qualunque linguaggio.
Su questo ti rispondo meglio dopo.
Sul supporto non condivido assolutamente la tua definizione
In tal caso dovresti spiegarmi perché avrebbero deciso di introdurre il bytecode invokedynamic: la JVM non era forse "Turing-completa"? Non ce ne sarebbe stato bisogno...
Se è stato fatto è per agevolare, appunto, l'implementazione (e la velocità d'esecuzione) dei linguaggi dinamici. Da cui il supporto di cui parlavo.
Così faranno, forse (se non l'hanno già fatto), coi generic, che soffrono della type erasure (http://docs.oracle.com/javase/tutorial/java/generics/erasure.html) che dovresti conoscere bene.
D'altra parte, come dici tu, la JVM non è Turing-completa? Avrebbero potuto benissimo implementare i generic senza la type erasure.
Per .NET e la sua CLR, invece, Microsoft ha seguito una strada diversa: ha aggiunto, quando s'è reso necessario, tutto ciò che serviva per implementare i generic e migliorare l'implementazione dei linguaggi dinamici.
Altra cosa, e chiudo, continui sistematicamente a evitare di parlare del codice unmanaged/unsafe. Ma magari sbaglio, come al solito: la JVM è Turing-completa, e sicuramente permetterà di scrivere linguaggi come C++/CLR. ;)
ma mi chiedo se nel post originale il tuo "che nemmeno li supporta" fosse riferito a Sun o alla piattaforma.
A entrambe. Anche se la situazione è cambiata con l'ultima JVM, come hai riportato prima.
Il linguaggio Java non reifica per ragioni di retrocompatibilità. Per la jvm è indifferente.
L'ANSI-C è uno dei linguaggi supportati dalla piattaforma Java.
La piattaforma Java offre totale supporto all'indirizzamento esplicito attraverso JNI.
Perchè non lo fa la jvm? Perchè è una pessima idea in termini di portabilità. Quando inizi a gestirti ad libitum il valore di un puntatore non stai più scrivendo codice per la macchina virtuale, stai scrivendo codice per il livello sottostante.
Sun ha separato la questione e ha scritto le specifiche JNI per gestire quell'esigenza. Non puoi dire che non abbia un senso. Poi puoi anche ritenere che sia meglio avere delle istruzioni ad hoc nel bytecode della macchina virtuale ma è una questione di preferenze. Per me la jvm ha anche troppe istruzioni, se fossero meno sarebbe meglio.
Ti metto i collegamenti alla documentazione che definisce la "piattaforma Java"
http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html
http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf
Le specifiche del linguaggio Java rilevano in quando definiscono l'insieme minimo di API che ogni piattaforma Java deve possedere.
cdimauro
02-03-2012, 17:05
Al momento non ho tempo per studiarmeli. Lo farò appena possibile.
Comunque velocemente: le JNI servono ad altro. Non c'è dubbio che possano essere usate per mettere una pezza al problema (fornendo un set di API / funzioni per manipolare puntatori & compagnia bella), ma io parlavo d'altro.
In C# posso scrivere codice unmanaged/unsafe che gioca coi puntatori, senza ovviamente ricorrere a JNI/P-Invoke. Questo perché il CLR dà la possibilità nativamente di implementare linguaggi che consentano operazioni come queste.
Quindi il nocciolo della questione è: la JVM consente di fare altrettanto (quindi senza ricorrere a JNI)?
La jvm è una stack machine, quindi non ha istruzioni per la manipolazione di registri di memoria.
Ma si può usare una stack machine per simulare una registry machine. Non è efficiente perchè introduci un livello di indirezione - rappresenti i registri con una mappa di riferimenti.
Quindi la risposta è sì, può farlo ma non con lo stesso livello di efficienza di una registry machine (o di una macchina spuria com'è quella richiesta dal CLI).
MA la piattaforma Java può farlo con lo stesso livello di efficienza: tramite JNI. Il cui scopo è esattamente quello di introdurre codice unmanaged nella piattaforma. Non so perchè tu dica che non è questo lo scopo di JNI: serve solo a quello.
cdimauro
02-03-2012, 18:12
La jvm è una stack machine, quindi non ha istruzioni per la manipolazione di registri di memoria.
Ma si può usare una stack machine per simulare una registry machine. Non è efficiente perchè introduci un livello di indirezione - rappresenti i registri con una mappa di riferimenti.
Quindi la risposta è sì, può farlo ma non con lo stesso livello di efficienza di una registry machine (o di una macchina spuria com'è quella richiesta dal CLI).
Anche la CLR è una stack machine, e ha persino meno bytecode/opcode della JVM, ma nonostante tutto consente di manipolare puntatori, che poi è l'oggetto della discussione.
I registri di memoria, insomma, non c'entrano nulla.
MA la piattaforma Java può farlo con lo stesso livello di efficienza: tramite JNI. Il cui scopo è esattamente quello di introdurre codice unmanaged nella piattaforma. Non so perchè tu dica che non è questo lo scopo di JNI: serve solo a quello.
L'equivalente .NET di JNI è P/Invoke, come avevo scritto prima, e servono entrambi per accedere a quello che in Java viene chiamato codice "nativo". Una "porta" verso l'esterno, quindi.
E' chiaro che si tratti di operazioni unsafe/unmanaged, ma non hanno nulla a che vedere con questo (http://msdn.microsoft.com/en-us/library/f58wzh21.aspx) o questo (http://msdn.microsoft.com/en-us/library/zycewsya.aspx), giusto per fare un paio di esempi (maggiori informazioni si trovano qui (http://msdn.microsoft.com/en-us/library/t2yzs44b.aspx)).
Ripeto: il supporto unmanaged/unsafe di CLR consente di manipolare tranquillamente puntatori. Oltre a richiamare routine "esterne" scritte in C, C++, o quello che vuoi.
Si tratta di due cose completamente diverse.
Che poi sia possibile scrivere alcune funzioni richiamabili tramite JNI per manipolare puntatori, l'avevo già scritto. Si tratterebbe comunque di una pezza per risolvere un problema che la JVM attualmente non riesce a gestire.
Inoltre che un siffatto meccanismo sia pure efficiente è ampiamente opinabile, perché per OGNI operazione di manipolazione di puntatore sarebbe necessario eseguire uno "stub" di "ingresso" e uno di "uscita" per collegare i due mondi diversi (quello della JVM e quello esterno).
Mentre un blocco di codice unsafe che gira su CLR risulta "ottimizzato", visto che non soltanto il compilatore ha provveduto a generare apposito codice IL, ma il compilatore JIT ne farà buon uso generando codice (abbastanza) ottimizzato per l'architettura sulla quale sta girando.
Il tutto, e non è trascurabile, scrivendo codice con lo stesso linguaggio, mentre per le chiamate a JNI & P/Invoke si deve far ricorso a linguaggi "alieni", come avevo scritto.
P.S. Qui (http://stackoverflow.com/questions/453610/javas-virtual-machine-and-clr) c'è un confronto delle due virtual machine.
No non è una pezza: è il modo in cui anche NET dovrebbe funzionare se non fosse un passo indietro tecnologico.
E il CIL non è quello di una stack-machine ma è al meno spurio (e al più una cavolata) perchè le operazioni di caricamento e lettura su un "pointer type" sono operazioni di caricamento e lettura su registri. Le stack machine non ce le hanno.
Puoi opinare, ma ci sono già esempio di invocazioni JNI senza overhead. Ad esempio i metodi nativi delle API Java (tipo bytebuffer) sono invocazioni JNI ma vengono mappati su analoghe funzioni della HotSpot stessa.
Java e NET sono due piattaforme del tutto equivalenti, puoi cercare le differenze che vuoi sui singoli pezzi ma tanto fai in una tanto fai nell'altra.
L'unica differenza è che "lo standard" ECMA-335 di NET è fatto apposta perchè Microsoft possa fornirne una versione compatibile solo con sè stessa (esattamente come cercò di fare con Java).
Sto guardando quel link al confronto sulle macchine ma francamente mi sembra un po' roba da bar dello sport.
Cioè, proprio così ad occhio:
CLR non fa l'inline dei metodi virtuali, la JVM sì.
Non è vero. Neanche la JVM fa l'inline dei metodi virtuali. Casomai lo fa HotSpot ma quella è UNA jvm. E nello standard CLR non ho visto divieti all'inline.
Non c'è qualcosina di un po' più accademico?
cdimauro
02-03-2012, 19:18
No non è una pezza: è il modo in cui anche NET dovrebbe funzionare se non fosse un passo indietro tecnologico.
ROFL. E' la prima volta che leggo un'affermazione diametralmente opposta, ma non me ne stupisco visto l'andamento della discussione. :D
E il CIL non è quello di una stack-machine ma è al meno spurio (e al più una cavolata) perchè le operazioni di caricamento e lettura su un "pointer type" sono operazioni di caricamento e lettura su registri. Le stack machine non ce le hanno.
Spurio in cosa? Mi fai vedere dov'è che la CIL non si comporterebbe come una stack machine?
Alla fine un tipo puntatore è un tipo come gli altri per il CLR, ed è così che lo gestisce.
Puoi opinare, ma ci sono già esempio di invocazioni JNI senza overhead. Ad esempio i metodi nativi delle API Java (tipo bytebuffer) sono invocazioni JNI ma vengono mappati su analoghe funzioni della HotSpot stessa.
Questo perché esistono ottimizzazioni specifiche. Non puoi fare lo stesso con TUTTE le funzioni dichiarate come JNI.
Java e NET sono due piattaforme del tutto equivalenti, puoi cercare le differenze che vuoi sui singoli pezzi ma tanto fai in una tanto fai nell'altra.
A livello astratto, come avevo già scritto fin dall'inizio. E' nei "dettagli" che le differenze emergono, e non è roba da poco.
Ma alla fine che si possa fare la stessa cosa ignorando però le implicazioni che le due piattaforme comportano a livello di difficoltà d'implementazione e/o prestazionale è un ragionamento decisamente sempliciotto.
Altrimenti, come dicevo anche prima, quando alla Sun hanno pensato bene di implementare i generic copiandoli dalla concorrenza non avrebbero introdotto la type erasure. E tu sai benissimo cosa comporta questa scelta, vero?
L'unica differenza è che "lo standard" ECMA-335 di NET è fatto apposta perchè Microsoft possa fornirne una versione compatibile solo con sè stessa (esattamente come cercò di fare con Java).
Mono ti smentisce.
Inoltre Microsoft fu condannata principalmente per avere scelto di non includere l'intero mastodontico framework che Java si porta dietro (c'è uno scambio di messaggi proprio su quest'argomento fra due dipendenti Microsoft e Sun; un mese dopo quest'ultima intentò causa alla prima).
Il runtime era sostanzialmente lo stesso, con l'aggiunta di P/Invoke per richiamare nativamente le API Win32.
Che poi l'obiettivo era proprio: poter accedere alle SUE API (con la SUA virtual machine Java) senza portarsi dietro l'immagine fardello della libreria standard di Java.
Questo comunque è un altro discorso.
cdimauro
02-03-2012, 19:20
Sto guardando quel link al confronto sulle macchine ma francamente mi sembra un po' roba da bar dello sport.
Cioè, proprio così ad occhio:
CLR non fa l'inline dei metodi virtuali, la JVM sì.
Non è vero. Neanche la JVM fa l'inline dei metodi virtuali. Casomai lo fa HotSpot ma quella è UNA jvm. E nello standard CLR non ho visto divieti all'inline.
Non c'è qualcosina di un po' più accademico?
Ecco qui (http://web.eecs.utk.edu/~pauln/papers/computers_and_security-net-java.pdf). Anche se l'argomento di partenza è la sicurezza, ma mostra alcuni internal.
Il documento comunque è vecchio.
cdimauro
02-03-2012, 19:25
Anche se non propriamente accademico, c'è la sempre verde intervista ad Anders Hejlsberg (http://www.artima.com/intv/choicesP.html) su CLR e le scelte che sono state fatte, che non lesina confronti con Java e C++.
Sei un revisionista storico. Microsoft fu condannata perchè nelle e-mail dei suoi dirigenti e tecnici si leggevano cose come "fottiamo Java prima che ci porti via il mercato delle applicazioni", "dobbiamo rendere il codice Java compatibile solo con Windows" e francesismi di tal fatta.
La spuri...età (ezza?) si legge nello "standard" ECMA-335.
http://www.ecma-international.org/publications/standards/Ecma-335.htm
Adesso non trovo più il capitolo ma era intorno al 12 o giù di lì dove dice che l'effetto delle istruzioni di caricamento e lettura del valore di un puntatore sono diverse a seconda che si tratti di managed o unmanaged. Nel secondo caso le operazioni cambiano la quantità immagazzinata nell'area di memoria puntata.
E sei anche un impossibilista. Se è possibile farlo per i metodi "core", perchè non è possibile farlo per tutti? Adesso non lo fa ma lo spazio di manovra secondo me ce l'hanno.
Mono conferma, non smentisce. Guarda le prestazioni di Mono e confrontale con NET.
Poi guarda quelle dell'OpenJDK e di una delle altre quattro implementazioni.
Nel primo caso c'è un abisso, nel secondo c'è semmai qualche leggera differenza.
cdimauro
02-03-2012, 20:37
Sei un revisionista storico. Microsoft fu condannata perchè nelle e-mail dei suoi dirigenti e tecnici si leggevano cose come "fottiamo Java prima che ci porti via il mercato delle applicazioni", "dobbiamo rendere il codice Java compatibile solo con Windows" e francesismi di tal fatta.
Ricordavo bene. Ecco qui (JFC; Microsoft declares war).
La spuri...età (ezza?) si legge nello "standard" ECMA-335.
http://www.ecma-international.org/publications/standards/Ecma-335.htm
Adesso non trovo più il capitolo ma era intorno al 12 o giù di lì dove dice che l'effetto delle istruzioni di caricamento e lettura del valore di un puntatore sono diverse a seconda che si tratti di managed o unmanaged. Nel secondo caso le operazioni cambiano la quantità immagazzinata nell'area di memoria puntata.
Ho visto, ma non è così. Ti riporto la parte in questione:
The use of object references is tightly restricted in the CIL. They are used almost exclusively with the ―virtual
object system‖ instructions, which are specifically designed to deal with objects. In addition, a few of the base
instructions of the CIL handle object references. In particular, object references can be:
1. Loaded onto the evaluation stack to be passed as arguments to methods (ldloc, ldarg), and stored from the stack to their home locations (stloc, starg)
2. Duplicated or popped off the evaluation stack (dup, pop)
3. Tested for equality with one another, but not other data types (beq, beq.s, bne, bne.s, ceq)
4. Loaded-from / stored-into unmanaged memory, in type unmanaged code only (ldind.ref, stind.ref)
5. Created as a null reference (ldnull)
6. Returned as a value (ret)
Si parla di oggetti (riferimenti a) in generale. Il punto 4 dice soltanto che possono essere letti o memorizzati in zone di memoria unmanaged.
E sei anche un impossibilista. Se è possibile farlo per i metodi "core", perchè non è possibile farlo per tutti? Adesso non lo fa ma lo spazio di manovra secondo me ce l'hanno.
Quindi secondo te hanno perso una mare di tempo per soluzioni ad hoc, quando potevano sviluppare una soluzione generale per tutte le funzioni JNI.
Secondo te perché non l'hanno fatto? Perché sono incapaci? :D
Mono conferma, non smentisce. Guarda le prestazioni di Mono e confrontale con NET.
Poi guarda quelle dell'OpenJDK e di una delle altre quattro implementazioni.
Nel primo caso c'è un abisso, nel secondo c'è semmai qualche leggera differenza.
Ma perché sposti continuamente la discussione su nuovi lidi ogni volta? Uno ti risponde su un preciso punto, e tu dirotti.
"Percheeeeeeeè, lo fai, disperato ragazzo mio." (cit.). :p
E' possibile implementare versioni di .NET & compagnia diverse da quella Microsoft? Risposta: sì.
Aggiunta: ma le prestazioni sono più scarse!
OK, ma Microsoft è un colosso che ha investito vagonate di soldi, e altri... no.
Essere ricchi... è una colpa. :D
Tra l'altro Mono non è l'unica implementazione. C'è pure dotGNU (http://www.dotgnu.org/) (sigh!).
P.S. Dell'intervista che ne pensi? Non è interessante?
Insomma alla fine m'hai fatto rileggere l'ECMA. Guarda le operazioni stind e cpobj (capitolo 3). E non trovo la load ma solo perchè mi sono bruciato gli occhi a cercare quelle due.
Ricordi male
http://www.justice.gov/atr/cases/f1700/1762.htm
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language. That said, have we ever taken a look at how long it would take Microsoft to build a cross-platform Java that did work? Naturally, we would never do it, but it would give us some idea of how much time we have to work with in killing Sun's Java." Exhibit 97 (MS7 026935), P. Sridharan 9/17/97 e-mail.
Certo che 'sti americani a scriversi 'ste cose per e-mail son proprio fessi. Almeno cancellale dopo.
Salve .... vedo che la discussione è proseguita bene :D
Io avrei un problemino .... sto eliminando tutto quello che trovo di Java.....
Paura ....
cdimauro
02-03-2012, 22:04
Insomma alla fine m'hai fatto rileggere l'ECMA. Guarda le operazioni stind e cpobj (capitolo 3). E non trovo la load ma solo perchè mi sono bruciato gli occhi a cercare quelle due.
Il capitolo 3 parlava d'altro, per cui mi sono smazzato tutto il documento a caccia di ogni riferimento a quei due opcode, e francamente non vedo differenze fra la gestione dei puntatori managed e unmanaged.
Se prendi cpobj te ne rendi subito conto, visto che per il lavoro che svolge richiede un puntatore, di qualunque natura, e non fa differenze:
The cpobj instruction copies the value at the address specified by src (an unmanaged pointer, native int, or a managed pointer, &) to the address specified by dest (also a pointer).
L'istruzione di load è la ldind.
Ricordi male
http://www.justice.gov/atr/cases/f1700/1762.htm
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language. That said, have we ever taken a look at how long it would take Microsoft to build a cross-platform Java that did work? Naturally, we would never do it, but it would give us some idea of how much time we have to work with in killing Sun's Java." Exhibit 97 (MS7 026935), P. Sridharan 9/17/97 e-mail.
Più che altro riporto male, visto che ho incollato il titolo del thread al posto dell'url.
Ecco qui: JFC; Microsoft declares war (http://www.xent.com/FoRK-archive/july97/0491.html).
Se leggi le dichiarazioni di ambo le parti, capisci da dov'è partito lo scontro.
Questo senza nulla togliere all'altra roba che poi c'è finita in mezzo, come quella che hai riportato.
Certo che 'sti americani a scriversi 'ste cose per e-mail son proprio fessi. Almeno cancellale dopo.
Hanno avuto Al Capone, sono riusciti a incastrarlo per miracolo, ma non hanno imparato nulla.
Alla fine sono pur sempre americani... :asd:
cpobj è "generico" ma non basta per una registry machine se non puoi infilare un qualsiasi indirizzo in un registro. E stind lo permette quando addr è un puntatore unmanaged - mentre non lo consente se è managed, lo dice nei paragrafetti sottostanti.
ldind a differenza di stind sembra essere sempre verificata.
Ps.: heilà Zino!
cdimauro
02-03-2012, 23:13
Sarà l'ora tarda e il sonno che mi sta consumando i neuroni, ma non riesco a trovarla. A pag. 426 c'è la documentazione specifica della stind, ma o non ne parla o non arrivo a capirlo io al momento.
Per cui... buona notte.
Credo di aver sistemato Java per bene (grossa toccata di maroni :D )!
Cancellato residui e rimessa ultima versione.
Ora devo risolvere altri problemi di win :rolleyes:
Voi che ne sapete, mi sapete dire :
1) il file perfstringbackup.TMP a che cavolo serve? Mi sta massacrando il disco ssd con scritture a me estranee, considerando che non ho ancora attivato alcun backup .. :confused:
2) come faccio ad eliminare una cartella che il sistema non mi riconosce i diritti amministrativi?
Sarebbe la cartella dell'installazione errata di XP Mode ...
Premesso che sono amministratore del pc, ho già provato ad andare in modaltà provvisoria e provare da lì, ma senza successo. Ho provato a cambiare gli attributi di proprietà della cartalle perchè insiste nel dire che il padre sarebbe l'utente SYSTEM .. :confused: ... ma non riesco ... :muro:
Per il momento notte!
Da una rapida ricerca "perfstringbackup.TMP" potrebbe essere collegato a un virus o ad un processo di monitoraggio delle performance di sistema (quest'ultimo però viene indicato con il suffisso .INI).
Antivirus-Antimalware che ti dicono?
insane74
03-03-2012, 08:21
Credo di aver sistemato Java per bene (grossa toccata di maroni :D )!
Cancellato residui e rimessa ultima versione.
Ora devo risolvere altri problemi di win :rolleyes:
Voi che ne sapete, mi sapete dire :
1) il file perfstringbackup.TMP a che cavolo serve? Mi sta massacrando il disco ssd con scritture a me estranee, considerando che non ho ancora attivato alcun backup .. :confused:
2) come faccio ad eliminare una cartella che il sistema non mi riconosce i diritti amministrativi?
Sarebbe la cartella dell'installazione errata di XP Mode ...
Premesso che sono amministratore del pc, ho già provato ad andare in modaltà provvisoria e provare da lì, ma senza successo. Ho provato a cambiare gli attributi di proprietà della cartalle perchè insiste nel dire che il padre sarebbe l'utente SYSTEM .. :confused: ... ma non riesco ... :muro:
Per il momento notte!
tenere sempre a portata di mano una "live" di ubuntu (o altra distro preferita), avviare da live, fare pulizia, e via! :D
tenere sempre a portata di mano una "live" di ubuntu (o altra distro preferita), avviare da live, fare pulizia, e via! :D
Credo sia una buona idea!
Se non ci sono controindicazioni eliminerò la cartella con ubuntu da pendrive :)
Sto scaricando tutto il malloppo adesso :read:
Sto installando su chiavetta .... una 4gb lenta .... ci sta mettendo una vita :stordita:
Sembra proprio piantato di brutto .... sarà colpa di SUN ?? :ciapet:
Da una rapida ricerca "perfstringbackup.TMP" potrebbe essere collegato a un virus o ad un processo di monitoraggio delle performance di sistema (quest'ultimo però viene indicato con il suffisso .INI).
Antivirus-Antimalware che ti dicono?
Non sembra un virus ...
Tra l'altro il file .TMP sembra sparito dal sistema, e resta quello .INI ...
Se riuscissi a capire da cosa era generato quel .tmp .... pazienza, adesso sto risolvendo un'altro problema :rolleyes:
cdimauro
03-03-2012, 19:52
cpobj è "generico" ma non basta per una registry machine se non puoi infilare un qualsiasi indirizzo in un registro. E stind lo permette quando addr è un puntatore unmanaged - mentre non lo consente se è managed, lo dice nei paragrafetti sottostanti.
ldind a differenza di stind sembra essere sempre verificata.
I paragrafi in questione dovrebbero essere questi:
Correctness:
Correct CIL ensures that addr is a pointer to T and the type of val is verifier-assignable-to T. For stind.ref the type pointer at by addr cannot be a generic parameter. [Note: A stobj instruction can be used with generic parameter types. end note]
Verifiability:
For verifiable code, addr shall be a managed pointer, T&, and the type of val shall be verifier-assignable-to T .
Comunque non vedo quale sia il problema: per codice unmanaged non c'è alcun controllo, mentre per quello managed sì.
Mi pare perfettamente in linea col concetto di codice safe-managed/unsafe-unmanaged.
Cosa c'è che non va?
L'altra notte le note in stind a lding mi sembravano diverse, adesso sono speculari. Magari provo a riguardarle stanotte. Comunque quelle sono operazioni da registry-machine [edit: quando l'argomento è un puntatore unmanaged]
cdimauro
04-03-2012, 08:37
Adesso ho capito cosa intendi, ma non c'entra proprio nulla con le register-based machine.
ldind e stind consentono di leggere e scrivere usando indirizzi (arbitrari con codice unmanaged) di memoria. Non a "registri" che... non ci sono proprio.
Le VM registry-based sono tutt'altra cosa. Mettono a disposizione un set di registri "virtuali" e il compilatore genera opcode per questa ISA astratta. E' esattamente la stessa cosa di compilatore che genera codice binario per un particolare microprocessore. Vedi Dalvik, ad esempio, che penso conoscerai.
Il fatto di poter manipolare indirizzi liberamente NON fa diventare register-based una VM stack-based. Nella maniera più assoluta.
Per cui CIL rimane a tutti gli effetti stack-based.
Secondo me sì, l'unica differenza è che gli indirizzi sono reali anzichè virtuali.
cdimauro
04-03-2012, 18:06
Mi spiace, ma non c'entra proprio nulla.
Ripeto: le VM register-based hanno un set di registri che vengono utilizzati nelle varie operazioni. Al contrario di quelle stack-based che usano, appunto, lo stack per eseguirle.
La differenza fra i due tipi è questa ed è nettissima. La letteratura in merito è vasta.
Con una banale ricerca recuperi documentazione a iosa sull'argomento, ma conoscerai sicuramente le differenza fra Dalvik e la JVM standard, che sono esponenti delle due in ambito Java.
La tua letteratura è diversa dalla mia. La mia da ragione a me.
cdimauro
04-03-2012, 19:35
Certo che arrivare a questi livelli pur di difendere la propria fede, ti fa scadere molto.
Quando ho sbagliato l'ho riconosciuto e mi sono rimangiato ciò che avevo detto.
Tu, invece, hai bisogno di un bel bagno d'umiltà.
Io sono gran ciambellano del torto marcio ma ti darò ragione quando ce l'avrai. Adesso non è che voglia star qui altre cento pagine a parlare della temperatura dell'acqua calda ma figurati che per quel che so io se tu mi dici che in tanto una macchina virtuale è register based in quanto definisce dei registri - anzichè avere più generalmente operazioni su registri - allora non c'è differenza tra stack e registry machines.
Abbi pazienza ma come faccio a dirti sì? Si vede che abbiamo letto cose diverse e morta lì. Egesùmmaria fossero qui i problemi del mondo.
cdimauro
04-03-2012, 22:36
Io sono gran ciambellano del torto marcio ma ti darò ragione quando ce l'avrai. Adesso non è che voglia star qui altre cento pagine a parlare della temperatura dell'acqua calda ma figurati che per quel che so io se tu mi dici che in tanto una macchina virtuale è register based in quanto definisce dei registri - anzichè avere più generalmente operazioni su registri - allora non c'è differenza tra stack e registry machines.
Abbi pazienza ma come faccio a dirti sì? Si vede che abbiamo letto cose diverse e morta lì. Egesùmmaria fossero qui i problemi del mondo.
Qui trovi un ottimo articolo che le confronta e, ovviamente, le definisce:
Virtual Machine Showdown: Stack Versus Registers (http://static.usenix.org/events/vee05/full_papers/p153-yunhe.pdf)
Visto che parla proprio di Java, ti farà pure piacere.
Viceversa, aspetto un documento che definisca come virtual machine register-based una che fa semplicemente uso di operazioni di accesso diretto alla memoria.
Neanche a farlo apposta ce l'ho.
cdimauro
04-03-2012, 22:52
Posta pure.
Intanto eccoti un'altra pubblicazione (http://www.cp.eng.chula.ac.th/~piak/paper/1999/stackreg.pdf), e un'altra ancora (http://doc.cat-v.org/inferno/4th_edition/dis_VM_design).
Ce l'ho nel senso che quello là l'ho letto. Non avevo letto gli altri due ma sono conformi a quanto so. Che poi quel che so è quel che ho capito di quanto ho letto: potrei anche capire male, dio ci scampi dall'onniscienza.
Però quello che ho capito un senso ce l'ha.
Vedi, il punto è che il "registro" delle macchine registry è il registro nell'unico senso a me noto: è una locazione di memoria costante.
Se anzichè R1 R2 R3 scrivi 100, 200, 300 è la stessa cosa. Giusto? Immagino che si possa convenire su questo.
Ma cosè la testa di una pila in una stack machine? Nelle specifiche di una stack-machine è una locazione di memoria costante.
Capisci che se è così - e a me pare che lo sia - allora non possiamo differenziare una stack da una register sulla base di un elemento che entrambe possiedono.
Allora la diversità dev'essere da qualche altra parte. Io la diversità la vedo nelle operazioni: le operazioni della stack machine non possono decidere "dove" operare, le operazioni della registry machine sì.
Ecco perchè ti dico che non è il possesso di registri a fare la differenza, ma le operazioni sui registri.
Magari non ne convieni, ma non puoi dirmi che sia una presa di posizione arbitraria: ha una sua logica o no?
cdimauro
04-03-2012, 23:51
Da quel che hai scritto non ci sarebbe alcuna differenza fra una registry-machine e una stack-machine: entrambe operano su locazioni di memoria.
La differenza sta, appunto, nel modo in cui svolgono le operazioni.
Nelle prime un'operazione opera direttamente sulle variabili interessate, mentre nelle seconde il loro valore viene prima prelevato e inserito nello stack, e soltanto dopo viene eseguita l'operazione che agisce esclusivamente sulla cima dello stack.
Questa è l'unica differenza (formale, ma spesso anche pratica) fra i due tipi di VM.
E, come vedi, non c'entra nulla la capacità, da parte di una determinata operazione, di poter accedere a un'arbitraria locazione di memoria.
Infatti le due operazioni di cui abbiamo discusso finora, ldind e stind, operano su indirizzi arbitrari di memoria, ma sono pur sempre due classiche operazioni di load & store presenti in una VM stack-based. Questo perché inseriscono o prelevano i loro dati nello e dallo stack.
Ma si potrebbe benissimo realizzare una VM register-based che operi anch'essa direttamente con indirizzi di memoria, ma, anziché utilizzare lo stack per memorizzarli o prelevarli, avrebbe apposite operazioni che utilizzerebbero direttamente le variabili in cui tali valori sarebbero conservati.
Si tratta, insomma, di una funzionalità trasversale al tipo di VM utilizzata.
La CIL, a conti fatti, rimane una pura VM stack-based. Esattamente come la JVM.
Sono autorizzato ad un civile "non concordo"?
cdimauro
05-03-2012, 00:05
Per me puoi fare quello che vuoi.
La realtà rimane quella che ho esposto, e di cui ho portato fior di pubblicazioni.
Cesare non trattarmi male l'amico PGI-Bis!
E' sempre stato fonte di ispirazione :p
cdimauro
05-03-2012, 07:59
Ciao "Hal". Erano anni che non leggevo un tuo messaggio qui sul forum. :p
PGI spesso è fonte d'ispirazione.
L'unico difetto è che, essendovi troppo legato, capita che "difenda" Java quando nemmeno Gosling lo farebbe. Vedi sopra. :D
Salve .....
ditemi come risolvo il problema java dell'allegato prima che spacco tutto!! :huh:
cdimauro
14-03-2012, 21:12
Scusami, ma che c'entra Java? Quello è un problema di Javascript.
I due linguaggi hanno soltanto quella parola in comune: per il resto non c'entrano niente.
La mia ignoranza in materia da linguaggi di programmazione è evidente :p
Sono rimasto al TurboPascal io ..... :doh:
Quel javascript è il plug-in che ho dovuto scaricare per firefox e mi viene visto come Java plug-in .... si può risolvere?
Ogni tanto lo fa, altre volte no .... :confused:
cdimauro
14-03-2012, 22:52
Javascript non è un plugin perché generalmente è presente già col browser.
Per il resto non so qual è la causa di quell'errore.
L'altro giorno il tecnico che... be' non so esattamente che cosa perchè io lo pago per la manutenzione dei sistemi ma i sistemi non funzionano lo stesso, comunque mi diceva che alcuni suoi clienti avevano avuto problemi con i siti fineco e unicredit. Vai a sapere perchè.
Prova ad andare sul sito come chrome, premendo ctrl-shift-j per visualizzare la console degli script. Se c'è un errore nello script dovrebbe dirtelo.
La console c'è anche in firefox ma non ricordo più quale sia il pulsante per aprirla (forse la trovi nel menu strumenti alla voce "web tools" o una roba del genere).
E' strana la faccenda del plug-in, che io sappia non sono richiesti plugin per l'esecuzione di javascript.
banryu79
15-03-2012, 10:55
La console c'è anche in firefox ma non ricordo più quale sia il pulsante per aprirla (forse la trovi nel menu strumenti alla voce "web tools" o una roba del genere).
Sviluppo Web -> Consolle Web oppure Ctrl+Shift+k
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.