Newsgroup: it.comp.os.dibattiti
Titolo: Java One

"Apple is a Gold sponsor at this year's Java One. Its message: Java
development is terrific on Mac OS X."
http://www.oreillynet.com/pub/a/mac/2001/06/05/javaone2001_report.html

development is terrific on Mac OS X."
IMHO, si sta' giocando una partita molto importante. Da una parte M$
con il suo .NET, dall'altra parte il resto del mondo con Java :)
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

 con il suo .NET, dall'altra parte il resto del mondo con Java :)
Vinca il migliore! ;-)
Hot News - JavaOne SF - Gallery
http://www.apple.com/hotnews/articles/2001/06/javaone/
-- 
Build Your Own Java-Based Supercomputer
Pseudo Remote Threads makes parallel clustering (almost) a breeze
http://www-106.ibm.com/developerworks/library/j-super.html?n-j-4121

 Vinca il migliore! ;-)
Mi sa che Sun ha gia' deciso che deve vincere Microsoft:
1)ha annunciato Jone *dopo* che M$ ha tirato fuori il polverone .NET,
risultato:
  -si parla del nulla (.NET) alzando un polverone
  -Jone non se lo fila nessuno e sun lo aveva, praticamente com'e'
adesso da 2 anni
2)tutto il mondo pensa che soap, wdsl, uddi e webservices stanno uscendo
adesso, invece esistono perfino implementazioni open source in perl
stabili da un pezzo :-)
3)Sun ha la presunzione di pensare di rappresentare DA SOLA 'il resto
del mondo' ... e' riuscita a inimicarsi in un sol colpo i fan di M$ e
tutta la comunita' open source
...... credo che se in SUN non aprono gli occhi (perfino IBM pare
riuscire a farlo) su questo match non scommettera' nessuno ..... nemmeno
io che notoriamente sono filo linux, sun, unix e mi sta antipatica la M$
:-)
Ciao
-- 
Antonio Baldassarra
anto...@seeweb.com

 tutta la comunita' open source
Quando uno si chiama SUN non può che fare come il diavolo:
fare le pentole ma non i coperchi :-)
Saluti.

 Mi sa che Sun ha gia' deciso che deve vincere Microsoft:
........................................................................
[
http://java.sun.com/javaone/javaone2001/whitepapers/javatoday.pdf
]
Java Technology Today:
Driving the new wave of open, intelligent Web services
The application programming interfaces of the Java platform -- as well
as the source code -- are available to anyone via download. This stands
in stark contrast to Microsoft's "Shared Source" program, which allows
only 1,500 of its customers and partners to view some of the source
code.
To date, there have been almost 5 million downloads of all the APIs and
source code of the Java platform by interested companies and developers.
This kind of openness allows developers to learn the Java platform from
the inside and become more productive more quickly. It also fosters
innovation because developers can actually see the source code that
determines how the software works.
The key here is interoperability -- it's hard to imagine Web services
without that. So the answers to the following questions will tell you
all you really need to know: Are .NET users free to choose any directory
other than Microsoft's Active Directory? Can they replace Microsoft's
Kerberos with any other Kerberos server? Can they replace Windows 2000
with any other operating system? The answer, in every case, is no. With
Java -- indeed, with all of Sun's Open Net Environment -- users are free
to choose the products that best suit their needs.
(c) 2001 Sun Microsystems, Inc. All rights reserved.
........................................................................
JavaOne[sf2001] - Info - Press
http://servlet.java.sun.com/javaone/info/press/0-sf2001.jsp

 ha scritto nel messaggio
news:1euquo2.12vvl10987np8N%bx...@tin.it...
 Can they replace Java language with any other?
 The answer, in every case, is no. With
 Java -- indeed, with all of Sun's Open Net Environment -- users are
free
 to choose the language that best suit their needs: Java.
Saluti.

 users are free to choose
