Why Haiku use custom java.lang ( haikuRT ) and it's rewrite classes from "haikuVM\lib\nxt\classes.jar" ? Why use haikuVM\lib\nxt\classes.jar ? May be write all need classes in haikuRT and not use haikuVM\lib\nxt\classes.jar ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
building an own JAVA runtime would be reinventing the wheel and a way to much effort (e.g. writting all this useful classes of java.lang). So, I decided to go with leJOS (classes.jar) instead of building my own JAVA runtime.
In fact, HaikuVM is using this classpath (snippet):
C:\haikuVM\haikuRT\src\main\java;C:\haikuVM\bin..\lib\nxt\classes.jar;...
This classpath translates to:
First: Use my modifications (e.g. of java.lang.String) given in project haikuRT.
Second (if not found in haikuRT): Use classes.jar (the runtime taken from leJOS).
On the other side: Why did I need to rewrite e.g. java.lang.String in haikuRT?
The answer is, not to write a better implementation of java.lang.String than leJOS already had. Instead I sadly was forced to write my own java.lang.String class, to match with my simplified memory layout (see typedef struct {...} HVM_String;) of my String implementation given in my C code of the HaikuVM-VM.
Kind regards
Bob Genom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And why Thread class in haikuRT contents method java.lang.Thread#nap? Why not create method as in original java.lang.Thread class? This will be perfect for run code on standard JVM - all methods will be as on JVM and all will be correct compilation.
And for specific method may be create separate class?
For method "nap" :
Change java.lang.Thread#waitUntil, setStateAndSwitch and currentThread access modifier from private to package-private and create in java.lang class for method "nap" (e.g. java.lang.ThreadMicro#nap) with similar functionality.
For this case we can run code on JVM and if will be use method "nap" we create JVM-version for method "nap" with similar functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please tell me, why exactly Thread#nap does hurt you. And why Thread#waitUntil and Thread#setStateAndSwitch does not hurt you? Do you have an example code?
But anyway, sounds like a good idea to move nap() from Thread to e.g. ThreadMicro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's need for run Arduino code on original JVM without rewrite original code. Example:
We have Java code.
public static void main(String[] args) {
for (int i=0; ; i++) {
Thread.nap(1000);
System.out.println("Hello World Java "+i);
}
}
(How format Java code on posts?)
For run this code on JVM we needs have methods Thread.nap(long ms). For it's we need rewrite original java.lang.Thread class and add method nap(long ms). And rewrited class have contends all methods original java.lang.Thread class and new method - nap(long ms). It's will be code-duplication. Otherwise for use additional class for additional methods (e.g. java.lang.ThreadMicro with method nap(long ms) ) we need create only one class with one method for run below code on JVM:
public static void main(String[] args) {
for (int i=0; ; i++) {
ThreadMicro.nap(1000);
System.out.println("Hello World Java "+i);
}
}
For run it's code on JVM we need only class ThreadMicro with method nap(long ms):
For run it's code on microcontrollers we need class ThreadMicro with method nap(long ms):
public static void nap(long ms) {
Thread.currentThread.waitUntil=System.currentTimeMillis()+ms;
Thread.currentThread.setStateAndSwitch(Thread.WAITING);
}
With it's code for java.land.Thread on microcontrollers we need Thread.currentThread, Thread.setStateAndSwitch, Thread.waitUntil and Thread.WAITING change "private" to "package-private").
And for run it's code on JVM we need have only one class with one method (ThreadMicro.nap) and this all. Otherwise for run code with Thread.nap() on JVM we need all class java.lang.Thread additionally with method nap.
Do you understand me?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And if support back compatibility for JVM we can use debugging if run code on PC (it's from "Ideas and brainstorms" - "Enable runtime debugging." ) :)
I'm using similar use case for testing compile-to-JavaScript Java code on GWT - it's run on usual JVM.
Last edit: TimReset 2015-05-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may run this with your favorit JVM on your PC. With a proper HaikuKernel you also may run this on e.g. a Duemilanove. See tutorial http://haiku-vm.sourceforge.net/#[[Tutorial%20All%20About%20MicroKernels]].
Another outstanding example is haikuvm/bench/Fibonacci32Bit.java. Run this on your PC and compare the results and performance when running on e.g. a Duemilanove, like I did here http://haiku-vm.sourceforge.net/#Performance.
The program Fibonacci32Bit.java is taken from the HaikuVM project haikuBench. HaikuBench is all about: "support back compatibility for standard JVM".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why Haiku use custom java.lang ( haikuRT ) and it's rewrite classes from "haikuVM\lib\nxt\classes.jar" ? Why use haikuVM\lib\nxt\classes.jar ? May be write all need classes in haikuRT and not use haikuVM\lib\nxt\classes.jar ?
Hello TimReset,
building an own JAVA runtime would be reinventing the wheel and a way to much effort (e.g. writting all this useful classes of java.lang). So, I decided to go with leJOS (classes.jar) instead of building my own JAVA runtime.
In fact, HaikuVM is using this classpath (snippet):
C:\haikuVM\haikuRT\src\main\java;C:\haikuVM\bin..\lib\nxt\classes.jar;...
This classpath translates to:
First: Use my modifications (e.g. of java.lang.String) given in project haikuRT.
Second (if not found in haikuRT): Use classes.jar (the runtime taken from leJOS).
On the other side: Why did I need to rewrite e.g. java.lang.String in haikuRT?
The answer is, not to write a better implementation of java.lang.String than leJOS already had. Instead I sadly was forced to write my own java.lang.String class, to match with my simplified memory layout (see typedef struct {...} HVM_String;) of my String implementation given in my C code of the HaikuVM-VM.
Kind regards
Bob Genom
And why Thread class in haikuRT contents method java.lang.Thread#nap? Why not create method as in original java.lang.Thread class? This will be perfect for run code on standard JVM - all methods will be as on JVM and all will be correct compilation.
And for specific method may be create separate class?
For method "nap" :
Change java.lang.Thread#waitUntil, setStateAndSwitch and currentThread access modifier from private to package-private and create in java.lang class for method "nap" (e.g. java.lang.ThreadMicro#nap) with similar functionality.
For this case we can run code on JVM and if will be use method "nap" we create JVM-version for method "nap" with similar functionality.
Please tell me, why exactly Thread#nap does hurt you. And why Thread#waitUntil and Thread#setStateAndSwitch does not hurt you? Do you have an example code?
But anyway, sounds like a good idea to move nap() from Thread to e.g. ThreadMicro.
It's need for run Arduino code on original JVM without rewrite original code. Example:
We have Java code.
(How format Java code on posts?)
For run this code on JVM we needs have methods Thread.nap(long ms). For it's we need rewrite original java.lang.Thread class and add method nap(long ms). And rewrited class have contends all methods original java.lang.Thread class and new method - nap(long ms). It's will be code-duplication. Otherwise for use additional class for additional methods (e.g. java.lang.ThreadMicro with method nap(long ms) ) we need create only one class with one method for run below code on JVM:
For run it's code on JVM we need only class ThreadMicro with method nap(long ms):
For run it's code on microcontrollers we need class ThreadMicro with method nap(long ms):
With it's code for java.land.Thread on microcontrollers we need Thread.currentThread, Thread.setStateAndSwitch, Thread.waitUntil and Thread.WAITING change "private" to "package-private").
And for run it's code on JVM we need have only one class with one method (ThreadMicro.nap) and this all. Otherwise for run code with Thread.nap() on JVM we need all class java.lang.Thread additionally with method nap.
Do you understand me?
And if support back compatibility for JVM we can use debugging if run code on PC (it's from "Ideas and brainstorms" - "Enable runtime debugging." ) :)
I'm using similar use case for testing compile-to-JavaScript Java code on GWT - it's run on usual JVM.
Last edit: TimReset 2015-05-06
This is exactly what I'm trying to do: "support back compatibility for standard JVM".
For example take arduino/tutorial/HelloWorldJava.java with a main function like this:
You may run this with your favorit JVM on your PC. With a proper HaikuKernel you also may run this on e.g. a Duemilanove. See tutorial http://haiku-vm.sourceforge.net/#[[Tutorial%20All%20About%20MicroKernels]].
Another outstanding example is haikuvm/bench/Fibonacci32Bit.java. Run this on your PC and compare the results and performance when running on e.g. a Duemilanove, like I did here http://haiku-vm.sourceforge.net/#Performance.
The program Fibonacci32Bit.java is taken from the HaikuVM project haikuBench. HaikuBench is all about: "support back compatibility for standard JVM".