[raztoki]

ok lets clear up some misconceptions here
a) jdownloader request files to be written using apis, it has zero control over where the data is saved to disk. ultimately this is a task of your operating system, and somewhat these days the hardware (or drivers) thats attached to your harddrive (magnetic or sold state)!
b) jd2 does utilise sparse (assuming your os supports such thing) (common with p2p software), this means the entire space requirement is preserved. No significant data is actually written to file, its just pre-reserved at the file table (as I understand it). So when you are downloading and the buffer is fulls, it then sends/flushes said data to that file.

so with a combination of a and b your operating system backend should allocate space in some logical order. The only time this wont happen is storeage device self manages write locations/cycles, or your storeage device is nearly full or heavily fragmented to start with or combinations of all of the above.

with newer harddrives (ssd's), they have limited write cycles (as you referred), so they balance the write cycles semi evenly which means files or part of files are stored all over the drive. This extends the life of your drive. ssds tend to not suffer large performance issues when data is spread out like this, actually it can increase the speed as internal reading from multiple chips can happen at the same time (kinda like how raid array works). they also do no rely on moving parts in order to seek a different location in order for the head to read fragmented data, and less moving parts/motors == less heat.

in respects to ram, Java does NOT have a limit of 512MiB (32bit Java max 4GBytes, and 64bit Java max is more than you can install in your system (at this time), 16EBytes). Be aware that also some operating system prevent the use of the ram figures (have a quick google). you can start it with more or less, depending on your starting parameters. I believe the installer will set a limit based on your systems ram availability. Some of the older installers (if you keep using old ones) can have fixed limits. 'vmoptions' i believe is the file you need to edit to change default.

in resects to buffer/cache, The only control like you have mentioned is the cache (held in memory before sent to write task). This limit is set for the average user. keep in mind that every download * chunks requires memory allocation (20*20 == 400 * 500kb (default)), thus if you start lots of downloads can be memory intensive, even more so if you move to larger allocations like your screen shot indicates. Also there are other buffer settings, filter keyword buffer over max, =].

in respects to extraction it should work in a similar way to JD, it uses java apis in order to read and write files. So location on file is once again out of control of the application far as I'm aware. Fragmentation at this point shouldn't happen either because the uncompressed filesize within the archive volume is known, so when creating file on disk (extracting) it could tell the os the exact byte size, its not like it keeps amending/expanding a file size.

in respects to why java was used? I assumed it was because thats what the original authors learnt at university and they wanted to utilise there skill base over learning another language? makes sense no? Also cross operating system support is native, you have very little operating system specific code, so it makes it open to largest possible userbase. In respects to Java is buggy, its 24 years old... I personally don't agree with your statement. Traditionally its seemed as memory intensive and even slow, but my opinion has changed over time.

hope this helps

raztoki