........................................................................
[
http://www.cs.wisc.edu/~bart/fuzz/fuzz-nt.html
]
An Empirical Study of the Robustness of Windows NT Applications Using
Random Testing ( Justin E. Forrester, Barton P. Miller - Computer
Sciences Department, University of Wisconsin)
Our current study has produced several main results:
* 21% of the applications that we tested on NT 4.0 crashed when
presented with random, valid keyboard and mouse events. Test results for
applications run on NT 5.0 (Windows 2000) were similar.
* An additional 24% of the applications that we tested hung when
presented with random valid keyboard and mouse events. Tests results for
applications run on NT 5.0 (Windows 2000) were similar.
* Up to 100% of the applications that we tested failed (crashed or hung)
when presented with completely random input streams consisting of random
Win32 messages.
* We noted (as a result of our completely random input testing) that any
application running on Windows platforms is vulnerable to random input
streams generated by any other application running on the same system.
This appears to be a flaw in the Win32 message interface.
* Our analysis of the two applications for which we have source code
shows that there appears to be a common careless programming idiom:
receiving a Win32 message and unsafely using a pointer or handle
contained in the message.
........................................................................

 wrote in message
news:1eusw2s.x2ut7z16j2nwcN%bx...@tin.it...


E che c'entra?
Saluti.


http://www-106.ibm.com/developerworks/library/j-super.html?n-j-4121
Questo  dovrebbe  essere  interessante  ... basato  su  CORBA  ?  La
prossima  volta  che  faccio  gracchiare  il  modem,  vado  a  darci
un'occhiata ... Aspetta ... Voila'! Ho istruito wwwoffle :-)


 Java.
Il che,  IMHO, e'  vero. Java  si e'  dimostrato il  linguaggio piu'
adatto per portabilita', sicurezza e disponibilita' di librerie.
Java  e' talmente  dannatamente  buono che  la  Microsoft ha  dovuto
buttarlo a mare  per promuovere il suo C# e  per fermare l'emorragia
di sviluppatori VB.



togli ELIMINAMI per potermi rispondere in email

 Questo  dovrebbe  essere  interessante  ... basato  su  CORBA  ?
No, e' un sistema basato su Java (v. "Java threads" e "Java Remote
Method Invocation").
-- 
Apple - Mac OS X - Java
http://www.apple.com/macosx/java2.html

 di sviluppatori VB.
Vero.
Saluti.

 to choose the products that best suit their needs.
E questo che c'entra ? e' una delle tante papers (peraltro di corretto contenuto) miranti
a pubblicizzare la sun-filosofia (che io condivido) ... il punto e' un altro:
Quella news la leggiamo in quattro, il mondo degli sviluppatori che sara' attratto da .net
in buona pate ne ignorera' l'esistenza e sun non fa nulla per raggiungerli, e' questo il punto.
Per me questo e' un ENORME ERRORE STRATEGICO che le fara' perdere la partita con grave
danno per tutti noi e per il mondo informatico.
--
Antonio Baldassarra
anto...@seeweb.com

 Per me questo e' un ENORME ERRORE STRATEGICO
Send them your favorite FUD!
http://java.sun.com/features/fudwatch/fudwatch1.2.html

 wrote in message
news:1eux2e2.11jlsmlaroemqN%bx...@tin.it...

Il FUD sul FUD.
E visto che sono rimasti al 1997 non ci credono
più neanche loro.
Saluti.

Method Invocation").
Argh !  Ma JRMI non e'  un "wrapper" per  CORBA ? Lo dicevo  io, che
quel libro dovevo comperarlo :-) ...


il resto del mondo...e Sun.
Hai ragione, il Sole non fa' parte del Mondo :-)


Vero.
Sara' un bene o sara' un male ? Mah ...


managed moderni.
Quali i tanti linguaggi moderni mi permettono di cambiare architetture, 
macchine, sistemi e quindi di spostare rapidamente le applicazioni?
Ho sono flessibile sui linguaggi (e comunque posso usarne altri anche se 
uso java) o lo sono sulle architetture. E' un problema di costi/benefici.
-- 
Balrog ):E...

 macchine, sistemi e quindi di spostare rapidamente le applicazioni?
Oh, se e' solo per quello ve ne sono a bizzeffe. Anche C, C++ e ASM se
vuoi, usando il VP di Tao/Amiga :)
Fabio Alemagna

 macchine, sistemi e quindi di spostare rapidamente le applicazioni?
Tutti quelli che implementano o si basano sul principio della macchina
virtuale, ovvero
quasi tutti quelli interpretati o giu di li.
Saluti.


python :)
Scherzi a parte (anche perchè non voglio innescare una flamewar sui 
linguaggi che sono, notoriamente, il secondo argomento che meglio si presta 
alle discussioni interminabili, dopo i sistemi operativi....), credo che 
java sia un ottimo linguaggio ad oggetti, ma rappresenta veramente la 
soluzione ottimale solo quando ti servono tutti (o buona parte) dei 
requisiti che hai descritto.
Anche perchè non ha solo vantaggi...
- E' pesante (come il concorrente .net, del resto)
- Non permette di accedere direttamente al 100% delle funzionalità del s.o.
- Non è così indolore il passaggio tra le diverse piattaforme (soprattutto 
se si parla di browser e applet)
- Alcune delle librerie sono letteralmente infestate di bug (swing, anche 
se sono rimasto alla ver. 1.2, magari puoi smentirmi).
- Il supporto per alcune piattaforme (linux e macOS in primis) non è così 
completo e performante (mi riferisco sempre alla 1.2) e, purtroppo, uno dei 
possibili campi di applicazione, quello delle interfacce utente "evolute" 
per siti web è molto condizionato dal fatto che il mercato dei client è in 
mano al peggiore concorrente (nemico?) di sun...
Personalmente non credo all'idea che un linguaggio (così come un sistema 
operativo) possa rappresentare la soluzione migliore per tutti i problemi.
Spesso è utile saper scegliere gli strumenti migliori in base al problema 
da risolvere e non cercare di usare sempre il martello, anche con le 
viti... :)
In molti casi l'accoppiata tra un linguaggio potente come C/C++ 
(personalmente preferisco il secondo...) e un motore di script come python 
(con cui puoi realizzare rapidamente "prototipi" o programmi "accessori") 
può rappresentare una soluzione migliore rispetto a un sistema realizzato 
solo con java, ovviamente IMHO.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)


Vogliamo cercare di dimostare la possibilita' di costrutti ricorsivi su
usenet :-)))
--
Antonio Baldassarra
anto...@seeweb.com

 piů neanche loro.
FUDwatch 1.7: February, 2001
FUDwatch(SM) Index
http://java.sun.com/features/fudwatch/index.html

quasi tutti quelli interpretati o giu di li.
Bah, non mi sembra tanto vero. La macchina virtuale di Java e' abbastanza 
diversa dalle "macchine virtuali" della maggior parte dei linguaggi 
interpretati.
Comunque, e del framework che mi sai dire? Questi linguaggi sono 
dotati di un framework sufficientemente ampio e supportato su piu' piattaforme? 
Non corri il rischio di trovare che qualche componente importante non sia 
supportato su una particolare piattaforma? Sei sicuro che i servizi che la 
macchina virtuale offre siano sufficienti a sviluppare componenti software 
realmente multipiattaforma? Oppure devi sperare che il componente sia stato 
adattato e ricompilato per quella particolare piattaforma?
-- 
Balrog ):E...

sistema realizzato solo con java, ovviamente IMHO.
Leggi la mia risposta a GDG.
-- 
Balrog ):E...


