Java like C++ lib already in progress
Status: Beta
Brought to you by:
kenjin
Menu
▾
▴
See http://sourceforge.net/projects/jakecpplib/
"Right hand, meet left hand"
if you look at the source, you will find out that their hierarchy
design is totally different with JDK. That is not what this project about. This project will have same hierarchy design as in jdk except the byte code loading , class, runtime machinism.
I hate to sound stupid, but I need to clarify this...
Hierarchy of JDK: The base class for all objects will be "Object". (Same as jakelib's ZObject)
and for example:
FileInputStream will inherit from InputStream, which inherited from Object. And will have all the same member functions and data members as JDKs classes ( = jakelib!)
The difference that I do see is that with CJava, the programmer will not need to create pointers and do pointer manipulations. So in CJava the "new" operator will be overloaded to somehow return objects and not pointers to instances. Then implement some kind of garbage collection manager to free up the un-referenced memory.
Why do you say that jakelib's hierarchical design is totally different from JDK's?
This confuses me.
Ehrhardt
That is right, I agree with you. Right, if they already develop these kind mechanism and classes, It will be very helpful for our project, In this project, i hope we can be very open minded. Plus these utility class, how about develop AWT system using GLUT, (kind of independent from platform as i know) if you have some thought about these, we can discuss with that. Not only that, we may need to write an garbage collection machenism, but i think it is impossible to implement since we don't use stack based manipulation, java virtual machine have full control about the memory......
sorry for confusion.....
Good stuff
+ About GLUT:
I personally like the idea of using GLUT.
+ About the Filter program in ./cjava/bin/:
I also liked your filter program idea. Build some kind of Java to C++ conversion app that would convert Java source code into C++. By doing this we could save months of development by just converting the existing (and future) Java Class library into C++ code.
- Yes, we will have to write/implement the underlying GUI functionality. (GLUT seems to be a cool idea)
- We will have to decide how to handle all the other Java keywords like: synchronized, native, extends, virtual etc. Class would be easy since we all probably agree that we want to keep the OO paradigm.
- We will also have to figure out how to do memory allocation/garbage collection. (= handling of the new and delete keywords)
- And what to do about type[] array stuff??
If we can get the filter utility to work well, we will be able to build a newer CJava core lib whenever the Java JDK Class lib source becomes available. And we will be able to take advantage of other open source Java development projects - just converting their libs to C++ libs.
+ About Garbage Collection:
I have stumbled upon this C++ garbage collection implementation. Im sure that this is not the only one in existence: http://ginger.hpl.hp.com/personal/Hans_Boehm/gc/
+ It seems like I am easily confusable:
You said: we don't use stack based manipulation
What do you mean by this? AFAIK C/C++ processes have stacks.
And what about the Java virtual machine? What does that have to do about the C++ lib that we are about to contrive?
Ehrhardt
After reading about GC, it does make sense that you can
deallocate if you are using their allication functions. What I mean before is : intuitively, you can allocate and deallocate using new, delete in C++, it is really hard to keep track of
the pointer when you forget to deallocate and also losing the
pointer, in java virtual machine, they get full control of the memory allocation. Sorry for the confusion, It has nothing to do with the C++ shared library, but indeed, this is only some thoughts. The complexity that cause is really something that I have expected about them. However, a good library should encapsulate all the complexity into the class,
The conversion between java and c++ code can be if we figure about the exact difference and write some grammer about them. it will be more simple just "filter" the stream several time to make it looks like java. However, the condition is that we have exactly same object structure to make it happen, if not, what happen if the class is not found namely "ClassLoader" which seems useless in C++.....
Anyway, GLUT seems works pretty well in any system.
if we could utilize that write some basic class for them.
However, we don't want ours looks like QT library, an OOPS library, the main advantage is that when paper download
this library and install include file to /usr/include/cjava/ and
a library in to /usr/lib/libcjava.so , and then the user can just call their functions. We may not responsible to garbage collection in this case...........
this is just some thoughts.
Thanks.
Funny to see, that there are still a lot of people out there that believe in performance and pointers :o)
I am also working at a Java->C++ Port that seems to be simular to your both ports in some fashion.
I started to build up a jdbc layer and build up all those functionality that was needed for this layer (e.g. String, Vector, ...). My port is called cava. It makes heavily use of namespaces (e.g. cava::lang::String, cava::sql::Driver, ...) and follows a different approach to avoid gc. I am using smart pointer handle classes in front of implementation classes. This gives me the benefit of passing a 'big' object (also as a return value) with almost no overhead compared to a pointer. The caller has not to think about removing the memory at any heap, because the handle class does care of it (through reference counting).
Currently I am working at a JUnit clone (CUnit), that seems to be most important to me. After that I will finish and complete the jdbc layer. Next to come is RMI.
Sure this library is intended to run on almost all platform, nevertheless until now I am using VC++ only.
One of the most challanging things seems to be real reflection within C++. I thought about using OpenC++. Did anybody use it already?
Hey Darius can we have a look at your cava source?
Cheers
Ehrhardt
Hello Ehrhardt,
sure, I will send some snipets, when I finalized my cunit port. Then I will have a bunch of test cases that will show the handling as it is ment to be. Please give me one more week. Ok?
Regards
Darius
Here is a response from the jakelib author: Florian
>hi ehrhardt,
>sorry my response comes that late :-(
>yes, i'm interested in cooperation with others >having similar plans. at
>the moment i'm doing some tests with a garbage >collector for c/c++. if it
>works out fine, we'll be able to do things real >java-like.
>
>i already have several classes ready for action
>(http://www.donuz.de/lib/jakelib/apidoc/).
>since you don't seem to offer any downloads yet, >i can't see how far
>you've come already.
>but if you have a look at my sources you'll >probably be able to judge
>whether our styles could match or not.
>
>regards,
>florian.
>
>Floria | /
> / \ /\ /
> / \/ \/ olff mailto:florian@donuz.de - >http://www.donuz.de
>
Ehrhardt