[Libreoffice] Getting started with Java development for LO

Thorsten Guenther thorsten.guenther at aposso.de
Thu Jan 27 07:39:14 PST 2011


Hi MIchael,

Am 27.01.2011 15:50, schrieb Michael Meeks:
>
>> 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.
I'm a Java developer but I agree that generally only one language should 
be used to implement any given single product. I don't get the point in 
the whole language independence and remoting stuff UNO implements. So 
lets rip all Java out of LO's core-functionality and concentrate on a 
attractive Java-API for (private / corporate) extensions.

>> 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.
That's an reasonable design decision for me. A Java API should feel 
native to Java developers too. If someone needs each and every LO 
functionality he can resort to c++.
>> 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 ?
I would like to help making LO a useful and attractive tool for 
(corporate) Java developers. .net developers can create nice extensions 
with ms-office for their clients. Java developers should be attracted to 
LO for that.
Is there any one else interested in exploring a design for a new LO 
Java-API as a first step?

Regards
Thorsten Guenther


More information about the LibreOffice mailing list