Uno dei punti di forza di java è la portabilità...
Serve sempre? 
Anche il codice compilato C o C++ può essere portabile a livello di 
sorgente. E' un grosso problema dover ricompilare? 
Non sempre, credo, soprattutto se questo mi evita uno strato intermedio (la 
virtual machine) che, per quanto possa essere fatto bene, occupa memoria e 
CPU.
Il framework di java è sicuramente molto ampio, ma non copre il 100% delle 
funzionalità di tutti i s.o. su cui gira. 
L'interfaccia utente di un'applicazione java, ad esempio, sarà sempre 
limitata rispetto a quella di un'applicazione nativa windows, macOS, GTK 
etc.. E le soluzioni proposte (swing) sono poco performanti e comunque non 
ben integrate (io sono rimasto alla 1.2, correggimi se sbaglio).
Per un'applicazione server che vantaggi mi offre la jvm rispetto a una 
ricompilazione di codice C che utilizza librerie standard? 
Non devo ricompilare quando installo un nuovo server con un os diverso? Non 
ne vale la pena...
Credo che java sia la soluzione migliore dove tutti i vantaggi che offre 
giustificano l'overhead della vm e dove la portabilità è un requisito 
indispensabile. Nel "bagaglio" di un buon analista/programmatore ci 
dovrebbe essere spazio per più di un linguaggio "completo" 
(C,C++,Java,Delphi...) e per qualche linguaggio meno generico che può però 
essere utile per risolvere determinate categorie di problemi 
(perl,SQL,javascript) o per realizzare "prototipi" (VB,python) o script 
(VBScript, python, gli script delle varie shell, tcl...) altrimenti rischi 
di trovarti a usare il martello per piantare le viti! :)


 dotati di un framework sufficientemente ampio e supportato su piu'
piattaforme?
Se lo si fa per Java lo si puo fare a maggior ragione per qualsiasi altro
linguaggio.
Saluti.

 linguaggio.
Ecco la teoria
-- 
Balrog ):E...
fabricius<at>ianus<dot>net

 dovrebbe essere spazio per più di un linguaggio "completo"
Infatti. Ma il punto non e'... se conosci java... ma se sei disposto ad 
usare anche java. Prima si parlava di obbligare i programmatori ad usare 
java invece che il loro visualbasicuccio preferito. E la cosa mi ha 
alquanto indisposto.


 Che esperienze hai in tal senso?
Al di fuori di linux o *BSD non vedo come si possano ricompilare le
applicazioni quando si parla di tutti gli altri sistemi, dal momento che
di solito non si hamnno i sorgenti...
E ricompilare sottrae tempo.
Fabio Alemagna

 contano molto nella crescita di una infrastruttura aziendale.
Ehm... non avevo letto "...che utilizza librerie standard".
Se per te e' sufficiente la libreria standard... usala.


 E ricompilare sottrae tempo.
E non ti da la garanzia di funzionamento. Moltiplica questo problema per 
tutte le applicazioni aziendali sviluppate in questo mondo ed ecco la 
dimensione (economica) del problema.


 efficienza del codice nativo con flessibilita' del byte code.
Ho solo ribadito che le due cose non sono mutualmente esclusive. Su
Elate/AmigaDE ottieni tutte e due, ad esempio. Elate puo' girare anche in
32k. Ridotto al minimo, ovvio, ma prova a fare lo stesso con java.
Oltretutto per Elate/AmigaDe esiste una delle virtual machine java piu'
veloci al mondo -- nonostante a sua volta giri su un'altra virtual machine
-- ed e' certificata da Sun.
Fabio Alemagna

 La tecnologia di TAO/Amiga si basa sul concetto del VP...
Purtroppo in questo mondo il successo di una soluzione non e' garantito dal 
valore intrinseco della stessa.
Auguro buona fortuna ad Amiga.


 valore intrinseco della stessa.
Ma sbaglio o si parlava di caratteristiche tecniche? Com'è che ti sei
spostato sul lato "successo"?
Fabio Alemagna


togli ELIMINAMI per potermi rispondere in email

 è così completo e performante (mi riferisco sempre alla 1.2)
