You need to be looking at java.nio.file.StandardOpenOption.SYNC and DSYNC and the java.nio.Files class to be doing this sort of I/O rather than the old java.io.* stuff.
Oracle have just announced early access JDK for ARM compiled using the hardfloat ABI! Rejoice! Now I can get down to writing some proper games for it. I'm hoping to make my stuff available to all to kickstart a few games programmers out there.
One thing that would be quite a keen thing to do is to not need X to run. Going direct to the drivers and bypassing any crappy windowing system is a very useful thing to be able to do. I wondered that an SDL backend for LWJGL might achieve that nicely. Solve the input problem too.
I do believe we've got a complete OpenGL ES 2 binding in LWJGL already but what you're asking is somewhat beyond the remit of what LWJGL seeks to provide which is a straight binding to native libraries. For a retargetable graphics API, you would want to be looking at libgdx which does exactly that. ...
There's no difference whatsoever between headless and headful - all the headful ones provide extra is the libraries and APIs to do AWT and sound, and you're not using the AWT libraries. (Try it for yourself - do a Hello World and run it under each; measure the resource usage before exiting).
<r>No complaints at all for RasPi - I just wanted to share the results of my investigations about Java on ARM based devices. Basically: slow, only useful as a toy at this stage.<br/> <br/> And dudes - svartalf implies that we (Puppygames) can't write fast, efficient code in Java, because he can't wr...
<r>Svartalf appears to be inviting them; it would help if he did not place a veiled insult about our work by describing his own inability to get it to do what he wants.<br/> <br/> If anybody else in this thread would like more real information about Java please head on over to java-gaming.org and/or...
Android is not Java and fairly rightly deserves the colossal lawsuit against it from Oracle. And I still feel from your descriptions that it is you that is limited, rather than the tool. We don't seem to suffer any limitations.
<r>@Svartalf - Quake3 was ported to Java years ago. J2SE is eminently capable of doing more or less anything you throw at it, in a desktop context. The world I think may have moved on last time you looked at Java (guessing maybe 10 years ago now?)<br/> <br/> @others - this was a thread asking about ...
Skills and knowledge investment mostly. Besides, why change when it does nearly everything you need? Until some set of problems comes along Java doesn't solve nicely I'll be sticking with it.
What have securities and market transactions and life-critical applications got to do with RasPis? You use Realtime Java for that sort of stuff. So hardly relevant to the thread, and not relevant to the device.
I wouldn't go adding FUD and a general display of ignorance about how Java works, how fast it is, or soft/hard realtime programming, in a thread from people interested in getting Java on the device...
<r>I wouldn't let CPU or RAM considerations get in the way of whether people want Java or not (which is not what this thread is about); as I have said, I've used the Oracle embedded JRE and it's every bit as fast as the desktop version even in the very constrained environment I tried it on.<br/> <br...
<r>There is a fourth choice but it sort of depends on RaspberryPi.org and Oracle being best friends. Stranger things have happened at sea but don't discount it! Their VM is after all mostly sat there doing bugger all as they've failed to convince anyone to license it.<br/> <br/> It's absolutely grea...
<r>My reasonably extensive investigations with others currently show me GCJ went nowhere and wasn't exactly producing particularly fast code (notably the GC implementations were very weak).<br/> <br/> All of the open source JVMs out there are barely functional let alone fast.<br/> <br/> And C is of ...