Hi Jan,
On 12/11/06, Jan Ciger <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
bertrand greslier wrote:
> On 12/11/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
>>
>> Hi Bertrand,
>>
>> On 12/11/06, bertrand greslier <[EMAIL PROTECTED]> wrote:
>> > Of what advanced use of C++ do you talk about excatly ?
>>
>> Templates is the biggy.
>
>
> Templates exist in java since version 1.5 ...
>
>> The parsing could be a fork and a first start for the java
>> implementation.
>>
>> You have to look to the practicalities of parsing C++ and converting
>> to Java and the maintainence thereafter. Personally I think this
>> avenue will just be a nightmare and the branched project would soon
>> collapse.
>>
>
> I have study the tools and it is possible to parse easily with
javaCC...,
> now I am able to do it.
> But you are right the fork is not a good solution because of there is
two
> versions to maintain.
> And the parse is generally not a good solution, often a nightmare and
> collapse if you lost implementation information.
> But my first idea is than all princip of C++ are in bijection with java
> C++ class <-> java class
> C++ template <-> java template
> C++ attribute <-> java attribute
> C++ method <-> java method
> Except these real difficulties :
> C++ OpenGL <-> api jogl jsr-231 or other. (ok for me)
> multi-inheritance <-> equivalent mecanism in java. (ok for me)
> STDlib <-> java implementation of stdlib or java equivalent. (to think
> about)
>
> another ??
>
Eh and that is not enough? The mapping of e.g. C++ classes to java classes
works
only on paper, in reality you will have to rewrite quite a bit (e.g.
mandatory
exception handling in Java, multiple inheritance doesn't have a Java
equivalent
unless you want to redesign the code to use interfaces, etc.)
Add automaticaly a try catch or automaticly recode a similar multiple
inheritance seems not be difficult.
Example class A { int x; }; class B{ int y; }; class C : public A, B { int
z; public: void test(){z = x + y:} ; };
=>(java translation) => public class C : extends A { int z; B b; public
void test(){ z = x + b.y; } };
What about STL? That is not stdlib (these are two different things). Are you
going to re-implement STL in Java? If yes, isn't it easier to just write a
C++
compiler in Java? That is what you are trying to achieve, IMHO.
(What is that IMHO please?? I am not very fluent in english)
Ok you are right, STL is a big problem, also stdlib, and also all OSG
dependancies.
Finally it seem to be very hard for these reasons.
I have seen similar "Oh, that is easy" mentality few years ago when some of
my
former colleagues tried to re-implement a pure C project 1:1 to Java
because the
management thought that it is easier than redesigning it (aka "We do not
need
any Java experts if it is a 1:1 translation. Even monkey could do it.").
It was
a three year disaster which ended as a huge waste of time and money after
the
project was finally canceled because the code produced was completely
unusable.
It would have been way simpler (and faster) to just wrap the C code and
use it
from Java or redesign and rewrite it from scratch in Java.
C code is not object oriented code. I think you don't compare apples with
apples.
And I am a java expert (I believe it ;-)).
Moreover, what is a point of doing this? What would you gain by a pure Java
implementation over the JNI binding except of a slowdown?
Yes a slowdown. The result is also a little slowdown. You are right. But it
is not
my goal, my goal is to have a independant platform code as the java is.
And my fist goal was to extend the OSG community to the java community.
And I believe that if you have a good frame rate it is not only because C++
is faster than java.
It is your graphic card witch work for the C++ not the inverse.
It is a C++ API, not a
Java API,
I know that. But for example XML Xerces has C++ and Java implementation.
I could be interessant for OSG to become also a standard API in java.
you will still have to deal with kludges due to that. Moreover, you
will still need parts which are not Java - e.g. OpenGL because you are
talking
to hardware at some point. This is not reasonable engineering, IMHO, more
like
"not invented here" (or rather "not written in my universal language")
syndrome.
Yes the jvm is not other than a set of .dll or .so and works with the
hardware.
I believe OpenGL will be completly integrated to the jvm soon.
Thanks for your advices.
Regards,
--
Bertrand Greslier
http://www.cooki3d.org
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