FYI:
Developer - Java
http://developer.apple.com/java/
Mac OS X Developer Documentation
http://developer.apple.com/techpubs/macosx/macosx.html
........................................................................
[
http://developer.apple.com/macosx/pdf/macosx_java.pdf
]
::: Mac OS X Platform :::
Many of the advantages of writing and running Java applications on Mac
OS X come from the underlying core operating system called Darwin. At
its base is the Mach 3.0 microkernel. This provides protected address
spaces, preemptive multitasking, real-time support, and advanced virtual
memory. Darwin also features an implementation of the BSD operating
system. For more details consult the book Inside Mac OS X: Kernel
Environment. For an overview, take a look at the book Inside Mac OS X:
System Overview.
With BSD underneath, you are able to use a standard command-line
environment for development and administration. Using the Terminal
application you will be able to use commands from tcsh , the enhanced C
shell. For more information on these shell commands you may want to
consult a book such as Using csh & tcsh published by O'Reilly.
The three development frameworks for Mac OS X applications are Carbon,
Cocoa, and Java. Apple has provided support for writing Cocoa
applications in Java by providing Java APIs for the Foundation and
Application Kit frameworks. You can access the documentation for these
frameworks using the JavaBrowser application in the
/Developer/Applications directory or by using your Web browser to
navigate to files that you can find online or in subfolders in the
/Developer/Documentation/Cocoa/Reference directory.
::: Java Implementation on Mac OS X :::
Mac OS X ships with the Java 2 Platform, Standard Edition (J2SE) 1.3.
You'll notice immediately that the user experience is greatly improved.
First, a large number of APIs are now available for the first time on a
Macintosh. Second there is a huge improvement in the performance of Java
applications now that the JVM is the Java HotSpot Client VM.
Full support of Java 2 means that there is first-class support for
Swing,the Collections framework, the Accessibility API, and your other
favorite APIs. It means that support for applets that require Java 2 is
provided on Mac OS X. In addition you'll find implementations of the
Java2D graphics architecture, Java-Sound, and the policy-based security
model. As part of the complete support of J2SE, Mac OS X also includes
packages such as RMI-IIOP, JNDI, and JDBC that were fomerly a part of
J2EE.
Apple has extended and enhanced the Java experience in many areas.
* Java threads are now native Mach threads. This means that they can
take advantage of symmetric multiprocessing without extra work from you.
The Java threads are also are fully preemptive.
* On Mac OS X, the overhead of multiple instances of the VM has been
reduced through the sharing of Java class data and of HotSpot-compiled
code across invocations. This feature is unique in the Mac OS X Java
implementation.
* Mac OS X provides double buffering for all Java applications.
* In addition to using the standard Java calls for graphics rendering,
you also have the option of rendering using OpenGL.
* Apple has Java-enabled Mac technologies such as QuickTime and
WebObjects.
* Java Embedding can be used to embed a Java applet into a window of a
native application. Note that the other tasks traditionally handled by
the JManager are now handled by the JNI Invocation API and the
CoreFoundation API.
* You'll find improved native method access in Mac OS X using JDirect3.
You should consult the developer release notes for details on how to use
JDirect3 and how to debug JDirect on Mac OS X.
(C) Apple Computer, Inc. January 23, 2001
........................................................................

virtuale, ovvero quasi tutti quelli interpretati o giu di li.
No. Con Perl e Tcl, per esempio, hai un mucchio di comandi che sotto
Win32 o sotto Mac non funzionano.  Perl e Tcl sono poco portabili se
comparati a Java. E pure meno potenti. E pure meno sicuri (SandBox).
E non sono in formato bytecode.


sistema realizzato solo con java, ovviamente IMHO.
Non  so  ...  Ho lavorato  con  un  server  WEB  scritto in  Java  e
con  delle  applicazioni  Java  (Servlets) e  sono  rimasto  colpito
dalla  portabilita' (WinNT,  Solaris, Linux),  dagli strumenti  gia'
disponibili e facilmente integrabili (WEBMacro, InstandDB, Velocity,
.) e, sopratutto, dalla comunita' che ci gira attorno.
In questo campo non so' come si comportano C++ e python ...



