Newsgroup: it.comp.java
Titolo: servizi NT in java

Salve a tutti, sono nuovo di Java !
Vorrei sapere se qualcuno sà se è possibile realizzare servizi per Windows NT
in Java.
Immagino che sia piuttosto improbabile, se così fosse vorrei allora sapere se
è possibile richiamare da programmi scritti in C++ delle classi scritte in
Java.
Grazie ! Ciao
____________________________________________________________________
Get free e-mail and a permanent address at 
http://www.netaddress.com/?N=1
--
Posted from 
www0r.netaddress.usa.net
 [204.68.24.47]
via Mailgate.ORG Server - 
http://www.mailgate.org

On 17 Nov 1998 10:47:15 +0100, 
zor...@usa.net
 (Fabio Giannotta)
wrote:

Prova 
http://www.swtech.com/java/
Tra tutti gli argomenti, c'è una sezione chiamata "Java Services on
NT".

Java.
Su NT (o altri ambienti Win32), con la JVM Microsoft, anche questo
e` possibile, e in effetti decisamente agevole: qualsiasi classe Java
puo` "esportare" i suoi metodi pubblici, automaticamente o con varie
customizzazioni, attraverso il Component Object Model (COM) della
Microsoft, che notoriamente e` poi accessibile da praticamente tutti
i linguaggi (accesso particolarmente comodo in Visual Basic e Visual
C++ della Microsoft, ma fattibilissimo anche in Delphi, Perl, Python,
e via elencando); in particolare, qualsiasi Javabean si puo`, in modo
automatico, "presentare" come controllo Active/X (e viceversa,
Java, nella versione Microsoft, puo` usare qualsiasi Active/X come
se fosse un Javabean -- cosi` come puo` accedere ad altri oggetti
che esportano la loro funzionalita` via COM).
Su altre piattaforme (VM Java, ecc), non Microsoft, dovresti potere
ottenere quello che desideri con la tecnologia "JNI" ("Java Native
Integration" -- non sono sicuro che la I stia per Integration), molto
a basso livello, ma, appunto per questo, tale da permettere di fare
anche "cose strane", sia pure non senza scrivere TANTO codice
(e` tutta pensata per il C, non per il C++, quindi, e` una interfaccia
NON a oggetti, a funzionalita` che alla fine restano pur sempre ad
oggetti -- gia` questo "mismatch di impedenze" fa soffrire).  Anche
MS ha una interfaccia di basso livello del genere (RNI, "Raw Native
Implementation" credo), ma ci sono anche tutti gli "strati alti" suddetti
che nel 99% dei casi permettono di lavorare con piu` comodita`.
L'integrazione fra Java, e il resto del sistema (particolarmente,
altri linguaggi, attraverso COM, ActiveX, ecc, ma anche cose come
i servizi NT) e` decisamente il punto di forza della versione Java
della Microsoft; a contraltare, e` importante tenere presente anche
le *debolezze*, che non sono poche, e per alcuni casi d'uso possono
anche essere veramente cruciali:
1. portabilita` addio!  Una classe Java scritta per essere un
    service NT, ad esempio, NON funzionera` se non su NT,
    e con macchina virtuale Microsoft aggiornata (penso che
    non funzionerebbe neppure su Win95, visto che i service
    non li ha!); una classe Java che usa ("come se" fosse un
    Javabean) un certo componente ActiveX, girera` SOLO
    dove quel componente ActiveX e` disponibile a sua volta
    (in pratica, solo su Win32 -- e, ancora una volta, dovrai
    avere la macchina virtuale MS); eccetera.
    Tutto cio` e` decisamente contrario alla "filosofia" WORA
    ("write once, run anywhere"), per cui, attenzione... tante
    cose VANNO, certo, fatte in modo non-portabile (se devi
    interagire a tutti i costi con servizi di una specifica e
    particolare macchina o S.O.), ma e` cruciale, almeno,
    *sapere* che lo si sta facendo, come scelta deliberata,
    mentre con i sistemi Microsoft, se uno non sta MOLTO
    attento, si trova a usare schemi non-portabili anche per
    quelle cose che si *potrebbero* (magari a prezzo di un
    codice un po' piu` lento, un po' piu` grosso, un po' meno
    Windows-like come look-and-feel, ecc) fare "WORA"...
