The following is not a joke:
- KDE4 needs java for best performance
more precise, soprano, used by nepomuk (semantic desktop thingie), has a sesame backend (java) and a redland backend (c++). According to upstream and others, the sesame backend is way faster than the redland backend.
In the soprano svn dir (and in the pristine tarball), there are a few jars put in precompiled:
- openrdf-sesame-2.1.2-onejar.jar
- slf4j-api-1.5.2.jar
- slf4j-simple-1.5.2.jar
This isn’t completely beautiful, but as they all are bsd licensed, it is at least legal.
But it isn’t good enough for debian, as we ship sources and build them. (I think I have heard at least fedora mumble something similar)
The two last jar files, the slf4j ones, are available packaged in debian in the libslf4j-java package. but openrdf-sesame is not available.
If some persons out there has java knowledge, debian packaging knowledge, preferably knowledge of debian java policy and some spare time, packaging openrdf-sesame would be much apprecaited.
And after that, getting the soprano sesame backend built is next goal.
Thanks in advance. applications welcome.
Just checked the source tar.gz, and packaging it will not be trivial at all… the source tar.gz also has stuff for the command line package, and has, except for those two slf4j jars, several other 3rd party jars:
activation-1.1.jar
aduna-appbase-core-3.1.jar
aduna-appbase-logging-api-3.1.jar
aduna-appbase-logging-file-3.1.jar
aduna-appbase-webapp-base-core-3.1.jar
aduna-commons-collections-2.0.jar
aduna-commons-concurrent-2.0.jar
aduna-commons-io-2.0.jar
aduna-commons-iteration-2.0.jar
aduna-commons-lang-2.0.jar
aduna-commons-net-2.0.jar
aduna-commons-platform-info-2.0.jar
aduna-commons-text-2.0.jar
aduna-commons-webapp-core-2.0.jar
aduna-commons-xml-2.0.jar
aopalliance-1.0.jar
asm-1.5.3.jar
cglib-2.1_3.jar
commons-cli-1.1.jar
commons-codec-1.2.jar
commons-dbcp-1.2.2.jar
commons-httpclient-3.1.jar
commons-pool-1.3.jar
jcl104-over-slf4j-1.5.0.jar
jstl-1.1.2.jar
logback-classic-0.9.9.jar
logback-core-0.9.9.jar
slf4j-api-1.5.0.jar
slf4j-jdk14-1.5.0.jar
spring-beans-2.5.1.jar
spring-context-2.5.1.jar
spring-context-support-2.5.1.jar
spring-core-2.5.1.jar
spring-web-2.5.1.jar
spring-webmvc-2.5.1.jar
standard-1.1.2.jar
Now, Aduna is the company behind OpenRDF (Sesame), and I am not sure if those jars are build from the source tar.gz too. The rest seems to be mostly Spring stuff…
Did you file a RFP with Debian yet?
Our plan in Fedora is to simply not ship Soprano’s Sesame2 backend, ever. (I’m willing to go even to the point of patching it out, and patching the Redland backend back in if it gets removed.) We don’t want the whole Java stack dragged in as a dependency of KDE.
IMHO the proper solution is to work with the Redland project to fix their performance problems: as it’s C++, it can definitely beat the Java-based Sesame2’s performance if it gets optimized properly.
My view (Debian Testing & KDE user) on the other hand is that I want whatever gives me the best performance, and I’m not bothered about a java dependency since its GPL now (or is that still a work in progress?) and I have it anyway for javascript websites. But my suggestion would be to somehow let the user choose their backend, if they want low dependencies they could get Redland, if they want performance they could get Sesame2.
@Kevin Kofler
Optimising Redland dose sound like the best solution overall if someone actually dose it. But shouldn’t the user get to choose witch backend they want?
Kevin Kofler said it all. There’s absolutely no reason why java could be better than C++ (if we leave apart personal preferences). So, in my humble opinion, it’s easier to fix the problem with the redland stuff, than to convince ALL the people to use a jvm, when it’s not really needed.
So, yes, it’s a joke: I don’t want 40mb more of ram occupied with a java machine. Of course, everyone should be able to compile whichever backend, but that does not excuse the primal fact: java should never be a default engine (also my humble opinion).
Regards.
@Wonderland: Re letting the user choose: In Fedora, we would be OK with building an optional separate soprano-sesame2 subpackage (which would not be automatically dragged in as a dependency of KDE), but only if it can be built entirely from source, with zero binary JARs. Including binary JARs is a violation of the Fedora packaging guidelines, so we can’t do that. And the situation in Debian is very similar, as including binary JARs also against Debian policies (as pusling explained in the blog entry).
Thanks for clearing that up, btw you can get sources: debian has a source package for libslf4j-java at http://packages.debian.org/source/lenny/libslf4j-java witch pusling says contains two of the jars in question, and since this blog was asking for help packageing the third jar, I’d guess sources can be found for that too :)
“I’m not bothered about a java dependency since its GPL now (or is that still a work in progress?) and I have it anyway for javascript websites.”
@Wonderland: Javascript is completely different from Java. It is poorly named, and in fact they have nothing to do with each other. Qt has its own implementation of Javascript, so does Firefox.
@ Rest of World: There is no way Java could be faster than C++! That just…
… <head explodes>
(Forgot that angle brackets get swallowed by WordPress.)
While I can perfectly understand why you want no java dependency, it is not that easy. In theory redland has potential for being faster than sesame2 but in practice we would have to reimplement their whole query engine. It is simply not good enough. So here, it is not a question of programming language but a question of good algorithms. When choosing sesame2 I was not happy but implementing my own RDF database (or reimplementing important parts of an existing one) was not an option. I would have never gotten anywhere.
So it would be great to have sesame2 packaged for now and see it as a temporary solution, hoping that redland’s query engine will improve soon (the plans are there). Using Nepomuk with redland now is a pain.
I’d support Kevin here. If there is a Java dependency, then it should not be included in the default install in any distribution. Make it optional is, sure. The standard KDE should _never_ depend on Java (or Mono, or whatevever other stuff). This is very important if you want to install KDE on other devices with less power (Example: There’s a port for KDE on the Nokia Internet Tablets. No Java there).
I’d even go that radical and say if this Redland C++ doesn’t do it right, then don’t include soprano and ultimatively nepomuk for any standard install.
@Sebastian Trüg: packaging seems imposible by the reason that Pusling and Kevin had already stated.
Now, from the user POV (or you can call it “my own point of view”), I do _not_ want a JVM running in my machine, much less for KDE. I totally agree with dukat here: if Redland C++ doesn’t do it right, then don’t include soprano or nepomuk for any standard install.
I’m a Java Developer by trade and saw your request. I have only messed around with building packages as a hobby. Packaging is not impossible. The way I did it might be unacceptable though.
Here are the source files:
http://www.centraltangle.com/open-rdf-sesame/open-rdf-sesame-java_2.1.3-1.tar.gz
http://www.centraltangle.com/open-rdf-sesame/open-rdf-sesame-java_2.1.3-1.dsc
I had to use maven2 to build the thing. There’s really no way to build just using ant., like most of the other java packages. I didn’t have any luck running dpkg-buildpackage with fakeroot either, but I’ve had similar problems with other packages.