Francamente quello dei web server non è il mio campo (e, per quanto ne sò 
nemmeno quello del C++ :)). 
Per python mi pare di aver visto delle Python server pages o qualcosa di 
simile...
Comunque il senso del mio post era che a volte è meglio che sia il 
programmatore ad essere "multipiattaforma" (nel senso di saper sfruttare 
diversi sistemi) e non solo la piattaforma di sviluppo :)
Quasi tutti i progetti che ho sviluppato o stò sviluppando sono composti da 
parti sviluppate con linguaggi diversi, ma forse sono io che mi vado a 
cercare i guai :)
Credo che java non sia solo un linguaggio (e infatti sun lo definisce 
"platform") e, anzi, il fatto di aver praticamente vincolato la JWM a 
quello specifico linguaggio (anche se esistono compilatori che generano 
bytecode per molti altri linguaggi, non supportati da sun) è stato un 
errore che altre VM (.net e TAO/Elate, per quanto leggo su questo ng) non 
hanno ripetuto. 
Purtroppo molti programmatori sono pigri e legati ad un solo linguaggio 
(questo è vero soprattutto per linguaggi come VB e dephi) o addirittura ad 
uno specifico sotto-linguaggio (C++ builder) e questo ha rappresentato un 
limite alla diffusione della "platform" java.


 spostato sul lato "successo"?
Adesso parliamo di sistemi operativi.
Mi spiace dirlo, ma io apprezzo tanto BeOS. Ma sulla Be non ci punterei una 
lira. E questo mi dispiace tanto. A questo punto, quale sistema operativo 
puo' rappresentare un "investimento" sicuro? Escludendo la roba MS a 
priori, mi rimangono due alternative... ed entrambe mi interessano. Quindi, 
io lavoro su quello su cui ha senso lavorare, almeno finche' qualcuno o 
qualcosa non mi dimostra che le altre alternative sono percorribili.
Torniamo a parlare di linguaggi e VP.
a chi l'ha vista sto VP di Amiga? L'hai visto tu? E poi? E queste 
superlative prestazioni, come sono state valutate? Quanto sono valutate? 
Hai riferimenti concreti? Perche' sti baubau di Amiga non rilasciano una 
cavolo di demo?!
E comunque, all'inizio stavo confutando le affermazioni di qualcun'altro su 
java.


 E non sono in formato bytecode.
Perl e' compilato in bytecode 'just in time' partendo dal sorgente. A
parte che si risparmia il tempo richiesto dalla compilazione, quali
sono i vantaggi del bytecode? Chiedo lumi in quanto inesperto.
-- 
Stefano - Hodie decimo septimo Kalendas Iulias MMI est

 qualcun'altro su java.
Be', io sono intervenuto qualcuno ha detto (non ricordo se eri tu), che
java e' l'unico linguaggio completamente portabile ma che questo si paga
in termini di efficienza. Ho solo fatto notare che ci sono altre
tecnologie che sono sia portabili che estremamente efficienti.
Fabio Alemagna

ma le JVM sono anche molto leeeeeente.
Vero, ed e'  l'unico punto a sfavore.  Anche se c'e' da  dire che la
lentezza  e' relativa  nel  tempo: Vista  l'evoluzione  dei Mhz,  la
lentezza si fara' sentire sempre di meno.
A meno che, ovviamente, le  JVM non seguino l'evoluzione dei sistemi
operativi  della  Microsoft, sempre  un  pelino  piu' pesanti  della
macchina entry-level disponibile al momento :-)
-- 
 __                                                               (o_
| _        "The Internet is slow, could you please reboot it ?"   //\
|__|iambo  mailto:
gabr...@giambonini.com
 
www.giambonini.com
   V_/_

 tecnologie che sono sia portabili che estremamente efficienti.
Dal mio punto di vista, questo e' ancora tutto da verificare.
Gia' che ci sono... a proposito di 
amigasdk.com
, dov'e' il link 
"documentation"?


 macchina entry-level disponibile al momento :-)
