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@novell.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.