javac
Submitted by lsantha on Sun, 05/16/2004 - 21:43.
I'm glad to announce that after fixing several bugs, I succeded to compile a Java source file and run the resulting class inside JNode.
During next week I will post the detailed procedure.
Levente
- Login to post comments
EDIT, COMPILE and RUN Java code under JNode
I implemented the following features:
- implemented the edit command for editing text files, part of the
default and full configuration
- extended the java command, now it uses a custom classloader and treats the current directory as classpath, this will be extended further. At the moment this command is able to execute different subsequent versions of the same class without conflicts. This means in theory the edit-compile-run cycle should already work. (It happened that I modified, compiled and run the same class 4 times in a row when JNode blocked )
- tested and packaged the kjc compiler for immediate use under JNode.
For now you can download it here. This plugin adds an alias caled javac, that invokes the main class of the compiler.
I also fixed the bug in java.lang.reflect.Array and a bug in java.util.ResourceeBoundle, otherwise some of the above things do not work.
Further notes on the compiler:
- increase the heap block size in DefaultHeapManager if needed so that the kjc plugin can be loaded
- you should have a writable partition, I used ext2, wich blockes quite often but it makes some things already possible
- you sould make availabe all classes required by the compilation of your program. (I copied from the build directories under JNode all the classes (core, shell, net, gui etc) to the ext2 partion in a common directory).
Here is a usual invocation of javac in my setup:
javac -C/hdc1/c/ Test.java
The first compilation takes a lot of time, while you might see deadlock messages, gc cycles, and a misterious messages that also block the console for a while and I don't know what it is.
The suubsequent compilations have chance to get much faster.
Since JNode might have trouble doing 'a lot of things at once', I sugest to perform simple operations before the more complex ones, like dir, cd /smohe/where/, dir, javac, javac -help, touch Test.java etc, to warm up different subsystems of JNode. It seems that JNode blocks easily when it should compile lot of classes and also make disk operations in a short time.
I hope these tools will show you clearly the weak points of the system and where should the work go during the comming weeks. I also hope that they will be increasingly useful as JNode advances in the future.
Regeards,
Levente
GC problem
Lately I have played a bit with the compiler. I wrote a small program in JNode that prints the number of heap blocks and how much free space is in each one. This showed me signs of a lot of uneeded work by the garbage collector. I'm not sure what the problem is yet but it just gets called way too often and it looks like this is related to the way memory is allocated. Somehow the system does not use a lot of free space (which is often much more than 50% of the total memory) that is there, instead it calls the gc. Since gc is still a time consuming operation (about 15 seconds in my setup) and on average it gets called once for every two or three compillations, it makes the above features quite tiresome to use.
Otherwise a small HelloWorld like program gets compiled under one second, wich is not bad at all .
So if this gc/memory allocation problem and the deadlocks in the IDE driver, mentioned by Andras get fixed, the development under JNode instantly would become more enjoyable.
It would be nice also to have the whole set of classes used by JNode (or at least Classpath and the core JNode classes) available in a dedicated directory somewhere next the /jnode directory or under it.
The classes are there in the memory, why should we set them up gain, though I'm affraid their format might not be suitable for javac if they are compiled to native code.
I wonder if we can distribute a compiler and other tools (that were lately mentioned to come) with the next version of JNode as long as their license permits it. This could be done either included in the CD image or as separate plugins readily packaged for download and immediate use.
Just a few thoughts for moving on...
Levente
It works!
Great stuff, Levente! I have just tried it and I've managed to write, compile and run 'hello world' from within JNode (after some attempts that resulted in "real panic"s...)
But as you wrote yourself, we have a lot to improve in JNode (currently I see the IDE driver as an important part of JNode that should be improved as it is constantly getting into deadlocks)
Andras
Nice!
This is great work!
I'll try it as soon as my daughter permits it.
Ewout
Great
It's a great news and i test it as soon as possible. I think it will be a good idea to verify if bugs you corrected in classpath already exist in cvs version of classpath and send a patch to correct thesebugs to the classpath team.
Fabien.
Excellent
Excellent work. The proccesses you have shown are foundational parts of advanced Jnode developement.
Alex
Good news
That's a good news !
I will see if I can use it with Ant.
Fabien
edit
A small general purpose text editor is comming soon.
This will be ivoked by the edit command.
I am working on an ant command
So, JNode will be able to compile itself. Because we are under JNode, we don't need to call nasm and mkisofs that are only needed for building a new boot.
I think it's a good test for running third party java application in JNode. Here is some ant functionalities that may cause problems :
- ant use its custom classloader
- ant is configuring its own classpath dynamically
- ant is able to run native application
- ant can invoke another JVM instance
Fabien
great, thats usefull
Hi,
I like the idea.
The next step is to create a Plugin from within JNode
Trickkiste