Re: [Libreoffice] defaulting to --without-java ... (?)

Hi Sebastian, *,

On Fri, Dec 3, 2010 at 8:35 AM, Sebastian Spaeth <Sebastian@sspaeth.de> wrote:
> On Thu, 2 Dec 2010 20:31:02 +0100, Christian Lohmaier wrote:
> > On Thu, Dec 2, 2010 at 8:22 PM, Sebastian Spaeth wrote:
> > > On Thu, 2 Dec 2010 17:45:17 +0100, Christian Lohmaier wrote:
> > > > > >        would anyone scream if we defaulted configure to --without-java ?
> > > >
> > > > I would.
> > > I would not.
> > I hope not for the wrong reasons.
>
> I hope these are not wrong reasons:

"Distro XY has a weired java-setup that makes it hard to compile with
java" would be a "wrong" reason from my POV.
As then instead configure has to be fixed/enhanced to work with that distro.

> - Because I dislike to rely on runtimes that we cannot redistribute on
>  all platforms due to legal restrictions/uncertainties (or can we
>  include the JRE on Windows now?)

OK - so you're for replacing java bits with c++ stuff. OK, nothing
against replacing stuff. But turning off java before that replacement
is available?

Besides I don't think that LO should include the JRE in the installer
in either case. I dislike that OOo includes the installer (and when I
participated in QA of localized packages, I always only used the
non-JRE variants).

> - Because I dislike to have to install a 65MB runtime on top of a 370MB
>  application, to get an html export filter? (OK, breaking Base is a
>  bummer). With ant, Java comes at 81MB here.

You're mixing developer's installation and user's installation. A user
doesn't need ant, and doesn't need a JDK. A user JRE download ain't 65
MB, but rather less than 20.

And chances are that the user already has a JRE installed. Any Mac
user already has Java, many windows users probably have it installed
as well already.

> - Because I dislike to add yet another build system (ant) on top of
>  dmake and gmake?

Well - that is orthogonal to disable java - it just happens that ant
is the build-system of choice for java projects created in IDEs like
netbeans or eclipse - and the java extensions in the sources are
basically dumps of the corresponding netbeans project. Similar for the
external tools that are built as part of OOo - you surely don't want
to rewrite their buildsystem just to save the developer installing one
package.
To build LO you install tons of devel packages, but ant is too much?

> - Because I think that we should include and focus on as few runtimes as
>  possible? That can be starbasic, vba, python, java, lua or whatnot,
>  but not many of them.

That is the first one - replacing the stuff currently relying on java
with non-java implementations.

> - Because I dislike a runtime whose patent grant explicitely does not
>  allow to implement only a subset of the language, preventing us to just
>  ship the parts we need? The portable people will not be happy.

We had that "I don't like java" point before. This is just
reiterating. And again - mixing building with the distribution. LO
should never ever ship the JRE along with it. Shipping parts of it
would be even worse.
Why would anyone want a seperate JRE shipped with the office? Just to
waste diskspace and to have two seperate runtimes to keep up to date?
No thanks.

> - Because I dislike a runtime whose past and future development is very
>  tightly connected to the wills and wishes of a single commercial
>  entity? LibO of all applications should know how that helps speedy
>  development and wide-ranging outside contributions

"I dislike Java" again - And there's openJDK.

> - Because disabling by default will increase the Leidensdruck to
>  actually implement features that people want in another language.

No - I really doubt that. As most developers are "just" that -
developers. Only few actually use LO to an extent a regular downloader
would do. Maybe Impress for presentations, but apart from that they
prefer their emacs or vim or whatever :-)

I see it the opposite way the "Leidensdruck" is created when enabling
java, as that (according to some posts here causes the build to take
longer (yes, java is not covered by ccache, thus if it would be c++,
then it would be faster), and even faster when running (what I doubt,
unless you use stuff that is only available in java, thus OOo loads
java, but then it cannot run "faster", since without that
functionality wouldn't run at all))

> - Being asked whether I would scream if it were disabled in developer
>  builds, I wouldn't scream as I don't use any of the functionality that
>  Java provides to LibO. Fair enough?

Sure - that's your opinion, but I don't share it.

> You might agree with some of the above points or not, and you might give
> them a different weight than I do, but they are not wrong in my book.

Wrong always depends on what weight you give to those points, from
what perspective you look at it. I'm more biased towards the user, not
from the developer POV.

I hate pulseaudio for being forced on the user before userspace was
ready, I hate gnome-power-manger/devkit-power for not recognizing
battery status of my laptop, I hate new gdm for removal of
fast-user-switch applet, etc.
Those might be superior designs, technically superior to the previous
solutions, but for me just counts:
Stuff that worked without problems for years now is broken, less useful.

So I'm all for enabling stuff that relies on java, although some
people would wish it would be "native c++".
And I surely won't tell people not to touch it, but keep it as java,
as long as the replacement offers the same functionality.
Getting back to LO: What I surely don't want is what happened with OOo
and the mail-merge wizard (has nothing to do with java though). The
new wizard (lots of dialogs to click through, almost impossible to
only choose a selection of the available data) surely is far inferior
compared to the old one (database-beamer, drag fields into document,
select the datasets, run the merge).

If it ends up like that - working without java but sucks functionality
wise - then I'm definitely in favor of the java solution, even if it
requires the evil runtime.

ciao
Christian