Discussione:Java (linguaggio di programmazione)

	Questa voce rientra tra gli argomenti trattati dal progetto tematico sottoindicato. Puoi consultare le discussioni in corso, aprirne una nuova o segnalarne una avviata qui.
Informatica bar di progetto monitoraggio voci

	La voce non è stata ancora monitorata, fallo ora!
nc Nessuna informazione sull'accuratezza dei contenuti. (che significa?) nc Nessuna informazione sulla scrittura. (che significa?) nc Nessuna informazione sulla presenza di fonti. (che significa?) nc Nessuna informazione sulla presenza di immagini o altri supporti grafici. (che significa?)

Java (linguaggio di programmazione)
Argomento di scuola secondaria di II grado
Materia	informatica
Dettagli
Dimensione della voce	49 050 byte
Progetto Wikipedia e scuola italiana

confusione

Mi sembra che ci sia una certa confusione tra il linguaggio Java e il JDK: Java è il linguaggio puro e semplice, che è adesso alla versione 2, mentre JDK significa Java Developer Kit, ed è una serie di programmi (tra cui la virtual machine e il compilatore) che servono a sviluppare codici in Java. Per questo motivo le versioni di Java (linguaggio) e JDK (toolkit) non coincidono. Infatti si può compilare ed eseguire programmi scritti in java anche senza JDK.

Paky 15:22, Mar 5, 2004 (UTC)

Completamente d'accordo. E' proprio così. Il JDK è una cosa, il Java è un'altra cosa (un linguaggio di programmazione).

ik1tzo 15:45, Mar 5, 2004 (UTC)

-

vorrei lasciare un commento su questo articolo. A mio parere ci sono troppe valutazioni personali dell'autore all'interno di un testo che dovrebbe essere assolutamente scientifico. Inoltre alcune opnioni sono un po' raffazzonate, non supportate da dati scienfici (rimandi a test e dati ufficiali - quelli relativi alle performance,è chiaro che un linguaggio compilato è più veloce, ma di quanto? prove, test ufficiali?) Opinioni come "L'apprendimento del linguaggio non è difficile." Ma che significa? Non è difficile in relazione a cosa e a chi? Il paragrafo sulla portabilità vuole far sottintendere che si debba tremare ogni volta che si lancia un'applicazione java su linux piuttosto che su windows, pronti a debuggare l JVM, il che è davvero molto distante dalla realtà dei fatti. L'ordine degli IDE è sballato, andrebbe seguito un criterio di popolarità nell'elenco, mentre invece è completamente capovolto. Intellij sarà un buon ide, ma chi lo usa? per non parlare di Bluj.

Nell'ambiente Eclipse

come si fa a aggiungere all'elenco dei metodi che compare quando si digita dopo l'oggetto "." una descrizione dei metodi come accade in NetBeans?

Ragazzi, uno che programma in Java con NetBeans ! Perchè vuoi passare a Eclipse, che è troppo IBM oriented? NetBeans è ottimo. Oppure, meglio ancora Idea che è una favola. Scrivimi che ci parliamo, mi interessa sempre scambiare idee con chi programma in Java. Gac 09:41, Ott 29, 2004 (UTC)

Scusate, ma perchè avete riaggiunto MacOsX tra gli OS per i quali è disponibile la 1.5 quando son ancora fermi alla 1.42? Avevo corretto la cosa ieri sera, ma oggi è di nuovo errrata.

Perchè dall'ultima versione di MacOSX (Tiger) la 1.5 è supportata (vedi link http://www.apple.com/macosx/features/java/ ) --Fridrik 20:28, ott 3, 2005 (CEST)

Aggiunte

Ho aggiunto 2 righe per l'eredità, più avanti inserirò anche le interfacce e le classi astratte se non lo avrà già fatto qualcun'altro per allora

Silyus 19:02, 20 gen 2006 (CET)

Secondo me, in Java non è possibile parlare di ereditarietà prescindendo dal discorso polimorfismo. Sarebbe bene aggiungere qualche riga anche per quest'ultimo argomento, che ne dici?

Scusate, secondo me è inutile inserire spiegazioni che riguardano le caratteristiche della programmazione ad oggetti come il polimorfismo. Credo che le spiegazioni su questi argomenti dovrebbero essere trattate esclusivamente nelle pagine dedicate alla OOP. Però troverei molto interessante una sezione (es. in basso) su *come* java mette a disposizione gli strumenti della OOP.

