[Libreoffice] Getting started with Java development for LO

[Peter Jentsch]

Hi Thorsten, 

I share your assumption that a Java API should feel native to Java
developers, but I still think any enhancement should at some point map
to the UNO API. I like the approach the odftoolkit took: they are
creating a fine grained low level API that's very close to the domain
model. And then they're defining a layer on top of that which is a lot
more coarse  grained an encapsulates a lot of the complex or just
complicated low level stuff. Making the Java UNO language binding more
comfortable to work with should IMHO also work on two levels:

First:  
- a lot of UNO interfaces and services have very close Java relatives
(for two completely unrelated examples look at
com.sun.star.awt.KeyEvent/java.awt.KeyEvent and
com.sun.star.beans.PropertyVetoException/java.beans.PropertyVetoException). 
- UNO turns the concept of checked/unchecked exceptions upside down in a
lot of places: com.sun.star.lang.IllegalArgumentException is a checked
exception, for example. If I get the basic principle of
checked/unchecked in Java right, checked exceptions are for resource
errors, while unchecked exceptions are for potential programming
problems). 
- queryInterface makes UNO Java code unreadable. That is the problem the
soa project tried to solve. Unfortunately sao is based on code
generation but the code generator itself is not part of the open sourced
code (if the original sao author reads this: please, give set the code
generator free ;-)

All of these issues could (and IMHO) should addressed while still
keeping the basic assumption that the language binding maps to the core
UNO API (the design of which might be questionable in a lot of places,
too, but that's a different matter). 

Secondly, and mostly independent of the above, I also agree it would be
desirable to have coarse grained Java API for UNO in place, that
provides for more productivity in day-to-day tasks, like simply starting
the office application, loading a document from a file and looping over
the fields in that document or inserting an image into the document. 

What I like about this 2-level approach is that it avoids the risk of
replacing the vast UNO API with something that is just broken in a
different way, and seperates the task of improving the UNO API and
component model, which is relevant for all language bindings, even the C
++ binding, from creating a Java language binding that doesn't make you
frown all day. 

If this is the direction you're going to take, I'd very much like to
join the effort (though I'm not sure about just how much I'll be able to
contribute).

Last, but not least: there are several existing projects out there that
already tried to scratch that itch, some commercial, some open source.
The one's I've come across are: 

http://sao.sourceforge.net/ (already mentioned, looks like mostly
generated code, wrapps UNO services into java objects, code generator
not included)). 

http://sourceforge.net/projects/duo-wrapper/ (abandoned directly after
inception, LGPL)

http://www.riess.de/DE/index.php?ordner=center&uordner=3-X-Datenblaetter&datei=3-3-rad-p01-juw (commercial)

http://ubion.ion.ag/solutions/003officeintegrationeditor (LGPL, that one
provides Java Window integration for eclipse/swt based applications
using the swt/awt bridge, but they also provide some high level API to
UNO)

Regards, 

Peter

Am Donnerstag, den 27.01.2011, 14:38 +0100 schrieb Thorsten Guenther:
> Hi all,
> 
> I tried to make myself familiar with the java portions of LO but got 
> stuck and confused. Can someone give me pointers on some topics?
> 
> 1) I understood on this mailing-lists archive that it is intended to 
> have any Java portions replaced with something else to get rid of JRE 
> dependencies. I guess that an optional Java-API for writing extensions 
> to LO is not effected by this and should be maintained. Is this correct?
> 
> 2) ATM this Java API is an UNO implementation from the OOo UDK project, 
> right? From my first Impression this API is ... I fail to get the design 
> decisions driving it. :-) I took a look at the OOo website to see 
> whether there are efforts to improve the API. The page 
> http://wiki.services.openoffice.org/wiki/Uno/Efforts was changed last 
> time in December '06, I basically stopped there. Are there any existing 
> plans anywhere to come up with a decent, modern Java API to LO?
> 
> I would like to get involved in Java development for LO but want to 
> avoid scratching my head over obsolete code.
> 
> Thanks and regards
> Thorsten Guenther
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>