Newsgroup: it.comp.java
Titolo: Info su jbuilder della borland

ho scaricato il personal 5 ma sia sul pc di casa (Athlon 1000) che in
ufficio (intel 550) mi risulta abbastanza lento.
cioč quando avvio il progetto, quando carico l'ide o  soprattutto quando uso
il designer mi si pianta per 2-3 secondi sul 1000 e 6-7 sul pentium 550.
Volevo chiedervi se č normale un simile fatto
Grazie
max
P.S. uso Win 98 SE

 P.S. uso Win 98 SE
malissimo :-)))

 Volevo chiedervi se è normale un simile fatto


Considera che la quantità di RAM è un punto essenziale per qualsiasi
applicazione Java, dove la memoria è gestita in automatico dal garbage
collector.
Per un' applicazione complessa come JBuilder è opportuno avere almeno 256 Mb
di RAM. Ti consiglio 512. E ti consiglio di provare la trial della
enterprise, altrimenti di jbuilder vedi molto poco (e sarebbe sensato allora
preferire un editor leggero).
Per la personal edition 128MB dovrebbero essere sufficienti; ad ogni modo
sul sito di borland le richieste hardware sono ben specificate.
Ad ogni modo sulla lentezza... il fatto che ognittanto JBuilder si
'appisoli' (per ripulire la memoria) devi rapportarlo al tempo che ti fa
risparmiare con ciò che ti offre. Tanto più spesso si 'appisola' quanto più
spesso deve eseguire il garbage collector (quindi più memoria hai e meno ciò
diventa un problema).
Purtroppo (o per fortuna) JBuilder è scritto in Java; se java lo valutassimo
soltanto per la velocità, probabilmente non programmeremmo in java, o
addirittura non utilizzeremmo OOP.
Sulla completezza di JBuilder, o la sua pseudo completezza... ovvio che se
la personal edition ha molto poco per lo sviluppo 'serio', se parliamo
invece della 'Enterprise edition', mi piacerebbe sapere cosa gli manca.
Ciao
Luigi

Se non mi sbaglio JBuilder è stato implementato in java a partire dall 
release 3... (in questo modo borland ha potuto commercializzare il suo 
prodotto anche in amibienti Linux).
Di IDE programmati in java che funzionino sotto linux se ne trovano 
parecchi, e anche di molto carini. Purtroppo però questi soffrono della 
lentezza dello stesso java.
A questo punto mi chiedo come mai, mentre dalla parte Windows esistono 
numerosi prodotti creati in codice nativo, per Linux non esistano...
Come mai?


 Come mai?
La mia risposta potrebbe essere che Linux è più adatto a far da server...
che non come workstation di sviluppo :)))) Ok ok... abbandono i miei
pregiudizi :)
Ad ogni modo basta farsi un giro su 
sourceforge.net
 o 
freashmeat.net
 per
trovare un sacco di editor java nativi funzionanti sotto linux. Inoltre i
maggiori IDE per java, VisualAge, JBuilder, Forte, Codewarrior, e altri
funzionano perfettamente sotto linux. Quindi secondo me è un'affermazione
non del tutto corretta. Persino il vim riconosce le keyword java e fa
l'highlight del codice. Ma tutto dipende da cosa si intende per IDE. Secondo
me un IDE java che supporti bene il linguaggio non può che essere scritto in
Java (reflection e cose simili, utilizzate per implementare object browsers
e autocompletition altrimenti si complicherebbero). Le soluzioni promiscue
(java/native) hanno mostrato essere peggiori delle soluzioni "pure" in fatto
di performance. Quindi, in linux come in windows, o si opta per un "editor"
nativo, o per un "IDE" puro java.
Questa mi sembra siano le opzioni offerte dalla realtà attuale.
Ciao
Jigi.

 
Mah... non so.... Vorrei vedere un IDE completo sotto Linux per essere 
pienamente d'accordo con te. Vedi, e qui mi ripeto, sotto windows 
esistono diverse soluzioni native... sotto linux invece esistono solo 
soluzioni in JAVA.

 soluzioni in JAVA.
Quali per esempio?
Gli altri "IDE completi", che io sappia, ci sono tutti. Se conosci altri
"IDE" di cui manca il porting per linux fammelo sapere perché io non ne
conosco.
Ciao
Luigi

 Come mai?
L'uso di Java in questi tools per lo sviluppo java è dovuto sia alla
portabilità che al fatto che è molto conveniente (pensa alla compilazione
dei sorgenti viene "gratuita" e integrata).
Detto questo, i prodotti nativi sono tecnologicamente molto diversi fra
windows e l'ambiente grafico linux, quindi è molto difficile supportare
contemporaneamente le due piattaforme. Diventa una scelta commerciale
(forzata).

Ok grazie! ho capito.......
jbuilder è fatto in java ed è avido di memoria (ne ho 256 mb)
per riallacciarmi ai tread che ne sono scaturiti...
sto cominciando a studiare il java appunto per realizzare applicazioni sulle
piattaforme Linux e Win..
Questa mia scelta non deriva tanto da un'esigenza ma è una specie di squardo
al futuro......tutti dicono Linux sta prendendo piede---> meglio mettersi al
sicuro.
fino ad ora ho sempre programmato in VBasic, (mi trovo benissimo ma le
applicazioni non girano sotto Linux) realizzo applicazioni per la gestione e
l'elaborazione di dati in un'azienda che fornisce servizi a rete.
Ora, visto che il mio interesse principale è per le applicazioni (le applet
mi interesssano solo marginalmente), se mi fate spaventare così io ci
rinuncio.
Se un'applicazione relativamente lite si pianta a sta maniera con un TB 1000
cosa farà la mia applicazione quando dovrà prelevare 10000 record dal db
dell'azienda e fare una bella query sostanziosa??
Cosa succederà se al mio db sono collegati 10 client, come spesso avviene
nella intranet dell' azienda dove lavoro?
grazie di nuovo
ciao
max

 applicazioni non girano sotto Linux) realizzo applicazioni per la gestione
