[Kde-java] Re: GCJ (Re: Build system for KDE4)

[Thomas Zander]

On Thursday 16 June 2005 13:20, Martijn Klingens wrote:
> Richard Dale said:
> >> Next to that; Java packages and C++ namespaces are used in different
> >> manners which lead C++ people to create huge namespaces and shallow
> >> trees, exactly the opposite of Java people.
> >> I'm still inclined to do the packages like I proposed before; based
> >> on which dir they are in currently.  With classes that may be moved
> >> specified using regexps in a config file.
> >
> > Yes, ok we could just ignore C++ namespaces and base it entirely on
> > the directory the include file is in for a class.
>
> I don't think that's a good idea at all.
>
> The goal is not to create a Java kdelibs API from scratch, the goal is
> to bind Java to the kdelibs API so that one can use KDE classes in Java
> and the other way round.

Ehm; no. I don't agree on that goal. If thats the goal then expect pretty 
bad uptake from Java programmers.
At FosDem I talked to the java-gnome bindings guy and he created a lot of 
stuff that is not in the gnome libraries (event handling for example); 
and that works. People use that.

> Therefore the original API is leading and the other language will need
> to follow. Anything else makes porting code harder, 
porting?
> makes api docs inconsistent, 
They are copied into the binding classes, so this is not true.

> makes copy-pasting examples a pain, etc. 
Copy pasting C++ code to a Java program will not work anyway; and imports 
v.s using are so different that this will fail anyway.

> While I agree that it will make the KDE APIs look a bit awkward in a
> Java ecosystem, so be it. 
You are awfully quick to throw a huge benefit out the door.  How convinced 
are you that C++ coders will start to program Java any time soon? Using 
their knowledge of the kdelibs API and expect it to be there in Java?

I'll tell you what my expectation is on that front; almost no C++ coder 
will 'switch'.

> When the bindings gain in popularity there 
> will also come C++ code with awkward-looking code due to imported Java
> APIs. Still better than mappings that are non-obvious.

Here you are wrong; no Java programmer will reference the C++ code 
examples or books or API docs.  They are useless for those programmers, 
as Qt is build on macros and various dirty tricks working around the 
problems in C++, no Java programmer will understand such things.
So your claim goes out the window since there will be virtually no Java 
programmers that are interrested in knowing the mappings in the first 
place.

> In that light I'm even hesitant to split Qt into QtCore and QtNetwork
> etc., or even KDE into kde.core and kde.ui, since those also don't map
> all that well to the existing usage and API.

Why is existing usage relevant?

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20050616/0f7bdb83/attachment.pgp