Slashdot Mirror

For the last ten years, I've been developing Taskjitsu, an open source professional services automation system that tracks time sheets and tasks. It is freely available, GPL-licensed, and commercially supported by PKR Internet.

Taskjitsu is at its core a Java web application, layered on top of Tomcat and PostgreSQL. It runs on Windows, Linux, and any other system that can run Java 1.4. We have RPMs available that work with Red Hat Application Server 1.0 and other JPackage 1.6-derived systems.

I wish all these Java libraries worked like the way CPAN does.

Do you mean you wish Java libraries worked like CPAN, in the way Maven and its automatic library repository works or in the way the JPackage repository works?

Since SWT requires a native component, you can't really install it as an addon to the existing JRE. This means every SWT application requires its own install of the SWT.

Unfortunately, the Sun Java runtime uses an incredibly ass-backwards packaging scheme, so there's no good way for packagers to know exactly where the JRE's directory (and hence its lib/ext directory) is. On the Linux side of things, JPackage is going a long way towards cleaning this up -- so distros that use JPackage actually do package SWT as a shared library that all SWT apps use in common. AFAIK, there's no movement on the Windows side of things to fix this.

I just installed Tomcat from JPackage on Fedora and it was painful because Sun makes it difficult to automate the installation of the basic Java foundation. I have to click through a license to download it, then click through it again to unpack it, then assemble an RPM, then install the RPM. And I have to repeat this for multiple packages (eg. Javamail) before I have enough that I can let the rest of the open source packages from JPackage download and install on top without further interaction.

Then Sun fails to structure its Java to fit the Linux Standard Base (LSB) Filesystem Hierarchy Standard (FHS) so JPackage must provide an adapter package that symlinks all the Sun files to the correct locations.

I just installed Tomcat from JPackage on Fedora and it was painful because Sun makes it difficult to automate the installation of the basic Java foundation. I have to click through a license to download it, then click through it again to unpack it, then assemble an RPM, then install the RPM. And I have to repeat this for multiple packages (eg. Javamail) before I have enough that I can let the rest of the open source packages from JPackage download and install on top without further interaction.

Then Sun fails to structure its Java to fit the Linux Standard Base (LSB) Filesystem Hierarchy Standard (FHS) so JPackage must provide an adapter package that symlinks all the Sun files to the correct locations.

For example, there's no other platform that has as many high quality, cross platform database drivers

And for that matter, Java has quite a few free database engines (HSQL, McKoi, Derby (Cloudscape, etc.)

At the end of the day, there simply isn't any other solution that's as well supported and ubiquitous as Java

it'd be even better if they were able to distributed the files in RPM and DPKG formats. Once you've committed to a package based system it hurts to install non-packaged stuff. That's one of the reasons why JPackage is so nice.

Then, they should work to standardize on http://www.autopackage.org/ [autopackage.org], or something very similar to it.

JPackage perhaps? :-)

There is also a popular request for enhancement hereurging sun to make the Java RPM play better in Linux, i.e. respecting the filesystem standards for where to place documentation etc.

I doubt that GCJ is going to take over on Linux though. Not that they aren't doing FANTASTIC work, but there is still lots of catching up to do and Java is a moving target.

As I found out the hard way over this past weekend, they left out all the java and java related rpms that FC2 had.

Try taking a look at JPackage which has a far more comprehensive collection of Java packages.

The problem was these clashed horribly with older Fedora Core releases that shipped some incompatible Java packages, but 3 should be the start of it working better.

Ever tried installing Java and Java programs?

Yes, I added jpackage.org to my sources.list and ran "apt-get install ant struts tomcat5" and got everything I needed.

As a hardcore Ruby lover, I've been unhappy that I can't use Ruby with the vast libraries available for Perl and other established libraries.

But this groovy thing looks like a really nice smalltalk-esque language that hooks right into Java, enough to satisfy both sides of my brain.

This is cool and I can benefit from this *right now* in my work. Forget Parrot or Perl 666 (heh).

How come I never heard of this? And why doesn't jpackage have it?

JPackage has rpms for lots of Java apps.

