Newsgroup: it.comp.java
Titolo: namespaces e files

Una classe ( es. Cliente.java) può trovarsi ad esempio nel namespace 
com.mycompany.domain
 
Anche i file di configurazione xml ,esempio mapper.xml,  possono  trovarsi 
in un namespace?
 
Anche se non sono oggetti java?
 
Grazie 
 


Se per "namespace" intendi "package", allora la risposta è si', nel 
senso che il package com.mycompany.domain corrisponde alla directory 
com/mycompany/domain che ovviamente, oltre a file .class, può contenere 
file di qualsiasi altro tipo: immagini, properties, xml, sorgenti etc.
 
Poi, dipendentemente dall'uso che ne vuoi fare occorre prestare 
attenzioni particolari. Ad esempio, se la directory com fa parte del 
classpath, puoi avere file distinti:
com/mapper.xml,
com/mycompany/mapper.xml
com/mycompany/domain/mapper.xml
Dal puto di vista del classloader non c'e' alcun ordine preferenziale, 
nel senso che Classloader.getResource("mapper.xml") ritornerà un URL 
determinato solo dall'ordine gerarchico del classloader e dei suoi 
parent, mentre Classloader.getResources("mapper.xml") probabilmente 
enumererà tutti i file con lo stesso nome.
 

 in un namespace?
 
Dipende. Io ad esempio li carico tramite una specifica opzione (che 
implemento, ovviamente) data via linea di comando
 
Enrico


vabbeh che c'entra? possono stare in un package anche se caricate tramite 
una opzione.
in realtà la domanda è se possono starci, quindi la risposta è sì senza 
dipende.
 
 

 
 
"Dr.UgoGagliardelli"  ha scritto nel messaggio 
news:m56s0b$mdd$1...@speranza.aioe.org...
 
<Se per "namespace" intendi "package", allora la risposta è si', nel
<senso che il package com.mycompany.domain corrisponde alla directory
<com/mycompany/domain che ovviamente, oltre a file .class, può contenere
<file di qualsiasi altro tipo: immagini, properties, xml, sorgenti etc.
 
l'ho visto in alcuni progetti,all'interno di NetBean o Spring,nel tree view 
a sinistra ,in cui tali file xml erano sotto il namespace,come fossero 
classi java.
 
ciao 
 


Certo, e' prassi comune. In ogni caso, per evitare ambiguita', userei il 
termine package che ha una valenza specifica in Java ed ha la la propria 
classe che lo descrive: java.lang.Package.

classi java.
 
 
ma di namespace si parla in C++ , in C#
in java si parla di packages
penso tu abbia aperto un progetto
in cui si importava del codice C++ in java
java offre questa possibilità già penso da Java 1.4
sicuramente netbeans almeno dalle versioni
piu' recenti, offre la possibilità di avere
dei templates C++
 
saggia decisione, visto che java non puo' battere C++ in velocità
perchè deve passare per la jvm
 
invece netbeans non ha,
 almeno nella versione che ho
supporto per C# (non avrebbe senso...)
e poi tra Csharpisti e Javisti
normalmente non corre buon sangue
 
cmq, quello che devi aver fatto tu...
è di aver aperto un progetto java con utilizzo
del framework spring e 
di C++
cosa che personalmente fino ad ora non
ho mai fatto.
 
ciao, Jasmine

 perchè deve passare per la jvm
 
Dissento:
 
http://benchmarksgame.alioth.debian.org/u64q/java.php
 
 
Come si vede, ci sono casi in cui Java e` equivalente a C++ in termini di 
velocita`. Detto questo, ha senso usare JNI (o JNA) in un progetto Java? Si, 
ma piu` per l'ottimizzazione di memoria (nei casi in cui il programmatore 
Java sia limitato dalla JVM) o per accesso diretto al sistema operativo 
sottostante
 
Enrico

velocita`. 
 
uhm... sono solo casi
fosse altro perchè i piu' importanti sistemi operativi
sono a tutt'oggi scritti in C/C++  
 
