Fedora Core 5 Wishlist

Here’s my categorized list of goals for Fedora Core 5.


  • GNU Crypto fix for Eclipse extssh support

    Casey Marshall has already committed a Diffie-Hellman JCE provider to GNU Classpath so this is just a matter of testing.

  • import all JAWT fixes

    All the necessary patches are already in GNU Classpath and libgcj.

  • Jessie merged into GNU Classpath
  • GNU Crypto core algorithms merged into GNU Classpath
  • gjdoc merged into GNU Classpath enabling …
  • an --enable-javadocs option to libgcj
  • make gcjx java-gcj-compat’s javac commands

    Not sure if this one is doable in time; I don’t mean full gcjx, just the bytecode-compiler portion in a standalone executable.

  • include Tritonus or some other sound implementation


  • ImageMagick backend for ImageIO
  • Graphics/Imaging refactoring for GTK 2.8 and Cairo
  • MegaMek packages in Fedora Extras

    This just involves a few AWT bug fixes now.

  • fix all 1.5 japi issues in java.awt.* packages
  • fix all 1.5 japi issues in javax.imageio.* packages


  • RHDB tools in Fedora Extras: Administrator, Visual Explain and Control Center.

    This will require updating these tools to support PostgreSQL 8.0.

  • Limewire in Fedora Extras

    It would be absolutely awesome to have this Swing app working on the free stack but I’m not sure it’s doable in the FC5 time frame. Would anyone like to undertake it?


  • Azureus in Fedora Extras

    Again, not sure if this is doable before FC5 but this would be awesome to have.


  • implement and test security features in GNU Classpath to allow running untrusted bytecode

    It’s very unlikely that this one will be finished before FC5 but I’d like to at least have started the implementation by then.

I’m hoping this list will inspire some volunteers, especially for the big apps and GNU Classpath’s security framework. Most of these items are very doable and will greatly improve the free JPackage stack on Fedora.

4 replies on “Fedora Core 5 Wishlist”

  1. Bear in mind that “all 1.5 japi issues” in anything at all is purely provisional at this point since japitools isn’t actually comparing the 1.5 language features. You could get to 0 japi errors even if serious incompatibilities still existed.

    But I have to say I’d love to see Tritonus make it into Classpath. You realize that would give us *no* packages at 0% (and only 4 packages below 90%) against 1.3 and only 2 packages at 0% against 1.4?

  2. Hi Thomas,
    Azureus needs fixes in the NIO interaction code. Currently our channel implementations are based upon the java.io streams (eek!). This makes supporting non-blocking IO overly complicated. IMHO it could not be that hard to rewrite the stuff using plain glibc routines.

    I plan to look at this in the next weeks.

  3. By all that is holy did you *really* mean that you want MegaMek in FC5?!? While I would truely celebrate to find any distro packaging MegaMek, and we’ve included several feature in the recently made a “stable” release to support just that, I am surprised, shocked, and not a little bit worried about overpromising to hear that someone thinks that any Free runtime is able to run the program.

    Goodness knows however that *YOU* of all people know what would be involved in getting it to render correctly, but I hadn’t heard anything in months (admitedly, because I’ve gotten way behind in reading the mailing lists), so I hadn’t thought that significant progress had been made. I must say that I am ecstatic that you believe that it is ready (or nearly ready) for inclusion. If there is anything that the MegaMek developers can do to help get the project ready to be included in Fedora, please leave a note on the MegaMek Open Discussion forum (http://sourceforge.net/forum/forum.php?forum_id=154579).

Comments are closed.