There already is a good IDE for Java: Eclipse. And it's a simple matter to have two jdk's installed. Eclipse has a drop-down list for you to choose which one you want to use. So a Linux distribution could include Eclipse and Open Source jdk, and if it's not suiting my needs, I can go out and get proprietary jdk, install it alongside OS jdk, and toggle between them if I want. Are you listening Mandrake/SuSE/Fedora? I want a jpackage section of your install wizards!

For the most part jars are put in /usr/share/java. Links to specifically versioned jars are put there too.

i.e.

$ ls /usr/share/java/jdom* -lh
-rw-r--r-- 1 root root 123K Mar 27 2003 /usr/share/java/jdom-1.0.jar
lrwxrwxrwx 1 root root 12 Oct 31 15:47 /usr/share/java/jdom.jar -> jdom-1.0.jar

For complete packaging guidelines, see their policy.

I've never used Gentoo or java-config, but JPackage provides similar sounding scripts: build-classpath, build-classpath-directory, and build-jar-repository.

If you have to upgrade and you're running Java on a Linux system that also runs RPM, why not head over to JPackage and download the spec for the 1.4.2_03 SDK? It would be a great opportunity to run an LSB compliant Java installation and support a fantastic open source project.

If you guys are so up in your panties about this move, go elsewhere for support. You can get updates elsewhere. I've successfully been maintaining servers in the 30 or 40 just using apt-get and kickstart -- for free.

Get started here:

Freshrpms.net
DAG RPMS
ATrpms
newrpms
KDE For Redhat/Fedora
JPackage
CCRMA (Karma)
Gstreamer
Kernel 2.6.0-test

And if you want up2date style GUI, get synaptic from ATrpms.

Anyone know any good/quick IDEs for Java?

jEdit

Get a RPM from the JPackage project.

Bonus: All the images in the above galleries are Open Source, unless otherwise stated! (Quite literally, because SVG files are like "source code" for a vector image.)

As for SVG creating and editing software, apart from the new dSVG software announced earlier today on Slashdot, we have:

