Hi Thorsten, I share your assumption that a Java API should feel native to Java developers, but I still think any enhancement should at some point map to the UNO API. I like the approach the odftoolkit took: they are creating a fine grained low level API that's very close to the domain model. And then they're defining a layer on top of that which is a lot more coarse grained an encapsulates a lot of the complex or just complicated low level stuff. Making the Java UNO language binding more comfortable to work with should IMHO also work on two levels:
First: - a lot of UNO interfaces and services have very close Java relatives (for two completely unrelated examples look at com.sun.star.awt.KeyEvent/java.awt.KeyEvent and com.sun.star.beans.PropertyVetoException/java.beans.PropertyVetoException). - UNO turns the concept of checked/unchecked exceptions upside down in a lot of places: com.sun.star.lang.IllegalArgumentException is a checked exception, for example. If I get the basic principle of checked/unchecked in Java right, checked exceptions are for resource errors, while unchecked exceptions are for potential programming problems). - queryInterface makes UNO Java code unreadable. That is the problem the soa project tried to solve. Unfortunately sao is based on code generation but the code generator itself is not part of the open sourced code (if the original sao author reads this: please, give set the code generator free ;-) All of these issues could (and IMHO) should addressed while still keeping the basic assumption that the language binding maps to the core UNO API (the design of which might be questionable in a lot of places, too, but that's a different matter). Secondly, and mostly independent of the above, I also agree it would be desirable to have coarse grained Java API for UNO in place, that provides for more productivity in day-to-day tasks, like simply starting the office application, loading a document from a file and looping over the fields in that document or inserting an image into the document. What I like about this 2-level approach is that it avoids the risk of replacing the vast UNO API with something that is just broken in a different way, and seperates the task of improving the UNO API and component model, which is relevant for all language bindings, even the C ++ binding, from creating a Java language binding that doesn't make you frown all day. If this is the direction you're going to take, I'd very much like to join the effort (though I'm not sure about just how much I'll be able to contribute). Last, but not least: there are several existing projects out there that already tried to scratch that itch, some commercial, some open source. The one's I've come across are: http://sao.sourceforge.net/ (already mentioned, looks like mostly generated code, wrapps UNO services into java objects, code generator not included)). http://sourceforge.net/projects/duo-wrapper/ (abandoned directly after inception, LGPL) http://www.riess.de/DE/index.php?ordner=center&uordner=3-X-Datenblaetter&datei=3-3-rad-p01-juw (commercial) http://ubion.ion.ag/solutions/003officeintegrationeditor (LGPL, that one provides Java Window integration for eclipse/swt based applications using the swt/awt bridge, but they also provide some high level API to UNO) Regards, Peter Am Donnerstag, den 27.01.2011, 14:38 +0100 schrieb Thorsten Guenther: > Hi all, > > 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? > > 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? > > 2) ATM this Java API is an UNO implementation from the OOo UDK project, > right? From my first Impression this API is ... I fail to get the design > decisions driving it. :-) I took a look at the OOo website to see > whether there are efforts to improve the API. The page > http://wiki.services.openoffice.org/wiki/Uno/Efforts was changed last > time in December '06, I basically stopped there. Are there any existing > plans anywhere to come up with a decent, modern Java API to LO? > > I would like to get involved in Java development for LO but want to > avoid scratching my head over obsolete code. > > Thanks and regards > Thorsten Guenther > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