Konzen 00:12, 26 feb 2006 (CET)

Concordo sul fatto che 2 righe sul polimorfismo non guasterebbero, se puoi aggiungi pure tu stesso la relativa parte in coda alla mia aggiunta sull'ereditarietà, altrimenti ci penserò io in settimana Silyus 19:02, 20 gen 2006 (CET)

Cancellature

Avevo aggiunto un paragrafo sulla Valutazione di Java. Ho scritto la verità, cioè che un programma in Java è più lento, specie se troppo grande (vedi il costosissimo Poseidon, che rende l'ultimo computer come uno di 6 anni fa). Perché chiudete gli occhi, che ci guadagnate? Inoltre, avete provato a fare una scansione antivirus e notare che quando l'antivirus arriva a Eclipse impiega 2 ore? Java ha i suoi vantaggi, ma gli svantaggi VANNO scritti. Per libertà. UnoChePensaConLaSuaTesta

Sicurezza in Java

Ciao , scusate, sto cercando di capire qualcosa riguardo il meccanismo di caricamento dinamico delle classi in Java. Da quello che ho capito vi è :

-un bootstrap class loader che carica le classi del core java API , ovvero quelle in rt.ja -un class loader per caricare le estensioni ,ExtClassLoader -un class loader per caricare dal CLASSPATH ,AppClassLOader

Poi se desidero posso implementare un class loader personalizzato derivando dalla classe "ClassLOader" e a paertire da Java 2 anche da "SecureClassLoader". In Java 2 la gerarchia dovrebbe essere la seguente:

ClassLoader--SecureClassLOader--URLClassLOader--AppletClassLoader

Quello che mi chiedo io è: 1-ExtClassLoader ed AppClassLoader derivano da URLClassLOader?

2-Ogni browser implementa il proprio class loader per effettuare il caricamento delle applets, Ma quando il browser scarica un'applet da una pagina e poi scarica un'altra applet da un altra pagina diversa dalla prima, allora utilizza 2 class loader diversi? E se scarica due voilte dalla stessa pagina utilizza sempre il medesimo class loader? E ancora , Ogni class loader pone le classi che ha scaricato in un proprio "namespace", in modo che le applet diverse non possano interferire tra di loro, ma se voglio che le applet comunichino tra di loro, come devo fare?

3-Ma cosa introduce effettivamente in più il SecureClassLOader?, gestisce forse il domini di protezione?

4- molte volte ho trovato scritto "classLoader di sistema"in nnumerosi documenti in rete, ma questo class loader è il bootstarp ClassLoader o cosa?

5-La classe viene caricata dinamicamente mediante i metodi loadClass, e infine viene definita da "defineClass", se non ho capito male, quest'ultimo metodo si occupa anche di passare il bytecode al verificatore, e di inserire la classe in un "dominio di protezione" che volendo può essere passato come parametro. Adesso io mi chiedo , e se non passo nessun dominio di protezione come parametro, la classe dove viene inserita? e con quali permessi? I domini di protezione possono essere creati staticamente, ad esempio quando passo il dominio di protezione al "defineClass" e anche dinamicamente, cioè vengono creati esaminando i permessi delle policy? ma da chi viene effettuato questo esame? Si tratta forse dell AccessController?

Il Software sotto licenza GPL è Software Libero (Free Software), il fatto che i sorgenti siano aperti non significa che sia "opensource": un pre-requisito del software libero è la disponibilità del codice sorgente, il software libero stabilisce le libertà degli utenti, quindi per favore: non utilizzate l'espressione opensource quando intendete Software Libero e software sotto GPL. Mi raccomando!!

Modifiche

Ho modificato la sezione contenente le date di rilascio di Java in quanto non riportava la data completa (era presente solamente l'anno). Ho comunque tenuto come commento alla pagina la vecchia lista in quanto vi erano le informazioni relative alle piattaforme per cui furono rilasciate

--Henryx 22:08, 14 giu 2007 (CEST)

Schede acceleratrici, acceleratori

Diversi utenti insistono nell'inserire una frase secondo cui il bytecode Java è eseguito o da una macchina virtuale o da apposite schede acceleratrici (o acceleratori). Vorrei spiegazioni perché:

• il bytecode è eseguito in ogni caso da una macchina virtuale java (per definizione); la JVM può essere implementata in software o hardware, ma resta una JVM. Faccio notare che la JVM tecnicamente è una specifica di un processore. Il fatto di confondere la JVM con uno specifico "interprete" Java (per esempio il comando "java" della SDK) è un errore concettuale;
• sinceramente non conosco l'espressione "schede acceleratrici" ma decisamente non mi suggerisce l'idea che una scheda acceleratrice sia un concetto paragonabile alla JVM (per cui si possa usare la frase di cui sopra, "il bytecode è eseguito da X o da Y"). La mia impressione è che una scheda acceleratrice sia un particolare "pezzo" di alcune "specifiche implementazioni hardware" della JVM. In questo caso, la frase incriminata suonerebbe come: "una automobile viene spinta avanti da un motore o da un iniettore multijet". Nella migliore delle ipotesi (ma non credo) una scheda acceleratrice è una implementazione hardware della JVM (ma la frase di cui sopra resta sbagliata).

Il link fornito da uno degli utenti interessati ([1]) conferma la mia impressione: una scheda acceleratrice (come dice il nome peraltro) sarebbe un pezzo di hardware progettato per aumentare le prestazioni di Java. Moongateclimber 04:55, 22 ott 2007 (CEST)

La prima obiezione può essere vera (quindi la precisazione può essere migliorata), ma questo non toglie il fatto che la disponibilità di schede acceleratrici hardware sia reale e quindi la sostanza della precisazione è di fatto corretta. Quella che viene un po' superficialmente definita da Moongateclimber come "pezzo di hardware progettato per aumentare le prestazioni di Java", deve funzionare in un determinato modo: il modo è che il java bytecode viene intepretato da questo apposito componente hardware, come si può dedurre dallo stesso articolo o da altre pagine reperibili in rete. Se non ci sono ulteriori obiezioni, entro un paio di giorni rimodificherò quindi la frase nel seguente modo: "Il bytecode verrà quindi interpretato da una macchina virtuale implementata come software o come apposito acceleratore hardware". ekerazha 11:48, 22 ott 2007 (CEST)

Se il codice sorgente java è interpretato, il derivato bytecode è un codice compilato a tutti gli effetti e non si può quindi dire bytecode verrà quindi interpretato da una macchina virtuale bensì bytecode verrà quindi eseguito da una macchina virtuale. La possibilità di avere hardware specifico che implementi una JVM sarà senz'altro vera, ma non mi risulta particolarmente diffusa ed inoltre è l'esatto contrario della filosofia di Java (l'hardware dev'essere ovviamente specifico per la particolare configurazione utilizzata, mentre Java nasce proprio per essere indipendente da hardware e sistema operativo). Noto che l'articolo citato è del 2001, non proprio recentissimo vista la materia :-) ; mi sembra che i (relativi) problemi di velocità esecutiva che Java aveva sofferta nella sua fase inziale siano stati successivamente superati dalla tecnologia JIT e dall'incremento delle prestazioni della JVM piuttosto che dalla diffusione di hardware specifici. Gac 12:18, 22 ott 2007 (CEST)

Il codice viene eseguito da una macchina virtuale che lo intepreta traducendo just-in-time il java bytecode in "codice nativo". Il fatto che non sia diffusissimo è abbastanza irrilevante, il dato di fatto è che esistono e che vengono utilizzati laddove si necessiti di particolare velocità nell'esecuzione/intepretazione di java bytecode. Anche il fatto che quel particolare articolo sia del 2001 è abbastanza irrilevante: quel tipo di scheda è tutt'ora in produzione e vendita. ekerazha 23:21, 29 ott 2007 (CET)

Io penso (ma è bene essere qui a discuterne) che anche "Il bytecode verrà quindi interpretato da una macchina virtuale implementata come software o come apposito acceleratore hardware" sia una frase scorretta; infatti non ritengo che un acceleratore sia una implementazione della JVM. A quanto ho capito, si tratta di un componente hardware che velocizza il funzionamento di una JVM (non so se con riferimento alle sole JVM hw o anche a quelle sw); in ogni caso non mi sembra che un acceleratore sia una implementazione della JVM (così come il sistema per il turbo non è un motore). Se si possono avere riferimenti in merito, sono pronto a cambiare idea. Moongateclimber 13:01, 22 ott 2007 (CEST)

Il funzionamento è quello che ho illustrato. Cercando rapidamente su Google ho trovato questa pagina http://www.freepatentsonline.com/20060200801.html "A hardware Java accelerator is provided to implement portions of the Java virtual machine in hardware in order to accelerate the operation of the system on Java bytecodes. The Java hardware accelerator preferably includes Java bytecode translation into native CPU instructions." Quindi di fatto è una JVM implementata in "hardware". ekerazha 23:21, 29 ott 2007 (CET)

Esattamente quanto intendevo: A hardware Java accelerator is provided to implement portions of the Java virtual machine. L'acceleratore è parte dell'implementazione della JVM, quindi non si può dire che esegue il bytecode. Moongateclimber 05:33, 30 ott 2007 (CET)

Leggi tutto, "The Java hardware accelerator preferably includes Java bytecode translation into native CPU instructions". Il concetto è che non necessariamente la scheda acceleratrice provvede a tradurre tutte le istruzioni, ma potrebbe anche accelerarne solo alcune... o anche tutte: dipende dalla scheda. Di fatto, come è anche riportato, la scheda esegue/interpreta bytecode traducendolo in codice nativo per la CPU, proprio come fa la Sun JVM ad esempio. ekerazha 11:36, 31 ott 2007 (CET)

Non capisco proprio la tua obiezione. Se la scheda è parte dell'implementazione della JVM (su questo siamo d'accordo si o no?) non puoi citarla come alternativa alla JVM. E comunque, non è vero che la JVM "traduce" il bytecode in istruzioni native della CPU; come ha giustamente osservato qualcun altro, la JVM esegue le istruzioni (vedi differenza fra compilatore e interprete). La scheda acceleratrice sembra facilitare il compito della JVM nello stesso modo in cui questo viene facilitato dalla compilazione JIT. Non penso che tu vorresti considerare corretta la frase "il bytecode viene eseguito dalla JVM o da un compilatore JIT", che mette a confronto mele con arance; ed esattamente lo stesso "miscuglio" improprio nasce dal mettere sullo stesso piano la JVM con una scheda hardware che la implementa parzialmente (o anche totalmente, tra l'altro). Moongateclimber 13:42, 31 ott 2007 (CET)

No non siamo d'accordo :-D Da quanto si legge, la scheda acceleratrice non è "parte" della JVM, ma la *rimpiazza* nell'esecuzione/intepretazione del Java bytecode. Per il secondo discorso ti consiglio la lettura di questo: http://it.wikipedia.org/wiki/Compilatore_just-in-time (la compilazione JIT che ho già citato): "compilatore just-in-time o JIT permette un tipo di compilazione, conosciuta anche come traduzione dinamica, con la quale è possibile aumentare le performance dei sistemi di programmazione che utilizzano il bytecode, traducendo il bytecode nel codice macchina nativo in fase di run-time". Se una scheda acceleratrice hardware rimpiazza la Sun JVM nell'esecuzione/intepretazione delle istruzioni, per l'appunto la rimpiazza e funge da JVM. ekerazha 14:59, 1 nov 2007 (CET)

Se non siamo d'accordo su quel punto è inutile continuare. Per definizione, il bytecode Java è eseguito dalla JVM ([2]). Punto e basta. Qualsiasi cosa esegua il bytecode è una JVM. Non esistono alternative. Moongateclimber 16:57, 1 nov 2007 (CET)

Nessuno ha detto il contrario, ho solo detto che è precisabile che questo compito può essere svolto sia via software che da schede acceleratrici hardware... e questo mi sembra assodato, quindi in mancanza di altre obiezioni di rilievo provvederò all'inserimento della precisazione nei prossimi giorni. ekerazha 12:52, 3 nov 2007 (CET)

Tieni presente che se quel paragrafo deve entrare nel merito di come è implementata la JVM, allora ci sono numerose alternative (e "schede acceleratrici" non può essere indicata come l'unica alternativa al software). Restano poi tutte le obiezioni di rilievo già fatte (es. una scheda acceleratrice non solo non è una JVM (assodato) ma non è neanche una implementazione di una JVM. Quindi io ti consiglierei di proporre qui il testo e discuterne prima di inserirlo, perché al di là delle apparenze ho seri dubbi che ci sia consenso su una specifica frase. Moongateclimber 10:29, 4 nov 2007 (CET)

Le uniche alternative sono "via software" o "via hardware" (con le apposite schede acceleratrici), non ci sono altre alternative relativamente a questa distinzione. Tutte le obiezioni sollevate in merito sono state chiarite con link a pagine che parlano dell'argomento, compresa quella che una scheda acceleratrice funga da JVM eseguendo/interpretando Java bytecode e "traducendolo" in codice nativo (JIT compilation) ;-) la frase che ho intenzione di inserire e che è già stata discussa è quella che avevo riportato sopra... la ripropongo: "Il bytecode verrà quindi interpretato da una macchina virtuale implementata come software o come apposito acceleratore hardware". ekerazha 14:09, 4 nov 2007 (CET)

Concordando con quanto accennato da Gac, inoltre, devo dire che l'implementazione hardware della JVM non mi sembra né una soluzione predominante né una linea di tendenza particolarmente enfatizzata da Sun. Implementazioni hw della JVM sono sempre state previste in teoria e sperimentate in pratica, ma non largamente diffuse, con la possibile eccezione del mondo embedded/micro (ma anche qui, vedi i cellulari per esempio, la JVM a quanto ne so tende a essere comunque principalmente o esclusivamente sw). Questo non toglie né complementa la mia obiezione di cui sopra, che è legata alla volontà di usare il rigor di termini in una voce enciclopedica, e che quindi resta valida a prescindere da queste considerazioni. Moongateclimber 13:05, 22 ott 2007 (CEST)

Risposto ;-) ekerazha 23:21, 29 ott 2007 (CET)

Schede acceleratrici, punto e a capo

Riporto qui la discussione perché l'indentazione cominciava a essere un po' ingestibile. E' stato convenuto che la JVM può essere implementata via software o via hardware. Ekerazha vorrebbe introdurre questo concetto nella voce dicendo

«Il bytecode verrà quindi interpretato da una macchina virtuale implementata come software o come apposito acceleratore hardware»

Io ancora mi oppongo, perché sostengo che dire che la JVM può essere implementata via hardware non è equivalente a dire che può essere implementata con schede acceleratrici. Primo, per il solito motivo: non vedo una dimostrazione che una scheda acceleratrice sia una implementazione della JVM (e non solo parte di una implementazione). Secondo, non vedo da nessuna parte una dimostrazione del fatto che una implementazione hardware debba per forza essere basata su schede acceleratrici. La Sun ha da sempre ipotizzato la realizzazione di processori Java (JVM "fisiche") e questo concetto mi sembra molto più generale di quello di scheda acceleratrice. Facendo una ricerca su Google trovo, per esempio, questo link ([3]) in cui si citano (per il settore specifico dell'embedded, che secondo me è quello che Ekerazha ha in mente) tre alternative all'implementazione della JVM: software, hardware dedicato, schede acceleratrici. Anche in questo corso online si parla dell'esecuzione di Java da parte di un "processore Java", senza menzione alle schede acceleratrici. Ora, se ci sono (come sono certo che ci siano) N approcci architetturali all'implementazione hardware delle JVM, o si citano tutti o non se ne cita nessuno e si rimane sul vago. Meglio ancora, si rimane sul vago a livello generale e poi si sviscera (in modo accurato e completo) in una sezione dedicata. Altrimenti, è come se uno dicesse "i dati persistenti sono memorizzati su disco o in una tabella di database relazionale", frase sbilenca perché anche i database sono su disco, e non ci sono solo quelli relazionali. Moongateclimber 18:47, 4 nov 2007 (CET)

Tra l'altro, i "Java accelerator" (vedi per esempio Jazelle) possono essere di due tipi: uno esegue bytecode (il che non vuol dire che sia una implementazione completa della JVM, come al solito), uno invece fornisce servizi per migliorare le prestazioni dei compilatori JIT. [4]. La questione continua a sembrarmi più complessa, e da trattare più organicamente, di quanto suggerirebbe un riferimento "buttato lì" agli acceleratori. Moongateclimber 18:59, 4 nov 2007 (CET)

Infatti io *nella modifica proposta non ho parlato di "schede acceleratrici"* (anche se probabilmente sono la tiplogia di implementazione più "accessibile"), ma di "acceleratori", che è la definizione che si ritrova comunemente ad indicare implementazioni in hardware della JVM. Il comune funzionamento di questi acceleratori è già stato ripetutamente riportato anche attraverso link a pagine esterne. L'acceleratore Jazelle qui linkato, *oltre a svolgere questa funzione* implementa anche alcune istruzioni aggiuntive in grado di migliorare ulteriormente le prestazioni. Non so se sia veramente il caso di creare una sezione dedicata per una precisazione di 1 riga. ekerazha 13:54, 13 nov 2007 (CET)

Sostituisci pure "acceleratore" al posto di "scheda acceleratrice" nelle mie osservazioni di sopra. Nessuno dei link che hai citato mi ha convinto del fatto che una parola che deriva da "accelerare" possa essere sinonimo di "processore" (perché una implementazione hardware di una JVM deve essere un processore). Moongateclimber 16:23, 14 nov 2007 (CET)

Mah... mi sembra un'obiezione alquanto futile. Anche gli "acceleratori grafici" erano processori (solitamente montati su schede dedicate... come pure alcuni acceleratori Java qui menzionati). Non vedo alcuna motivazione sensata per la quale un processore che "accelera" non possa essere definito "acceleratore" (come d'altronde è definito *nei fatti*, vedi le pagine linkate). Se poi a te non convincono amen... ma rimane una terminologia usata *di fatto*. ekerazha 15:59, 25 nov 2007 (CET)

Continuiamo a parlare di due cose diverse. Una scheda acceleratrice può benissimo essere un processore, quello che non ho ancora visto dimostrato è che sia un processore Java (una implementazione completa delle specifiche della JVM). Moongateclimber 17:44, 25 nov 2007 (CET)

Era riportato in uno dei siti che avevo linkato sopra tempo fa (e l'avevo pure esplicitato). Comunque anche "ipotizzando" che non sia *completa*, questo non toglie che svolga la mansione di convertire in hardware tutte/alcune istruzioni Java bytecode in codice nativo, come nuovamente riportato nelle suddette pagine linkate. ekerazha 12:32, 21 gen 2008 (CET)

Interfaccie Grafiche

Ehilà! Ho messo i link a java.awt (che ho tradotto dall'inglese) e a Swing... Conte91 (msg) 23:19, 20 mar 2008 (CET)

Linguaggio C

Perché nella pagina c'è il template del linguaggio C? Non sarebbe opportuno un template sul linguaggio Java? LoStrangolatore (msg) 12:50, 5 nov 2009 (CET)

Hai ragione. Ho proposto una modifica. --Outer root >echo 17:18, 5 nov 2009 (CET)

Link inesistente

Ciao a tutti scusate ho visto che la parola "sicuro" è un link che però porta alla stessa pagina, non è neanche un link interno. E' da cancellare o magari è un link in attesa della voce "sicurezza" come si può vedere dal codice?— Questo commento senza la firma utente è stato inserito da 79.28.102.130 (discussioni · contributi) 11:20, 26 set 2011 (CEST).

Grazie della segnalazione, nell'incertezza ho provveduto a rimuoverlo.--B3t (msg) 11:43, 27 set 2011 (CEST)

Versioni nascoste nel capitolo "Versioni"

Nella sezione "Versioni" alcune sono commentate dall'utente Henryx con questa motivazione "Eliminati in quanto non viene riportata la data di rilascio (Henryx)" Per quelle viene riportato solo l'anno, ma non mi pare una buona ragione per depennarle dalla voce. Commenti? --Raffaele.castagno (msg) 00:49, 23 ott 2011 (CEST)

Aggiunto un nuovo esempio di HelloWorld

Ho aggiunto un esempio di programma per la stampa della stringa Hello World! che sfrutti i concetti della OOP. Ho anche provveduto a spiegare un minimo il codice degli esempi precedenti! Hellslord (msg) 12:20, 23 giu 2012 (CEST)

Ri-organizzazione della voce

Questa voce ha bisogno di diverse modifiche. La sezione relativa alla curiosità potrebbe essere rimossa per intero. Quella sulle versioni dovrebbe contenere le modifiche che il linguaggio ha avuto nel tempo, così come è adesso ha una utilità molto limitata. La sezione Hello World è troppo grande e va ripensata. --Vitalij zad (msg) 16:35, 1 lug 2014 (CEST)

Paragrafo "Linguaggio"

Non mi sembra enciclopedico presentare un linguaggio attraverso una serie di programmi di esempio, siamo su Wikipedia non su stackoverflow. --Andreabont (MSG) 23:35, 12 lug 2016 (CEST)

Collegamenti esterni modificati

Gentili utenti,

ho appena modificato 2 collegamento/i esterno/i sulla pagina Java (linguaggio di programmazione). Per cortesia controllate la mia modifica. Se avete qualche domanda o se fosse necessario far sì che il bot ignori i link o l'intera pagina, date un'occhiata a queste FAQ. Ho effettuato le seguenti modifiche:

• Aggiunta del link all'archivio https://www.webcitation.org/67yahbjPg?url=http://www.langpop.com/ per http://www.langpop.com/
• Aggiunta del link all'archivio https://web.archive.org/web/20090321180726/http://electronicdesign.com/Articles/Index.cfm?ArticleID=2255&pg=3 per http://electronicdesign.com/Articles/Index.cfm?ArticleID=2255&pg=3

Fate riferimento alle FAQ per informazioni su come correggere gli errori del bot

Saluti.—InternetArchiveBot (Segnala un errore) 05:54, 3 ott 2017 (CEST)

Collegamenti esterni modificati

Gentili utenti,

ho appena modificato 1 collegamento/i esterno/i sulla pagina Java (linguaggio di programmazione). Per cortesia controllate la mia modifica. Se avete qualche domanda o se fosse necessario far sì che il bot ignori i link o l'intera pagina, date un'occhiata a queste FAQ. Ho effettuato le seguenti modifiche:

• Aggiunta del link all'archivio https://web.archive.org/web/20070611104244/https://openjdk.dev.java.net/ per https://openjdk.dev.java.net/

Fate riferimento alle FAQ per informazioni su come correggere gli errori del bot

Saluti.—InternetArchiveBot (Segnala un errore) 16:25, 14 mar 2018 (CET)

Collegamenti esterni modificati

Gentili utenti,

ho appena modificato 2 collegamento/i esterno/i sulla pagina Java (linguaggio di programmazione). Per cortesia controllate la mia modifica. Se avete qualche domanda o se fosse necessario far sì che il bot ignori i link o l'intera pagina, date un'occhiata a queste FAQ. Ho effettuato le seguenti modifiche:

• Aggiunta del link all'archivio https://web.archive.org/web/20090523111129/http://radio.weblogs.com/0100490/2003/01/28.html per http://radio.weblogs.com/0100490/2003/01/28.html
• Aggiunta del link all'archivio https://web.archive.org/web/20151103174045/https://home.java.net/ per https://home.java.net/

Fate riferimento alle FAQ per informazioni su come correggere gli errori del bot

Saluti.—InternetArchiveBot (Segnala un errore) 00:18, 11 set 2018 (CEST)

Collegamenti esterni modificati

Gentili utenti,

ho appena modificato 1 collegamento esterno sulla pagina Java (linguaggio di programmazione). Per cortesia controllate la mia modifica. Se avete qualche domanda o se fosse necessario far sì che il bot ignori i link o l'intera pagina, date un'occhiata a queste FAQ. Ho effettuato le seguenti modifiche:

• Aggiunta del link all'archivio https://web.archive.org/web/20061115064813/http://today.java.net/pub/a//today/2006/11/13/open-source-java-editorial.html per http://today.java.net/pub/a//today/2006/11/13/open-source-java-editorial.html

Fate riferimento alle FAQ per informazioni su come correggere gli errori del bot.

Saluti.—InternetArchiveBot (Segnala un errore) 11:49, 6 giu 2019 (CEST)

Collegamenti esterni interrotti

Una procedura automatica ha modificato uno o più collegamenti esterni ritenuti interrotti:

• Aggiunta del link all'archivio https://web.archive.org/web/20090803031758/http://www.javaworld.com/javaworld/jw-10-1996/jw-10-javaname.html per http://www.javaworld.com/javaworld/jw-10-1996/jw-10-javaname.html
• Aggiunta del link all'archivio https://www.webcitation.org/65tawvVM4?url=http://www.oracle.com/us/sun/index.htm per http://www.sun.com/software/opensource/java/faq.jsp

In caso di problemi vedere le FAQ.—InternetArchiveBot (Segnala un errore) 17:44, 23 apr 2021 (CEST)

Collegamenti esterni interrotti

Una procedura automatica ha modificato uno o più collegamenti esterni ritenuti interrotti:

• Sostituzione del link all'archivio https://www.webcitation.org/65tawvVM4?url=http://www.oracle.com/us/sun/index.htm con https://web.archive.org/web/20120303230525/http://www.oracle.com/us/sun/index.htm su http://www.sun.com/software/opensource/java/faq.jsp

In caso di problemi vedere le FAQ.—InternetArchiveBot (Segnala un errore) 15:19, 15 nov 2022 (CET)