[Libreoffice] Getting started with Java development for LO
thorsten.guenther at aposso.de
Thu Jan 27 07:39:14 PST 2011
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
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
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?
More information about the LibreOffice