How much tweaking? Not that much but some of it is pretty tricky. Yes the Lego software does provide an interface to the hardware but it is not always in a from the is easy to use from leJOS/Java.
The basic structure of the Lego software is that the kernel provides really low level access via a toolkit from TI. So this lets you really control the hardware, set timers, sort out pins, A/D controllers etc. Then there is a set of kernel modules that turn the hardware into sensor ports, motor ports, LCD devices, things that can play sound etc. Finally there is the Lego VM which handles execution of the byte code but which also has a lot of code for things like the sensor identification, drawing text, handling sound files etc. The VM runs as a user level program and talks to the kernel modules through a set of Linux character devices. You talk to these devices using a mixture of read/write calls ioctls and memory mapped file operations. There are a number of options to how to interface to the system from leJOS:
1) Talk directly to the hardware using the TI libs
2) Turn the code in the Lego VM into some sort of C library (the VM is written in C) and make JNI calls to that.
3) Talk to the kernel module interface.
In this initial implementation I used option 3. It is reasonably straight forward but there are a few things that needed sorting out:
1. Java does not really do ioctl and memory mapped files that are based on character devices.
2. The interface level used by Lego does not always match well with our model. So in Lego's case all of the low level PID control for the motors is in the kernel module. We like to do as much as possible in Java so there was a mismatch there.
3. There is an entirely new class of sensors in the EV3 that use a UART interface and that have a very different model to the analogue and i2c based devices. Plus there is a bunch of stuff to auto detect of the sensor and a mechanism to allow the new UART sensors to describe themselves.
4. A whole bunch of detailed stuff, like the actual bit/byte layout of the LCD display which is different to that used in the NXT and so needed new font bitmaps and a reworking of the bitblt function.
5. Some totally new sensors to deal with (like the IR sensor which is very cool).
But in general the port has been reasonably ok. There are lots of things that need sorting. The sensor model probably needs to be reworked to function well with the sensor auto-detect stuff. Bluetooth and USB need to be re-implemented from scratch. We need to work out how users will normally use the device, so getting files to it, running them etc. At the moment I use NFS and telnet, but I'm not sure if that will work for everyone.