LibreOffice 7.0 Released As The Open-Source, Vulkan-Accelerated Office Suite

[skeevy420]

Well.
Libre Office arrived on my desktop with a proper GPU (NVidia 1060) from Flatpak.
And i am sad to say that transitions in Impress still do not work on Linux.

That sucks.

[caligula]

Now, if you want to talk problems, the real one is most apps are not actually packaged for Linux (in a deb/rpm/whatever format). Developers just distribute a compiled form because that runs everywhere. Omit to add a JRE and you're deluding yourself thinking with just one package you've now covered all operating systems.

For simple programs that's a reasonable assumption. Java packages are able store resources and resource bundles, and know how to launch the application. You just need to depend on a generic JRE package and launch with "$JAVA_HOME/bin/java -jar mypackage.jar $*". Many simple tools work this way.

[Veto]

Java apps are supposed to do the same: bundle a working JRE.

That is apparently a new feature of the language, and most applications don't. To quote from LibreOffice homepage: "For certain features of the software - but not most - Java is required. Java is notably required for Base.".

Java does not break backwards compatibility.
The only time they did such a thing was Java9....

Hehe. "Java does not... The only time they did..."
Also this is simply wrong. https://www.oracle.com/java/technologies/javase/compatibility.html#incompatibilities

Everything written since Java9 will work with whatever comes for a while.

Let us just see about that... (Also it seems you strongly equate Java with OpenJDK)

[starshipeleven]

Well, you've lost the bigger picture here. The argument was the LO somehow sucks because of Java. I only showed Java is not a technical impediment.

You only showed that it's not certain, but likely that LO somehow sucks because of java.

Java makes it pretty hard to shoot yourself in the foot (handles most of the OS specifics, takes care of memory allocation for you)

And adds its own new ways of shooting yourself in the foot

[bug77]

That is apparently a new feature of the language, and most applications don't. To quote from LibreOffice homepage: "For certain features of the software - but not most - Java is required. Java is notably required for Base.".

Not sure what your point is.
Ubuntu: https://packages.ubuntu.com/focal/libreoffice <- requires Java will work with anything from 8 to 11
Arch: https://www.archlinux.org/packages/e...eoffice-fresh/ <- requires Java will work with anything from 8 to 11
Install it from the official repo and you're good. Really no different from any other app.

Hehe. "Java does not... The only time they did..."

Like I said, there was no way to hide private APIs, now there is. This is not breaking backwards compatibility.

Also this is simply wrong. https://www.oracle.com/java/technologies/javase/compatibility.html#incompatibilities

Oh my, the debug interface was replaced by a better one. That will break your app in so many ways

Let us just see about that... (Also it seems you strongly equate Java with OpenJDK)

What else should I equate it to? OpenJDK is the reference implementation. Almost everything else is just OpenJDK + additional (development or monitoring) tools on top.

[Veto]

You are simply wrong and continously downplaying the issues lots of users have experienced (and continue to do) with Java. However, this can apparently go on for ever... Bye!

[bug77]

You are simply wrong and continously downplaying the issues lots of users have experienced (and continue to do) with Java. However, this can apparently go on for ever... Bye!

I wasn't trying to downplay anything. I've posted before that a speedier adoption of Java's module system and AoT compilation are essential for its future.
It's just that nothing you have described is a Java-specific problem. It's a packaging problem. You'd have the same problems if you used .Net, Python... hell, you'd have the same problem if the whole damn thing was written in C and not linked correctly to all of its dependencies.
But we can stop here, it's not like we'll fix the world if we go on.

[krell]

I wasn't trying to downplay anything. I've posted before that a speedier adoption of Java's module system and AoT compilation are essential for its future.
It's just that nothing you have described is a Java-specific problem. It's a packaging problem. You'd have the same problems if you used .Net, Python... hell, you'd have the same problem if the whole damn thing was written in C and not linked correctly to all of its dependencies.
But we can stop here, it's not like we'll fix the world if we go on.

What i described is clearly a java problem. Jin simply does not work on openjdk11 which is the default version now included in Ubuntu and Debian. We know this cause people on the freechess server investigated and found that they could get jin to work by commenting out some class definitions from the jin source code(Though sound would still not work). It only supports java up to java version 8

There are also packaging problems such as requiring accessibility to be true which is something that is controlled by /etc/java.conf or something.
In contrast consider the old hand Nvi editor a linux/unix clone of the original vi written in C. It was last maintained about 20 years ago and guess what? It still compiles and runs without problems now.

[bug77]

What i described is clearly a java problem. Jin simply does not work on openjdk11 which is the default version now included in Ubuntu and Debian. We know this cause people on the freechess server investigated and found that they could get jin to work by commenting out some class definitions from the jin source code(Though sound would still not work). It only supports java up to java version 8

Have you read anything I have wrote so far? Java 9 came with a way to block access to private APIs, APIs that were always documented as unsafe to use.

There are also packaging problems such as requiring accessibility to be true which is something that is controlled by /etc/java.conf or something.
In contrast consider the old hand Nvi editor a linux/unix clone of the original vi written in C. It was last maintained about 20 years ago and guess what? It still compiles and runs without problems now.

Yes, that one works a treat:

cc -c -O -I. -I./../include -I./../regex -I./../db/include -I./../curses ../ex/ex_script.c
../ex/ex_script.c:27:10: fatal error: sys/stropts.h: No such file or directory
27 | #include <sys/stropts.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:335: ex_script.o] Error 1

C/C++ programs will exhibit the exact problem you mentioned if you don't provide the proper .so files (unless fully statically linked, which is rare).

[caligula]

Jin simply does not work on openjdk11 which is the default version now included in Ubuntu and Debian. We know this cause people on the freechess server investigated and found that they could get jin to work by commenting out some class definitions from the jin source code(Though sound would still not work). It only supports java up to java version 8

Take a look at this https://aur.archlinux.org/packages/jin/
They don't have any patches and it works with JDK5 - JDK11. If Debian has some packaging issue, it doesn't mean everyone has.