2. *Nessun generatore di codice nativo*!!!  Non farti
    imbrogliare da jexegen, il "generatore di EXE": sono EXE,
    si`, ma NON codice nativo, solo il solito bytecode Java
    "impacchettato" un po' diversamente, e non girano se non
    in presenza di un'istallazione aggiornata della JVM MS!!!
    L'implementazione JVM MS non e` malaccio come
    prestazioni (un po' debole sulla grafica "standard" Java,
    cioe` AWT, piu` veloce del JDK invece su carichi di
    tipo computazionale ecc -- alla fin fine, diciamo un
    pareggio) -- ma non e` la stessa cosa come un vero
    generatore di codice nativo (Supercede, Symantec,
    e IBM, offrono tutti dei generatori di codice nativo nei
    _loro_ sistemi di sviluppo Java -- ma essi compilano
    Java standard, *NON* le estensioni Microsoft!!!).
    E` una vergogna che MS non abbia ancora messo,
    neppure in beta, un generatore di codice nativo per
    Java, soprattutto se pensi che uno per _Basic_ lo
    hanno da  anni, quindi non poteva essere poi tanto
    difficile fare almeno una prima versione sperimentale.
    Bah.
3. *NON* allineato con le funzionalita` Java 1.2!!!
    Per quelle 1.1 sei a posto (l'RMI, se proprio devi
    averla, puoi scaricartela da un ottimo pacchetto che
    offre gratuitamente l'IBM sul suo sito alphaworks,
    proprio per rimediare a questa mancanza delle
    JVM Microsoft!) -- ma 1.2 aggiunge tante belle
    cosine, tipo Swing, collezioni, eccetera, che il
    Java Microsoft NON ha invece incluse (puoi certo
    prendere altre librerie equivalenti dalla rete, tipo
    la splendida libreria di "collezioni" JGL che e`
    assai piu` ricca di quelle native Java 1.2 , o provare
    a girare le Swing tratte da altre fonti, ma, chi ti
    *supporta*, poi, se fai "misture" del genere, se
    qualcosa non dovesse funzionare...?!).
Prego notare che tutto quanto sopra prescinde in modo
rigoroso da considerazioni di "simpatia" o "antipatia" pro
o contro Microsoft, Sun, o chiunque altro -- sono, le mie,
tutte considerazioni tecniche e pragmatiche.  Molti dei
patiti Java *odiano* Microsoft (e vedono Java proprio
come una "arma" contro MS!), quindi non sceglieranno
MAI uno strumento MS, anche se fosse il migliore o
l'unico per un dato compito; presumo che uno che si
propone di scrivere services per NT non sia di questi,
se no non avrei sprecato tempo in questa disamina...:-).
Alcuni, al contrario (soprattutto persone che, delle
realta` dell'informatica, non capiscono nulla) sono del
tutto terrorizzati dall'idea di usare qualsiasi fornitore non
Microsoft ("e se mi fallisce domattina"?-) -- presumo,
ancora, che una persona che sta prendendo in
considerazione la possibilita` di usare Java NON soffra
di questa sindrome patologica:-).
Per tutti noi altri "nel mezzo", decisi a fare la scelta
tecnica "migliore", idealmente "senza guardare in
faccia a nessuno", la situazione attuale di Java non
e` facile, poiche` le specifiche soluzioni MS offrono
si` tanti vantaggi, ma anche svantaggi non da poco,
che ho cercato di riassumere in questo post.  Forse
la cosa migliore e`:
1. tenere il piede in due staffe: garantire che tutto il
    proprio codice riusabile compili e giri sia con SDK,
    sia con JDK;
2. tenere il codice NON riusabile, ad esempio quanto
    occorra per implementare un servizio NT, in classi
    apposite da compilarsi solo in SDK (e similmente,
    quanto occorra per agganciarsi a, ad es., Swing,
    in classi apposite da compilarsi solo in JDK);
3. sperare che la situazione si chiarisca presto...!-)
Alex