Dove ho letto che "il software diventa piu' lento piu' velocemente di
quanto l'hardware diventi piu' veloce"... boh!


 "documentation"?
Non c'è, visto che non è un sito ufficiale.
Fabio Alemagna

 - E' pesante (come il concorrente .net, del resto)
Io sulla "pesantezza" di .NET non ci scommetterei cosi' tanto.
Ciao.

sono i vantaggi del bytecode? Chiedo lumi in quanto inesperto.
Non sei obbligato a dare in giro i sorgenti >:->
-- 
 __                                                               (o_
| _        "The Internet is slow, could you please reboot it ?"   //\
|__|iambo  mailto:
gabr...@giambonini.com
 
www.giambonini.com
   V_/_

Dipende dal tipo di applicazioni che devi realizzare.
Portabili al 100%,  credo che sia uno dei  requisiti piu' importatni
per chi sviluppa in Java.
Per il resto del post: Sono d'accordo al quasi-100% :-)
-- 
 __                                                               (o_
| _        "The Internet is slow, could you please reboot it ?"   //\
|__|iambo  mailto:
gabr...@giambonini.com
 
www.giambonini.com
   V_/_

 Non sei obbligato a dare in giro i sorgenti >:->
Non ci vedo grandi vantaggi. Questo dice man perlfaq3 /hide:
       You can try using encryption via source filters (Filter::*
       from CPAN), but any decent programmer will be able to
       decrypt it.  You can try using the byte code compiler and
       interpreter described below, but the curious might still
       be able to de-compile it.  You can try using the native-
       code compiler described below, but crackers might be able
       to disassemble it.  These pose varying degrees of diffi-
       culty to people wanting to get at your code, but none can
       definitively conceal it (this is true of every language,
       not just Perl).
       If you're concerned about people profiting from your code,
       then the bottom line is that nothing but a restrictive
       license will give you legal security.  License your soft-
       ware and pepper it with threatening statements like ``This
       is unpublished proprietary software of XYZ Corp.  Your
       access to it does not give you permission to use it blah
       blah blah.''  We are not lawyers, of course, so you should
       see a lawyer if you want to be sure your license's wording
       will stand up in court.
(Nota che si parla di 'byte-code compiler', anche se non credo sia
perfettamente funzionanate)
Ma insomma, siamo diventati un po' OT...
-- 
Stefano - Hodie decimo sexto Kalendas Iulias MMI est

 ortogonale chiedi pure.
Ok: cosa e' la persistenza ortogonale? ;-))
Saluti
Marco

 file manager.
The problem with this description is that actually there are no files
for a manager to manage. And you're still missing the fundamental
point about namespaces.
A file is by definition an object in a separate namespace. You explicitly
read from or write to it.
Back to the office metaphor, a program's namespace might be the desktop.
You refer to an object on the desktop using its coordinates on the
desktop plane. You CANNOT refer to a file in the drawer using the same
kind of coordinates, simply because files are not on that plane. You thus
need to manually, explicitly move the file to your desktop before you can
manipulate its contents using desktop coordinates (i.e. map or copy the
external object to your namespace, operations that of course come at a
cost). That usually happens by requesting the help of a filesystem, file
manager, database manager or whatever else you want to call the external
entity that manages persistent data.
With orthogonal persistence, there are no files in the office. There's
just one huge desk, where everything can be referred to using the same
kind of coordinates. No mapping or copying required. You just work on
objects and never worry about any "outside" (well, except when you
try to access other machines; even in a networked environment, though,
it is not that crazy to envision one global namespace spanning across
multiple machines).
-----
La cosa fondamentale che si evince, quindi, e' che i "files" non esistono
piu'. Obelix puo' confermare che su OS/400 non esistono files e che in
realta' tutte le informazioni sono memorizzate in un database
("single-level storage", cosi' e' chiamata la cosa li').
Nel "Amiverse" non esistono files, ma solo oggetti messi in relazione tra
di loro. Ti faccio un esempio:
Sei a casa tua. In un momento di creatività ti viene voglia di
disegnare.
Prendi un foglio di carta              ! istanzi un oggetto
Prendi la matita e cominci a disegnare ! modifichi l'oggetto.
Salvi? Dove salvi? Significa qualcosa salvare, in questo contesto? No.
Sei stanco... il disegno non è       |  L'oggetto rimane lì, il sistema
finito. Lo lasci sulla scrivania, lo |  ne gestira' le sorti, spegni il
metti nel cassetto... fai tu. Esci.  |  computer.
Qualche tempo dopo ti riviene voglia | Accendi il computer e ricominci
disegnare. Ti rimetti alla scrivania | ad usare 'oggetto. Come troverai
e riprendi il foglio                 | l'oggetto dipendera' dall'interfac-
                                     | cia che la UI ti fornira', UI che
                                     | sara' indipendente dal resto del
                                     | sistema. Quello che molto
                                     | probabilmente succedera', se
                                     | l'oggetto e' recente, dove recente
                                     | e' un concetto che il sistema
                                     | *apprendera' basandosi sui compor-
                                     | tamenti dell'utente (e' implemen-
                                     | tata anche una rene neurale in
                                     | AmigaDE), sara' trovartelo sul
                                     | desktop, o rappresentazione equi-
                                     | valente.
Il problema che che' e' passato tanto tempo dall'ultima volta che hai
usato quel foglio... ora non lo trovi piu.
"mammaaaaa, dove hai messo il mio    | *Chiedi* al sistema "My drawing"
disegno?"                            |
In realta' la UI (si badi, non GUI o CLI, proprio UI) sara' completamente
indipendente da tutto il resto. Si potrebbe benissimo continuare ad avere
una rappresentazionealla quale siamo abituati, ma si potrebbe anche
gestire il tutto tramite istruzioni simil-sql, ad esmpio... stara'
all'utente ed al programmatore dell'UI, la scelta.
Maggiori informazioni sulla persistenza ortogonale le trovi qui:
http://tunes.org/papers/Glossary/#orthogonal
 persistence
(nota lo spazio tra "orthogonal" e "persistence")
Fabio Alemagna


-100%? :)



Le versioni beta sono pesantissime (più di java), ma questo può essere 
giustificato dal fatto che sono versioni di debug.
Forse il CLR di microsoft che è un po' meno generico e portabile, pare, di 
quello sun, e sicuramente più orientato agli x86 è un po' più leggero della 
JVM, e il fatto di poter "compilare" il bytecode in fase di installazione e 
non necessariamente a runtime (questa mi pare una scelta furba) potrebbe 
effettivamente garantire prestazioni superiori.


Ma insomma, siamo diventati un po' OT...
Infatti, come avrai notato, ho stroncato gran parte del post :)
Mi sa' che  stavamo scivolando nel solito "Il mio  e' piu' lungo del
tuo", confronto che  tra due linguaggi cosi' differenti  come Java e
Perl non aveva molto senso, no ?
A vantaggio di Perl, posso dire che costruire un parser per files di
configurazione e' stato una sciocchezza :)


 effettivamente garantire prestazioni superiori.
La stessa cosa la si puo' fare con Elate/AmigaDE...
Fabio Alemagna

                                      | AmigaDE), sara' trovartelo sul
Se l'avessero anche gli utenti... :o)
-- 
disclaimer: not speaking for anybody but me.

 garantire prestazioni superiori.
Un avvio piu' rapido, non prestazioni superiori.
Ciao.

:

Credo anche prestazioni superiori visto che, perlomeno fino alla 1.2, java 
traduceva il bytecode in codice nativo durante l'esecuzione e non prima di 
eseguirlo.