• Apache Batik for all you Java people. This is a fairly mature library (I believe it's based off the CSIRO library), plus sample apps like a viewer, a rasteriser (i.e. convert to gif, jpeg, etc.), a font converter, and a pretty-printer. Quotage: "With Batik, you can manipulate SVG documents anywhere Java is available. You can also use the various Batik modules to generate, manipulate, transcode and search SVG images in your applications or applets." Batik, according to its test suite, supports all of the static SVG specification (i.e. static images) and some of the dynamic specification (i.e. animations and scripting).

  (Get your easy installable RPMs for Batik, and many other Java projects, at jpackage - but good luck finding a download link that works! Batik 1.5 hadn't propagated to all the Sourceforge mirrors when I tried it last night - so try all the US mirrors, it will be on at least one of them. Also, because of the numerous dependencies, it's recommended to use a smart package manager that can automatically resolve dependencies, like apt-get or urpmi.)

• Sodipodi, [screenshots] a GNOME SVG drawing app, currently at version 0.32. It hosts the open source SVG image gallery linked to above.

• For more, including KDE/Konq support for SVG, see this Wiki page

Each application that wants to use Java recommends you install their bundled version of Java

This is Sun's fault. The folks at jpackage have been trying for quite some time to create freely distributable RPMs of JREs and SDKs. THe technical issues are surmountable, but Sun won't let you distribute a JRE unless it's bundled with a application, for the specific purpose of being used with that app and no other.

This is a legal issue entirely of Sun's making.

WebGraph is a framework to study the web graph. It provides simple ways to manage very large graphs, exploiting modern compression techniques. More precisely, it is currently made of:

1. A set of flat codes, called codes, which are particularly suitable for storing web graphs (or, in general, integers with power-law distribution in a certain exponent range). The fact that these codes work well can be easily tested empirically, but we also try to provide a detailed mathematical analysis.
2. Algorithms for compressing web graphs that exploit referentiation ( la LINK), intervalisation and codes to provide a high compression ratio: for instance, the WebBase graph (2001 crawl) is compressed at 3.08 bits per link, and a snapshot of about 18,500,000 pages of the .uk domain gathered by UbiCrawler is compressed at 2.22 bits per link (the corresponding figures for the transposed graphs are 2.89 bits per link and 1.98 bits per link). The algorithms are controlled by several parameters, which provide different tradeoffs between access speed and compression ratio.
3. Algorithms for accessing a compressed graph without actually decompressing it, using lazy techniques that delay the decompression until it is actually necessary.
4. A complete, documented implementation of the algorithms above in Java, contained in the package it.unimi.dsi.webgraph. Besides a clearly defined API, the package contains several classes that allow to modify (e.g., transpose) or recompress a graph, so to experiment with various settings. The package relies on fastutil for a type-specific, high-performance collections framework, on MG4J for bit-level I/O, on the COLT distribution for ready-to-use, efficient algorithms and on GNU getopt for line-command parsing.
5. Data sets for very large graph (e.g., a billion of links). These are either gathered from public sources (such as WebBase), or produced by UbiCrawler.

In the end, with WebGraph you can access and analyse a very large web graph, even on a PC with as little as 256 Mbytes of RAM. Using WebGraph is as easy as installing a few jar files and downloading a data set. This makes studying phenomena such as PageRank, distribution of graph properties of the web graph, etc. very easy.

You are welcome to use and improve WebGraph! Installation

You just have to install the .jar file coming with the distribution, and download the jars WebGraph depends upon (i.e., fastutil, MG4J, COLT and GNU getopt). You may find useful to refer to the JPackage Project if you own an RPM-based distribution. In the same vein of the packages above, WebGraph is also distributed as a Jpackage-like RPM.

WebGraph is a framework to study the web graph. It provides simple ways to manage very large graphs, exploiting modern compression techniques. More precisely, it is currently made of:

1. A set of flat codes, called codes, which are particularly suitable for storing web graphs (or, in general, integers with power-law distribution in a certain exponent range). The fact that these codes work well can be easily tested empirically, but we also try to provide a detailed mathematical analysis.
2. Algorithms for compressing web graphs that exploit referentiation ( la LINK), intervalisation and codes to provide a high compression ratio: for instance, the WebBase graph (2001 crawl) is compressed at 3.08 bits per link, and a snapshot of about 18,500,000 pages of the .uk domain gathered by UbiCrawler is compressed at 2.22 bits per link (the corresponding figures for the transposed graphs are 2.89 bits per link and 1.98 bits per link). The algorithms are controlled by several parameters, which provide different tradeoffs between access speed and compression ratio.
3. Algorithms for accessing a compressed graph without actually decompressing it, using lazy techniques that delay the decompression until it is actually necessary.
4. A complete, documented implementation of the algorithms above in Java, contained in the package it.unimi.dsi.webgraph. Besides a clearly defined API, the package contains several classes that allow to modify (e.g., transpose) or recompress a graph, so to experiment with various settings. The package relies on fastutil for a type-specific, high-performance collections framework, on MG4J for bit-level I/O, on the COLT distribution for ready-to-use, efficient algorithms and on GNU getopt for line-command parsing.
5. Data sets for very large graph (e.g., a billion of links). These are either gathered from public sources (such as WebBase), or produced by UbiCrawler.

In the end, with WebGraph you can access and analyse a very large web graph, even on a PC with as little as 256 Mbytes of RAM. Using WebGraph is as easy as installing a few jar files and downloading a data set. This makes studying phenomena such as PageRank, distribution of graph properties of the web graph, etc. very easy.

You are welcome to use and improve WebGraph! Installation

You just have to install the .jar file coming with the distribution, and download the jars WebGraph depends upon (i.e., fastutil, MG4J, COLT and GNU getopt). You may find useful to refer to the JPackage Project if you own an RPM-based distribution. In the same vein of the packages above, WebGraph is also distributed as a Jpackage-like RPM.

Yes, and hopefully they'll follow some sane packaging standards like these found here

Yes, and hopefully they'll follow some sane packaging standards like these found here