[Libreoffice] Getting started with Java development for LO

[Michael Meeks]

Hi Thorsten,

On Thu, 2011-01-27 at 14:38 +0100, Thorsten Guenther wrote:
> 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?

	Sure ! :-)

> 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?

	Of course, it's great to have Java around for extensions, and we'll be
keeping that valuable functionality. Having said that - if you want to
write an extension that you think would be widely useful - I would tend
to want to encoruage people to do that in C++, and have it integrated
with the core: reduces maintenance, makes deployment easy, and helps
consistency.

> 2) ATM this Java API is an UNO implementation from the OOo UDK project, 
> right? From my first Impression this API is ...

	unutterably terrible ? it strikes a perfect balance between not really
suiting the nastiness you need for thread-safety, while not meeting
anyone's need for usability ;-)

>  I fail to get the design decisions driving it. :-) 

	Hah - it is part of the UNO religion: to an UNO lover, any problem
looks like an opportunity to use UNO; if you read $ info m4, the last
paragraph of the introduction - you get a good analogy for this.

> Are there any existing plans anywhere to come up with a decent,
> modern Java API to LO?

	Well; there is a rather more usable API - which is that used by the VBA
stuff - although that is rather Microsoft-ish, which has several
drawbacks - and focused on compatibility rather than exposing all the
features.

> I would like to get involved in Java development for LO but want to 
> avoid scratching my head over obsolete code.

	Sure - well; at least in theory UNO provides a beautiful way to do
bindings. The reality however is hugely different - interface
introspection destroys intelligent API auto-completion, over-use of
generic interfaces and anys makes semantics hard to understand, and
documenting interfaces rather than objects makes things hard to grok.

	It is hard to know how to escape that ;-) the VBA approach - of
(substantially), monolithic interfaces per object with type
introspection might work better, but ...

	Do you actually want to write an extension then ? or just make Java
easier to use with LibreOffice ?

	Thanks,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot