When it comes to storing data, what is the preferred method?
XML, JDBC (with or without ODBC) and an external SQL database, or one of these "in-the-application" databases (the ones I've seen are SQL)?
what kind of data? for a simple application you can use hsql or xml Any kind of data, I guess….I'm not thinking specifics here. Just in generalities.
ThomasO: flat files are still bomb Flat files…refresh my memory…files that contain text?
Not necessarily text, no Ah, ok. A quick wikipedia search turned up all the answers about them.
Rather primitive things, but effective for some information.
< \n> how do i clear a char[] array?
\n: you either iterate over it.. or scrap it and create a new one for (int i = 0; i < char.length; i ++) { char[i] = null; }
not really, no
Why wouldn't that work?
a char is not a reference
so that wouldn't compile
and it would be slow
< \n> i cant just say mychararray = null; ?
\n: that would not clear it as such.. just lose it 
< \n> i want to reuse it for a loop
< \n> just a temp var Err, not char. But char would be the name of your array. Then it might work.
well a char[] array implies it's a char[]
MXV: Wouldn't that work?
If, in my code, you replaced char[] with name[] where name was the name of the array in question?
Thomas0: null is not a valid value for a char
for(int i = 0, j = c.length; i < j; i++) c[i] = 0; would be the correct way to iterate over and empty a char[] array
….ok…explain the j thing… That seems like a waste of code.
it just avoids fetching c.length for each iteration
(which is not optimized away by the compiler and thus slow)
c = new char[c.length]; has the same result with gc overhead.. faster if the array is large and you do that fairly infrequently Doesn't the HotSpot compiler optimize it?
I was under the impression that HotSpot optimizes any frequently used code.
null rather than 0 and a variable named char were the only things preventing your code from compiling The char variable was just stupidity. And char is something I use infrequently.
So the first thing that came to mind was null, but if I got an error in a compiler, I would have changed that to 0 first thing.
Anyway…has anyone here used SmallSQL?
anyway, that can't be optimized away by hotspot.. as c might change to something else while the loop is running I never thought of that, but it makes sense.
hotspot optimization is rather sloppy.. so it won't bother to check the scope and resolve stuff too deep.
The first time I ran hotspot, I was like "hopy crap" after it turned a certain procedure into taking 5 minutes for large files to <2 minutes.
(and by large files, I mean reading in and analyzing multiple files in the GB ranges)
it inlines stuff and does some local copying, but nothing too fancy.
I've never bothered to analyze how it worked…it's not open source, is it?
just swapping out the interpreter for native code gives quite a boost in itself
the source is available with the scsl license Never messed with native code…you do mean JNI, right?
no.. hotspot generates native opcodes that execute directly on the cpu
Like good old jit As opposed to bytecode?
right If it's so much faster, why doesn't Java use it anymore?
methods are executed as interpreted bytecode until they get hotspotted
hotspot is quite like jit for frequently used methods
So java essentially does use it Wouldn't it be faster if all of the bytecode was transformed to native code prior to running? And then the native "executable" file would only function on one machine.
no But then you could take your source code and compile it or put your byte code on any machine.
then you would lose the dynamic optimization that hotspot does in addition to the compilation
Hotspot can optimize things a static compiler/optimizer can't do I was thinking like HotSpot but for the entire program…optimizing everything from the bytecode for a particular machine to make a unique executable.
which is why hotspotted java is faster than statically compiled C/C++.. or jitted java
unique executable is no good as it can execute in a number of different ways.. which calls for differnet things to be optimized
You would be inlining things that may never be never used I see…although this has been interesting, it's 100F+ here and a little too hot to be running my PC for long periods of time (stupid broken AC). So I'm off for a while.
Thanks MVC for a nice little convo to get me thinking about things.
as for storing data.. don't underestimate data records in a flat file with a separate index
Err…MXV.
Yeah, that is helpful…
Thanks again.