Native Database
Submitted by sagsaw on Thu, 07/09/2009 - 05:15.
How about including JavaDB with Jnode 0.3
It would run in the client server mode, start at the startup and the OS would have a native database.
How about a Jnode--->Accessories--->Addressbook menu entry and the application bundled with Jnode 0.3
Also can we study the feasibility of storing most OS settings in JavaDB instead of flat files like in linux or ini files in windows.
With the in memory database feature, I am sure this would be a very fast way to access all setings and the user interface would be very fast rather.
With 2 GB RAM being a standard nowdays and RAM prices in general falling down, I guess very soon 8-16 GB RAM could be possible on home desktops/laptops and thus caching settings data or any frequently accessed data using in memory database would greatly improve speed of the GUI and the OS as a whole.
- Login to post comments
Have you tried running JavaDB on JNode?
Have you tried running JavaDB on JNode? Can you contribute instructions / patches / whatever needed to make it work?
I don't understand the relevance of an AddressBook menu entry though. We don't have an address book app ... yet.
Your point about memory is moot until we get the x86-64 port of JNode working. Even then, I suspect should implement a FS-independent disk block cache to allow memory to be used for FS caching. Interesting, but there are probably more pressing issues ...
Work begun on JavaDB/Derby
Hey hagar and Isantha
Since i downloaded the latest svn head, i have seen some work done by hagar in distr directory to get derby working.
M also working on the same and will post the results soon in this thread itself ....
If successful, i will request for a commit auth for the derby/javadb sub project ....
if granted this right it would boost my confidence
about granting commit rights ...
we only give rights after some approved patches has been submitted.
As I understand your sentence, it seems you thought no patch is needed to be approved as a commiter. But it's not your fault at all because that rule is written nowhere (we need to fix that IMO).
Fabien
my blog : en français, in english or both
Hurray First hurdle passed
Hello
I managed to get the ij tool running ...
I tried to get derby fired up in embedded mode ... but it gives NPE and exits ... am doing more work as and when i get time ....
for now am attaching a screen shot of this historic moment
Do we need a patch ...
... to run ij ?
Fabien
my blog : en français, in english or both
RE: Do we need a patch
No Fabien ....
Will post the detail steps ....
m also trying to get Derby working ....
but will post steps for ij ....
its crude since i do not have the full documentation of plugin xml file ... but it sure did work ...
Derby_error shot
Attached is the error screen shot when i try to start derby in embedded mode from ij.
I felt that this probably has more to do with Jnode than derby ... so before i start to work on trying to dig into derby for debugging, i thought that someone can take a look at this shot and check if its Jnode or derby that is the problem ....
Sagar
I've made some progress with
I've made some progress with this.
Can you check if the reported exception is fixed?
That error was ....
.... fixed but a new one has cropped up ...
Attached a screenshot ...
I've committed some code
I've committed some code related to that exception.
Could you please test it again?
no the exception still ....
.... persists ...
attaching screenshot ...
saw that you committed nativeunixoperatingsystem.java ...
dont think it exists in the repository anymore ... i cant find it in the checked out src ...
The file was in there but
The file was in there but some packaging information still missing.
This is sorted out now.
ok some progress ..............
........................
the database is created but the command does not return even after 2 hours with CPU usage 50-100 % and i have to press CTRL + C to return after which ij ends and prompt is returned.
the database is created in the dir /jnode/home but since the command does not return which means that i need to get a debug version of derby so that all the log after firing the connect command from ij is written to the derby.log and only then we can identify what is causing this ...
first of all ij needs to be run from /jnode/home as this is the directory which has read write access.
in the attached screenshot the error derby.log not found is due to the fact that i ran the ij comand from /
i am still digging deep ... but on a very very high level, i think that we must ensure that any java application runs out of the box on jnode and make all necessary changes in jnode for that ... rather than making changes in the applications source code instead unless absolutely necessary ... PLATFORM INDEPENDANCE OF JAVA MUST BE INTACT ....
I do not see an error in the
I do not see an error in the provided screenshot so I can not comment as to why it's not working.
Though I'm commenting as I'm not sure I understood your last paragraph. We exactly are trying to do that, we're modifying JNode so it can run any Java app and the patch by levente tried to do just that: He implemented (though with a stub implementation) a missing piece of code in the openjdk classlib.
Of course to find a bug it can happen we have to modify the app we're trying to run. But that's just for debug purposes. So, in case you mistook levente's commit, I'm ensuring you that JNode's development tries to keep "java is platform independant"
Thanks Peter ...
... its very clear now ...
but i am stuck at this point with JavaDB
My Observations till now
1. ij runs successfully.
2. connect ..... create=true; command fires JavaDB in embedded mode, creates the database but the command does not return ...
even after many hours ...
Possible cause ...
something is still missing from Jnode which is a part of the connect command after the database is created and hence the command neither returns with a success message nor with a error message. It might just be stuck up in a loop as the CPU usage is around 50-100%
Required some inputs to proceed ...
some tips
If JNode is not locked, then you should
- look at the log console
- create another console before testing derby : then you can type 'thread' in it
There is also jnode's kernel debugger, which might help you see what thread is blocked and if I remember well you can print a thread's stacktrace.
Fabien
my blog : en français, in english or both
Thanks but ...
....
i run jnode in the non gui mode so how to create another console?
then how to access it? similar to linux ATL+Fn keys ?
you can also create another console in non gui mode ...
by using the console command and you can switch between consoles by using the Alt+Fn keys, look at the Keyboard Bindings.
Fabien
my blog : en français, in english or both
ok ......
...thanks fabien will post the results once i get some time to check out ... in a couple of days probably ...
This reminds me of some of
This reminds me of some of the problems we also had with Ant. It turned out that they call native code... I think we have to work on this. Still, it's nice to see you are getting on with the task of getting derby running.
Will Check
it out in a couple of days as time is curently at a premium ...
will update from svn check and post the results .....
sorry ....
.... Isantha, m not able to find time ....
but will surely update from svn and post you the results by this week end ....
It's a JNode problem,
It's a JNode problem, indeed. A native method implementation is missing in the VM interface of the classlib.
Also ...
..... let me know some more about Jnode Engineering ....
where can i get the info ...
documentation mentions diagrams which are not there ....
Correct me in the following ....
1. Jnode has its own VM written in ............?
2. Java API is built on top of it using Open JDK ....
3. I see NativeCheckBox.java and more ..... why native and not the standard?
4. From what i understand .... micro kernel boots the native jvm built using JVM specifications and written probably in assembly(i guess for this case its the only language in which you can write it)... this jvm actually can be thought of as the OS ......... the implementation of this jvm is still not complete ....and
probably so is the full JAVAAPI ....
So till the jvm is not complete, which by itself it a huge task, some things might not work ...
sagar
answers
1. Jnode has its own VM written in Java
2. Java API is built on top of it using Open JDK + some parts from GNU Classpath and IcedTea
3. I see NativeCheckBox.java and more ..... why native and not the standard?
NativeCheckBox is the class that implements the native methods of the CheckBox class.
The aim is to have an unmodified class from the Open JDK (here it's CheckBox).
When the JNode VM find a native method, it will try to find a class with the same name but prefixed with Native :
example : CheckBox -> NativeCheckBox
4. From what i understand .... micro kernel boots the native jvm built using JVM specifications and written probably in assembly(i guess for this case its the only language in which you can write it)... this jvm actually can be thought of as the OS ......... the implementation of this jvm is still not complete ....and
probably so is the full JAVAAPI ....
So till the jvm is not complete, which by itself it a huge task, some things might not work ...
Yes, the micro kernel is written in assembly. Everything else is written in Java, including the garbage collector, the JVM (except when it's not possible in Java), the drivers.
I am not sure about the completion state of the JVM.
The binding between the implementation of Java APIs (=Open JDK + GNU Classpath + icedtea) and JNode is not complete : yes, it's a huge task !
Fabien
my blog : en français, in english or both
Guide me ....
.....on what next ???
Best to wait ...
... for an expert (ideally Levente if he has time) to fix the problem.
Have you looked at ...
... that page of the documentation ?
If you find something is missing in that documentation, don't hesitate to ask both here or on irc channel.
Then I could add the missing informations.
As an additional source of information, you could have a look at the other plugin descriptors.
Fabien
my blog : en français, in english or both
FS caching
Well what I was talking about is not a low level FS cache but a more higher level application setings cache.
I guess windows explorer or Nautilus file manager in linux stores user setings like arrange icons ... list view icon view thumbnails etc ....
FS cache would be great to have in memory ... but i guess the everhead of sql would defy the speed improvements for the FS but for applications i guess this would increase the speed of the GUI ... especially for OS level applications like a File Manager.
Secondly, what i meant by a menu entry was that if Java DB is successfully run on Jnode then a application like Addressbook can be added.
I am jumping the gun and visualizing release 1.0 too early, but I am very much fascinated by this project, but unfortunately am not finding much time to dedicate to it ...