Java e C++ detengono la maggior parte
del mercato odierno
Java riesce a tenere quasi testa a C++
perchè è portatile ma nel momento in cui sei costretto
ad usare jni, chiamate di sistema
in un modo o nell'altro ristabilisci il primato di C++
 
 
il piu' importante linguaggio di programmazione rimane ancora
C++
ed è cosi' da piu' di una trentina d'anni
 
fa molto in parlare di programmazione embedded
chissà magari il mondo del futuro
vedrà interfacciarsi dispositivi embedded
a ciclo chiuso in modo da formare un ciclo aperto
e la console sarà passata a java :)
 
oppure,  la portatilità
sarà realizzata non piu' tramite virtualizzazione
ma tramite hardware reso in qualche modo molto piu' flessibile
 
 
ciao, Jasmine
 
 

 modo da formare un ciclo aperto e la console sarà passata a java :)
 
tradotto in italiano?
 

 perchè deve passare per la jvm
 
Se il sistema e` basato su HotSpot, questo non e` neanche cosi` vero. 
 

 ma tramite hardware reso in qualche modo molto piu' flessibile
 
Si`, certo, o anche sbilicuda navi da combattimento in fiamme al largo dei bastioni di Orione, tarapia tapica, con raggi B che balenano nel buio vicino alle porte di Tannhäuser, come se fosse antani, con scappellamento a destra.

 anche se e` vero che Java garantisce piu` portabilita` di altri linguaggi.
Ovvio che se negli "altri linguaggi" includiamo linguaggi piu' o meno 
interpretati, ci sono altri linguaggi che garantiscono portabilità 
analoghe (php, python, perl, ruby etc.).
Ma se parliamo di C++, la sua portabilità e' garantita sulla medesima 
piattaforma e os solo in pochi casi specifici, me ne viene in mente solo 
uno, ma con escludo che ce ne possano essere anche altri.
 

 piattaforma e os solo in pochi casi specifici,
 
Huh?! "Portabilita` sulla medesima piattaforma" e` una frase che non ha senso. Le implementazioni C++ sono di norma backward-compatible anch'esse. 


Dipendentemente dalla "norma". Se, ad esempio parliamo di windows non lo 
darei per certo.
 
 

 darei per certo.
 
Se l'implementazione di un linguaggio e` backward-compatible o meno non dipende dal sistema operativo. Dipende da quanto lo standard del linguaggio stravolge i concetti del precedente standard, e da quanto conforme l'implementazione e` a quanto dettato dal comitato ISO. Vero e` che con C++ e` difficile trovare un'implementazione 100% standard, ma sulle definizioni dei comportamenti fondamentali del linguaggio si puo` stare tranquilli.
 

 ma sulle definizioni dei comportamenti fondamentali del linguaggio si puo` stare tranquilli.
Infatti. Il grande vantaggio del java rispetto al C++ e' proprio che 
ogni dipendenza dal sistema operativo e' demandata alla jvm. Se proprio 
non se ne puo' fare a meno, ad esempio per accedere direttamente a 
device non direttamente supportati dalla jvm, java ti obbliga ad 
implementazioni jni (o jna), isolando di fatto gli interfacciamenti al 
sistema come dici tu. A me non sembra poco.
 

 ogni dipendenza dal sistema operativo e' demandata alla jvm. 
 
Ma ottieni lo stesso con il C++, utilizzando librerie specifiche del sistema. Io ho sviluppato software sotto Windows, con mingw, che girava perfettamente sotto Linux, senza alcun cambiamento.

 e la console sarà passata a java :)
 
J2ME e Android (con Dalvik e ART) sono tra di noi da un bel pezzo
 
Enrico

  non ha (e forse non ha mai avuto) poi una grande applicazione pratica.
 
Parla per te, il mio software di backup (scritto in java) si basa sul Write 
Once Run Everywhere :)
 
Enrico

Bella discussione sui namespace ...