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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