e
Tieniti forte... ho un amico che tempo fa asseriva di essere riuscito a far
partire Visual Basic 5 sotto Linux utilizzando wine...
Presupponendo che ciň sia vero (e molto probabilmente lo č), č anche
presumibile che alcuni dei tuoi programmi VB riescano ad essere emulati e
fatti funzionare sotto linux. Potrebbe essere un'emozione forte :))

 contemporaneamente le due piattaforme.
Come tu dici è vero... ad ogni modo il mercato fa miracoli. vedi kylix...
Inoltre porting come corel photopaint da windows a linux ed emulatori di API
windows sotto linux (vedi wine), potrebbero essere la chiave di volta per la
portabilità di applicativi da win to linux. Vedi anche StarOffice,
praticamente identici a dispetto dell'OS. Non è poi proprio un'utopia la
portabilità del codice scritto in C...
viceversa da linux a windows ci sono 'emulatori' di chiamate all' OS come
cygwin che permettono di compilare sorgenti C/C++ progettati x linux, su
piattaforma windows.
Secondo me, queste differenze di ambiente grafico si potrebbero anche
superare...
Secondo me la scelta di Java per la scrittura di un IDE, semplifica di molto
tutto il lavoro di introspection che un IDE, per fare certe cose, è quasi
obbligato a fare. Emulare queste funzionalità in modo nativo, ne sono
convinto, è molto più lento e macchinoso che non supportarle in modo nativo.
Gli IDE nativi infatti, ho visto che usano spesso un'indicizzazione delle
API per poter rendere disponibile il codeinsight. Gli IDE java invece
operano direttamente sulle classi, il che implica che basta che la classe
sia compilata per poter avere la completition del codice e tutto il resto
"in linea". Secondo me, non è una scelta commerciale, ma una scelta
tecnologica. Credo che ci sia una stragrande maggioranza di programmatori
Java che sviluppano sotto windows e deployano sotto unix. Gli sviluppatori
Unix, forse un po' più conservatori, trovo siano più propensi e felici di
utilizzare editor come vi o emacs,che dopotutto offrono quasi tutto ciò che
un programmatore possa desiderare.
Ciao
Luigi

 Luigi
Ad esempio JCreator... implementato in C, disponibile solo per Windows.
Non so però se si possa classificare proprio come IDE... cmq ha quello 
che mi interessa... (ti ricordo che sono pigro e smemorato, e a me 
tronerebbe molto utile il code insight...)
Grazie
Alberto

 (forzata).
Già... purtroppo... però non esistono nemmeno prodotti free...

 
Nulla... dipende da quello che faranno questi 10 client... e dalla tua 
iplementazione...

 ogni database le prestazioni miglioreranno...
??? !!!! ????
Mai sentita questa cosa... e mi sembra moooolto strana...
Il mio personalissimo consiglio è utilizzare JDBC...

Scusa ma spiegati meglio... come intenderesti interfacciarti a db?
Per esempio, con che librerie ti collegheresti ad un database oracle. O ad
un'altro db?
Per il resto del discorso una query che tira su 1000 record non mi sembra
tragica... to' voglio esagerare... 2 secondi ? (dipende dalla dimensione del
record...)
Ciao
Jigi

 max
Fare una query non c'entra. Se usi Java per applicazioni "enterprise"
con tutti gli utenti collegati che vuoi facendo le query che vuoi, non
sarai penalizzato, e le tue prestazioni, al solito, dipenderanno da un
insieme di altri fattori.
Puoi replicare con Re, per cortesia (visto che ti vuoi avvicinare a
Linux, prova a postare con Outlook, in triplice copia e R:, e chiedere
come si ricompila il kernel....:)?
tityrus

 tronerebbe molto utile il code insight...)
Scommetto però che devi "indicizzare le classi" (o lo fa lui ognittanto in
automatico) per far funzionare il codeinsign funzioni su un package di
classi che hai fatto tu .
Gli ho dato uno sguardo veloce (non l'avevo mai sentito), mi ricorda
vagamente JBuilder 3.0...

Con JDBC puoi collegarti ad ODBC e quindi leggere qualunque database che 
abbia un driver ODBC. (quindi un bridge)
Per leggere i DB direttamente invece devi utilizzare i driver dei 
relativi produttori che supportino java...
Se non mi sbaglio, ad esempio, per leggere i un DB PostGres usi il
jdbcdev-1.2.jar o altri.


Sì ok... ma da JDBC NON BISOGNA SCOSTARSI.... difatti "jdbcdev-1.2.jar" a
giudicare dal nome è un driver JDBC.
Cioè... ho visto dei sorgenti dove c'è gente che si importa
oracle.jdbc.internal.* e cose del genere... roba da tagliargli le mani...
JDBC è un must... l'unico motivo per fare cose del genere è non sapere che
cosa sia JDBC.
Come gente che si implementa un parser XML fatto in casa... (ho un progetto
in gestione dove han fatto questo... una bella eredità...) quando invece
JAXP è ciò che va usato in questi casi, anche quando l'implementazione è
xerces, crimson, xml4j o qualunque altra...
jaxp sta a jdbc come xerces sta al driver oracle...
Se la gente si studiasse le tecnologie prima di utilizzarle certe disgrazie
non mi capiterebbero :'-(
Oggi sono un vittimista... portate pazienza... tutto il mondo ce l'ha con me
:-)
Jigi

 
Hai ragione a riguardo, certo č che perň i suddetti driver da te 
menzionati sono molto piů performanti rispetto ai classi JDBC