Re: [Libreoffice] Rationale for replacing Java with anything but c++ (was Re: web based libre office)

Am 28.01.2011 11:17, schrieb Michael Meeks:
> > could you please give me an idea why it would be useful to replace a
> > language alien to the core with another alien ?
>       Well python is not alien, since we ship a tiny (~1.7Mb) python run-time
> with every copy of LibreOffice we ship; ie. it is more built-in than
> Java which is (sadly) not ubiquitous, and 10x larger.
>
>       Incidentally, the side effect of not having Java around, or worse
> having a broken / mis-detected Java on an install is a slew of annoying
> dialogs when you start LibreOffice from the various extensions that want
> it; eg. five in a row of the form:
>
>       "Can I annoy you right now ?! [yes!]"
>
>       ;-) a terrible user experience. I'd like to loose that: indeed working
> on that would help reduce the need to prune Java stuff. The other option
> of shipping a vast chunk of cruft we don't need to bundle, and use
> almost none of is less attractive. Furthermore, Java has this unpleasant
> GC that complicates debugging by hooking various signals, and has in the
> past caused all manner of problems: eg. leaving invalid guard pages
> around on the stack causing apparently un-related crashes later, and so
> on. ie. I would really like to see Java relegated to a nice-but-optional
> thing that in practise is not on the hot path for most people.
...
> > If that's not the case... whats the problem with Java? Just the
> > "is a appropriate JRE / JDK installed" issue?. Sorry, perhaps
> > a noob question
>       Not at all - a good question :-) I appreciate if your mission is to
> drive Java deployment everywhere then perhaps the answer is not one that
> everyone will like. Perhaps the best thing to do for Java is to try to
> work on the C++ code paths, and error notification code for cases where
> it is not present, particularly on Windows.
Well, sadly I dont know a thing about the technical issues embedding a
jvm in an c application. Perhaps some of the user experience (apart from
download size) could be solved by shipping a "private" JVM with LO, but
this will have some legal issues to take care about.
So, since me looks like a lone java cowboy in friendly c land here (some
pythons sneaking around :-) I will just care about a scope that I can
handle:

I would like to provide a Java-API for remote controlling LO. That is
what can be done today with the UNO API. So the new API should be
implemented as wrapper, hiding as much UNO'isms as possible, presumably
for the cost of reduced functionality. Goal is to provide a friendly
looking tool for Java (or any JVM-Language) developers who want to
automate Document creation / manipulation with LO.

I hope this will get some more Java crowd attracted while the embedded
Java stuff can be removed. Assuming that the IDL / UNO / Java class
generation parts are there to stay..

If this this is of interest for the LO-community I would like to write
up some thoughts on the Wiki at the appropriate place. Any hint where
this would be?

Thanks
Thorsten Guenther