Call for participation: Free Java @ FOSDEM 2012
We are pleased to announce the Call for Participation in the FOSDEM 2012 Free Java DevRoom! This marks the 9th year that the Free Java DevRoom has been a part of FOSDEM. http://fosdem.org/2012/ Saturday 4th and Sunday 5th of February 2012 Brussels, Belgium The Free Java DevRoom has become unique in that it has attracted upstream, downstream, distrbutors and Free Software hackers together in one venue. Topics range from the deep technical to deep community. Join us for this year's theme: Free Java Momentum Check out our wiki for more details on the conference: http://wiki.debian.org/Java/DevJam/2012/Fosdem And join the freejava-devr...@lists.fosdem.org https://lists.fosdem.org/mailman/listinfo/freejava-devroom Please submit one (or more) 30 minute talk proposal(s) by the 30th of December 2011 to fos...@developer.classpath.org. A template for submitting a talk can be found at: http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation Please join us! --The Free Java DevRoom Organizing Committee Andrew Haley, Red Hat Dalibor Topic, Oracle Dr Andrew John Hughes, Red Hat Mark Wielaard, IcedTea Sylvestre Ledru, Debian Tom Marble, Informatique p.s. We had some nice media coverage last year... FLOSS Weekly 152: FOSDEM http://twit.tv/floss152 Linux Outlaws 191 - Special: FOSDEM Coverage http://old.linuxoutlaws.com/podcast/191 -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111211132058.gf7...@toonder.wildebeest.org
Free Java @ FOSDEM 2011 - Talk Schedule
Mark your calendars! Free Java @ Fosdem will be in less than 3 weeks. Saturday 5, Sunday 6 February 2011, Fosdem, Brussels, Belgium. Room AW1.125. We got a very good selection of very diverse talks, all around core java implementation issues, integration, community and the future of Free Java as platform. Full program, talk abstract and speakers bios at: http://wiki.debian.org/Java/DevJam/2011/Fosdem/TalkSchedule Saturday 13:00 - 13:10 Welcome to Java Sans Frontières Tom Marble 13:10 - 14:00 State of OpenJDK Mark Reinhold, Joe Darcy 14:00 - 14:30 IcedRobot, the GNUlization of Android David Fu, Mario Torre 14:30 - 15:00 break + group picture 15:00 - 15:20 Why Linux distributions hate Java Thierry Carrez 15:20 - 15:40 The Java Packaging Nightmare Torsten Werner 15:40 - 16:00 Guide to packaging for developers Stanislav Ochotnicky 16:00 - 16:25 break 16:25 - 16:30 What makes IcedTea tick? Mark Wielaard 16:30 - 17:00 What in the world is this 'IcedTea-Web' project? Deepak Bhole 17:00 - 17:30 The Free javaws Implementation in IcedTea Omair Majid 17:30 - 18:00 break 18:00 - 18:30 Lessons open sourcing Java taught me Simon Phipps 18:30 - 19:00 The Rise and Fall and Rise of Java Steve O'Grady evening LibreDinner Sunday 09:30 - 10:00 The Free Java Jigsaw Puzzle Tom Marble 10:00 - 10:30 The Modular Java Platform Mark Reinhold 10:30 - 11:15 Project Coin - Language Evolution in the Open Joe Darcy 11:15 - 11:30 break 11:30 - 12:00 Observing HotSpot with SystemTap Mark Wielaard 12:00 - 12:30 JamVM Gets a New Flavour: Porting JamVM to OpenJDK Robert Lougher 12:30 - 13:00 IndyDroid - JSR 292 on Android Rémi Forax 13:00 - 14:00 lunch and keysigning 14:00 - 14:30 Free Java - Reasons to be cheerful! Ben Evans, Martijn Verburg 14:30 - 15:00 PHP.reboot a dynamic language as fast as Java (almost!) Rémi Forax 15:00 - 15:30 Rhino and RingoJS - server-side JavaScript on the JVM Hannes Wallnöfer 15:30 - 16:00 break 16:00 - 16:30 AltosUI - Rocket Telemetry Ground Station Bdale Garbee 16:30 - 16:55 Low latency in Gervill and JavaSound Karl Helgason 16:55 - 17:00 Garbage Collection (wrap-up) Tom Marble Please join the freejava-devr...@lists.fosdem.org list for general discussion about the event. http://lists.fosdem.org/mailman/listinfo/freejava-devroom Hoping to see you all there, Andrew Haley GCJ Maintainer, GNU Classpath, IcedTea OpenJDK Developer. Andrew John Hughes IcedTea Maintainer, GNU Classpath Maintainer, OpenJDK GCJ Developer Christian Thalinger OpenJDK developer, former CACAO Maintainer Mark Wielaard GNU Classpath Maintainer, GCJ, IcedTea OpenJDK contributor. Tom Marble Java Libre hacker, Former OpenJDK Ambassador -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295258648.2998.25.ca...@springer.wildebeest.org
Re: What is openjdk equivalent of javaws.jar
On Mon, 2009-11-09 at 15:08 +0530, Onkar Shinde wrote: Hi, I am trying to package a software (sweethome3d) which uses some classes from javax.jnlp package. When I searched on javacio.us the results indicated that the classes I am looking for are part of javaws.jar. This file is currently available only in Sun JRE package in Debian. Can anyone help me locate the openjdk equivalent of javaws.jar from Sun JRE package? The particular class I am looking for is javax.jnlp.SingleInstanceListener. OpenJDK doesn't come with java webstart. Sun seems to prefer to keep this proprietary. But luckily the OpenJDK package in Debian is based on IcedTea (http://icedtea.classpath.org/) which comes with a free alternative implementation based on netx. You can find the classes in rt.jar (although based on what you say above maybe they should go in a separate jar file, if so, please file a bug report). Cheers, Mark -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: java bytecode / java runtime version mismatch
Hi Matthias, On Tue, 2008-10-28 at 09:25 +0100, Matthias Klose wrote: I filed bug reports for packages building with openjdk-6 or cacao-oj6, producing java bytecode for version 50, and which still depend on java-runtime5, or earlier (attached at the end). This package builds with openjdk-6 or cacao-oj6, which is not the default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac creates java bytecode for version 50, which cannot be used by older jvms. I thought all (free) runtimes accepted version 50 bytecode these days, even if they say they implement only java-runtime5. Is this a problem in practice? And if so against which runtimes? We might want to just fix those runtimes. Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java bytecode / java runtime version mismatch
On Tue, 2008-10-28 at 10:03 +0100, Matthias Klose wrote:
Mark Wielaard writes:
I thought all (free) runtimes accepted version 50 bytecode these days,
even if they say they implement only java-runtime5. Is this a problem in
practice? And if so against which runtimes? We might want to just fix
those runtimes.
problems were reported with at least sun-java5, which doesn't accept
openjdk-6 bytecode.
Bah, that seems to be a proprietary one we cannot fix :{ But if none of
the free ones have a problem then lets just migrate people to free
runtimes.
Cheers,
Mark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ImageJ: OpenJdk has problems with JPEGImageEncoder
On Tue, 2008-09-23 at 07:56 -0700, David Herron wrote: com.sun.image.codec.jpeg.JPEGImageEncoder - This is a private class, not a public class, and we've always maintained freedom to drop/change/modify private classes at any time. This was dropped. This issue is upstream in the openjdk project. On the OpenJDK 2d-dev mailing list (no URL unfortunately) this package was discussed in August and Chris Campbell said this:- The history (and fate) of those classes is documented here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962 There is an attempt to recreate the package in IcedTea through an imageio wrapper. It is not yet finished though. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=192 Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Get ready for Fosdem - Free Java Meeting
In just two weeks, 22 and 23 February, the Free Java Meeting will take place during Fosdem in Brussels, Belgium. There is a dynamic program with lots of (short) talks and space for discussions on the state of the various free java projects, mobile java, the VM and the Distro Rumble, the free java factory, cool stuff, freedom, compatibility, community and planning all the exciting stuff we are going to do together in the next year. So if you are interested in Debian-java, GNU Classpath, OpenJDK, JikesRVM, Fedora-java, IKVM.NET, JamVM, Jalimo, MobileEmbedded, Kaffe, Gentoo-java, IcedTea, JNode, MIDPath, FBToolkit, Brandweg, Duchess, IcePick, HotSpot, Zero, Ubuntu-java, GCJ and much, much more. Then please come and join us. More information on the program, who will be there and other activities at http://fosdem.org/2008/schedule/devroom/freejava and http://wiki.debian.org/Java/DevJam/2008/Fosdem Best of all, it is all free. You only have to pay the beer yourself *) Hope to see you all there! *) FOSDEM '08 is a free and non-commercial event organized by the community, for the community. Its goal is to provide Free Software and Open Source developers a place to meet. http://fosdem.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNU/Linux Java Policy and Packaging
On Sun, 2007-06-17 at 01:01 +0100, Paul Cager wrote: * How do you detect when a new version breaks the ABI? It seems quite complicated. Do you use a tool to compare the classes / method signatures, etc, or do you only bump the slot number if an application fails? There is Japitools http://sab39.netreach.com/japi/ which you would hope a library writer runs before releasing a new version. It gives a nice overview of public visible changes between 2 versions of a java library. Note that it only checks for binary compatibility, not source compatibility though. I don't know of any tools designed for source compatibility. Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun's OpenJDK in Debian?
On Sat, 2007-06-09 at 22:50 +0200, Michael Koch wrote: Is this the main blocker for accepting OpenJDK in Debian? Would it be possible to just omit the binary modules or to replace these with free implementations from other free projects? Yes, this is a big blocker for this. We are working on icedtea, a temporary fork of openjdk, which tries to replace the the closed source parts. This is mainly discussed on the openjdk mailing lists and on IRC. Since openjdk has so many lists, the one you are looking for is: http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev Or in gmane start with this thread: http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5 Only bootstraps on Fedora 7 for now, but we are making (very) slow progress to get things to build fully on Debian also. All help appreciated! Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Location of API docs
On Sun, 2007-01-14 at 01:12 +0100, Michael Koch wrote: On Sat, Jan 13, 2007 at 09:19:31PM +, Paul Cager wrote: Marcus Better wrote: Matthias Klose wrote: Assuming that the doc is installed in /usr/share/doc/libfoo-java/api, a reference to a class Bar should point to ../../libbar-java/api. Not yet sure how to find the location for this reference I seem to remember that javadoc can be given a command line parameter giving the location of the javadocs for a certain Java package? You can use the -link option to do this. It works very well with Sun's Javadoc, but I have not tried it with gjdoc. I can't remember the details, but it's integrated with ant's javadoc target. For Debian packages we need -linkoffline to link to the locally installed javadocs of dependant packages. I havent tried yet if one or both of these options work in gjdoc or not. They both work for gjdoc. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Location of API docs
Hi Matthias, On Thu, 2007-01-11 at 21:11 +0100, Matthias Klose wrote: The idea was to make the -doc packages depend on other -doc packages so that references to other packages can be resolved; unfortunately gjdoc doesn't support that yet. What would you need from gjdoc to support 'that'? Could you give an example, I am afraid I was unable to follow the discussion to see what is really needed here. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: jogl
Hi, On Sat, 2006-12-02 at 11:35 +0100, Petter Reinholdtsen wrote: And AFAIK some problems occur with the free-java stack. But I don't know the current status. A prebuilt version of jogl was used successfully with worldwind2d, classpath and jamvm more than 6 months ago, so I believe jogl should work just fine with the free java stack. See URL:http://gnu.wildebeest.org/diary/index.php?p=156 for a screen shot. Of course, something might have broke since then. :) And at least the image color handling should be fixed now. Apparently that bridge wasn't blue after all :) It is a good idea to try to make this work with the free stack. We will try to work with Sun on their OpenJDK effort. But one of the prominent pieces which they might not be able to release is the graphics rasterizer. So making sure things like WW2D works with GNU Classpath now will help us see whether or not we can plug in our graphics pipeline (based on cairo) when their code becomes available. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sun has an ombudsman
Hi, I saw the swift reaction on bug #276302: [Sun License for JavaCC] which has been an issue for years (upstream claims it is free software under a modern bsd license, but some files had additional restriction). Getting a real answer, an acknowledgment that this is a problem with regard to the DFSG and a solution to the problem makes it now possible to package this package for Debian main. So I send a Thanks! to some people at Sun for their handling of this issue. They reminded me that Sun has an ombudsman that is responsible for solving these kinds of issues the free software community might have with software Sun distributes. In the past a lot of people (me included) have been pretty skeptical about Sun's motives and their effectiveness with regard to understanding and handling community issues. But since their OpenJDK initiative, they have been engaging and interacting with the existing libre java communities (GNU Classpath, gcj, kaffe friends), acknowledging that cooperation is the way forward. They do seem genuine in their efforts cleaning ship with respect to their GPL Java initiative and java packages Sun creates on top of that. Because I know Simon Phipps, who coordinated a lot between the communities with respect to the launch of OpenJDK, is the person currently monitoring and handling [EMAIL PROTECTED], I would like to encourage people to email him whenever they spot things like the nuclear clause in packages from Sun which prevent them going into main. Even if those issues have been open for years without a clear path to a solution. Especially with regard to their java-packages Sun really is spring-cleaning now. So make the best of it! :) Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openjdk-compiler
Hi, On Mon, 2006-11-20 at 07:47 +0100, Ola Lundqvist wrote: On Sun, Nov 19, 2006 at 09:04:26PM +0100, Mark Wielaard wrote: We are not completely there yet though. Thanks a lot for that information. I'll try to dig further into this in order to make it buildable with things from only main. FYI. We got a little closer again. See: http://gnu.wildebeest.org/diary/index.php?p=172 Still patches and special branches of some things needed, but hopefully things are moving fast enough to get this into main soon. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: ITP: openjdk-compiler
Hi, On Tue, 2006-11-14 at 16:53 +0100, Ola Lundqvist wrote: On Tue, Nov 14, 2006 at 03:55:24PM +0100, Marcus Better wrote: I have now determined that it can build using itself as compiler (If I make a preliminary version bootstrapped with binary sun javac). Then it would have to go in non-free unfortunately. Can the bootstrap compiler be built with gcj instead? Bootstraping is perfectly ok for compilers and such. Many of the core packages in Debian can actually not be built without special handling in the beginning, and in many cases later on when binary formats are changed and so on. So that is not a problem. There are some efforts to get Sun javac to build and run with the existing free stack. See the GNU Classpath wiki: http://developer.classpath.org/mediation/ClasspathCurrentTopics And Andrew Hughes blog: http://blog.fuseyism.com/?p=18 We are not completely there yet though. Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JavaMail and JAF
On Thu, 2006-08-31 at 15:15 +0200, Marcus Better wrote: Matthias Klose wrote: what do you mean by out of the box? Sorry for being unclear. Can the classpathx versions work as drop-in replacements for the Sun packages? (JBoss contains jar files for JavaMail 1.3.1 and JAF 1.0.2. I intend to replace them with the ones from classpathx.) They really should. If you find issues doing that then please file bug reports. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backporting the classpath 0.92 changes from the gcc-4_1-rh-branch
Hi Matthias, On Sat, 2006-08-05 at 23:15 +0200, Matthias Klose wrote: Using the gcj/jc1 from the gcc-4_1-rh-branch to build the merged sources shows the same behaviour, so I assume that the problem is in the libjava/classpath merge, not in the gcc/java merge. Any help or suggestions are welcome. Currently finishing up the upstream 0.92 release, so we can have the formal backport. So I haven't yet to compile this myself. I am CCing Tom and Tom who might recognize this issue. Also make sure sources.am is up to date and the automake files are regenerated (see the libjava/HACKING file). My quick guess is that there is something wrong with either the sources or the build instructions of DateFormat.java. This file used to have a private override in libgcj, but since the latest merge it should use the upstream classpath version. Make sure that it is removed from libjava/java/text/DateFormat.java and that there is a new file libjava/classpath/java/text/DateFormat.java Similar for SimpleDateFormat.java. Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I use the apps running free Java???
Hoi, On Thu, 2006-01-26 at 09:49 +0100, Stephan Michels wrote: On 1/26/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote: Is it possible to run the following combination of applications on a Debian AMD64 Etch installation, using nothing but free software (I know it can using Sun's SDK, because that is what I am running now): - Java 1.5 We are planning to package classpath-generics. With Cacao or jamvm you are able to run most of the Java 1.5 stuff. - Swing client Not know the status of swing. We are making good progress. When something is developed against the GNU Classpath libraries it will likely work, but random swing code will probably still show some bugs against Free Swing. GNU Classpath Examples has some nice Free Swing Demos that show what works (is this packaged for Debian?) There is a Free Swing Test Apps page at: http://developer.classpath.org/mediation/FreeSwingTestApps And there will be a presentation on Free Swing by Roman Kennke at the GNU Classpath Friends meeting during Fosdem next month: http://www.gnu.org/software/classpath/events/fosdem06.html - JBoss 4.03SP1 or higher Don't know, will be difficult. Jonas, for example, seems to be able to run on a a free java stack. It is mostly a packaging nightmare from what I have seen. And knowing a couple of small workarounds. I did get JBoss up and running a while ago, but I haven't looked at it recently: http://gnu.wildebeest.org/diary/index.php?p=126 Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Can I use the apps running free Java???
Hi, On Thu, 2006-01-26 at 10:38 -0500, Lennart Sorensen wrote: On Thu, Jan 26, 2006 at 09:32:30AM +0100, Joost Kraaijeveld wrote: Is it possible to run the following combination of applications on a Debian AMD64 Etch installation, using nothing but free software (I know it can using Sun's SDK, because that is what I am running now): - Java 1.5 I am not aware of any free java implementation that matches java 1.5 yet. I know many doing 1.3, and I think a few might do 1.4 by now. Those based on GNU Classpath are close to full 1.4: http://developer.classpath.org/support/ (roadmap) And we are working on full 1.5 support. Some nice progress can be seen: http://gnu.wildebeest.org/diary/index.php?p=139 If that is possible, are there (pointers to) any known problems? Well don't know. I know java is best avoided. :) Yes :) But please do try to help out with the free replacements for those that did fell into the proprietary java trap! Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: kaffe transition freemind
Hi Eric, On Wed, 2006-01-18 at 09:22 +0100, Eric Lavarde - Debian wrote: I've got a good news: FreeMind is compiling with the new kaffe. The bad news is that it's not usable with kaffe (FreeMind starts but spits errors, doesn't redraw properly when using the menus, and is just not usable). Cool, that is some progress. Note that it is also mentioned on: http://developer.classpath.org/mediation/FreeSwingTestApps But there all it said was: it just shows the splash screen and main window, but doesn't react to any input. So now at least we react to input (but wrongly). PPS: errors I get: Default (System) Look Feel: javax.swing.plaf.metal.MetalLookAndFeel Exception during event dispatch: java.lang.ClassCastException: can't cast `gnu/java/awt/peer/gtk/GdkGraphics' to`java/awt/Graphics2D' at freemind.main.FreeMindSplash$1.paint (FreeMindSplash.java:59) This one is easy if kaffe has been configure with --enable-gtk-cairo (this is an experimental Graphics2D implementation based on Cairo, it still needs lots of works, I don't know if the kaffe package in Debian has this enabled). If it has then you can run the program with -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Is classpath-tools useful?
Hi Petter, On Sat, 2005-12-24 at 10:47 +0100, Petter Reinholdtsen wrote: I just found classpath-tools listed quite high on URL:http://haydn.debian.org/~thuriaux-guest/qa/global.html. The package look like it could need some care. Is the package still useful? I could not quite see what it does. That means upstream is lazy :) GNU Classpath Tools is part of GNU Classpath: http://www.gnu.org/software/classpath/cp-tools/ But we never made a formal release of the collection of tools. gjdoc is released separately. The other tools are mostly integrated into kaffe and gcj. Although gcc comes with a few alternative implementations of some of them (jcf-dump in particular as replacement for the cp-tools javap). Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
GNU Classpath friends meeting during Fosdem 2006
GNU Classpath friends meeting during Fosdem 2006. The various free software library, runtimes, compiler and tool projects around GNU Classpath will meet in Brussel to discuss what has happened in the last year in the Free Software community and what the next year will bring us during Fosdem. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ The program will be as follows: - Saturday from 13:00 to 17:30 - End-User talks Presentations that show what cool stuff can be done with the Free Stack right now. - Putting the 'Free' into JFreeChart Dave Gilbert, JFreeChart Project Leader A review of the efforts to make JFreeChart work with GNU Classpath-based runtimes, including a brief history, a demonstration of the current state (using the java bindings for Cairo), and an overview of the work that remains to be done. - Using Eclipse for GNU Classpath development Tom Tromey Learn how to setup a fully working development environment based on GNU Classpath in Eclipse that can be used to bootstrap the full free toolchain (and can be used to run Eclipse itself) in just 10 minutes. - Eclipse RCP and GCJ/GIJ Wayne Beaton Eclipse Rich Client Platform (RCP) is a runtime platform for delivering your Java applications on multiple platforms. RCP is far more than just a windowing toolkit; it is rich client middleware that provides a comprehensive framework for building and deploying applications that are modular, extensible, and updatable. The kinds of applications you can build with Eclipse RCP are limited only by your imagination. During this talk, we will discuss how the Eclipse RCP can be used in conjunction with the Eclipse Eco-system and GCJ/GIJ to build high quality applications. If there is time at the end of the day we would like to do a Show-And-Tell where people do quick Demos of applications running on a completely free stack. Ideas and suggestions welcome. - Sunday from 09:00 to 13:00 - Developer talks Presentations of (core) libraries and runtimes that are in progress, made a lot of progress in the last year and are in active development. - Free Swing, past, present and future Roman Kennke An overview of that state of Free Swing one year ago, what has been done in the meantime, what still must be done and which applications work now. - The Free CORBA comes Dr Audrius Meskauskas If the Free world does not want to step back in the battle, we need a complete set of the Free tools for advanced communication over the network. For our CORBA implementation we needed: 1. Free. No classes with restricted license. 2. Fully workable, interoperable and pass tests, recognized by the CORBA user community as serious (we needed to find a well known Free testing suite). 3. Properly commented, being ready for the long life in the Free world. 4. No pressure to use the outdated approaches. CORBA 3.0.3 and jdk 1.5. To reach these goals, we have chosen for implementing a clean room implementation, using the published standard specifications only. During the recent year of the GNU Classpath development, this goal is in large degree achieved. The important directions of future development could be providing features that are outside the scope of the both CORBA standard and Sun API, but included in the near all proprietary implementations (SSH, HTTP and other bridges, get rid of rmic code generator for RMI/IIOP, fault tolerant behavior, reduced the footprint and others). - The JamVM runtime Robert Lougher An overview of the JamVM virtual machine, with comparisons to other GNU Classpath runtimes, and a section on the VM interface. - Integrating Vmgen-based interpreters Christian Thalinger Vmgen is a tool for writing efficient interpreters. The Cacao runtime recently added a Vmgen based interpreter in addition to the JIT engine. - Sunday from 14:00 to 17:30 - The Future Interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. - State of the world, beyond japi Mark Wielaard, GNU Classpath Maintainer After a short overview of the various free stacks, libraries, compilers, tools and runtimes this session is mostly open discussion about what work remains to be done and how to integrate the various efforts better. Ideas for work items welcome. We hope to see you in Brussels on February 25 and 26 2006, If you have suggestions or ideas for the demos and discussion sessions please contact us at [EMAIL PROTECTED
Re: WTF: All those eclipse packages (and som gcj questions)
Hi, On Sat, 2005-12-17 at 16:35 +0100, Michael Koch wrote: Also the generics don't work when using the java-gcj-compat VM as you suggested for beeing able to use ecj as compiler. All language extensions from Java 5.0 work with GCJ 4.0. The main problem is just that you cant use the Java 5.0 API which use generics as this is not included in GCC 4.0 (and not in 4.1 either) yet. It will hopefully be included in GCC 4.2. To be able to use generics extended API of Java 5.0 you will need classpath-generics which is not in debian yet. We will hopefully upload this soon. Then you can e.g. use VectorString and such stuff. I got this working, see http://gnu.wildebeest.org/diary/index.php?p=139 But you do need classpath-generics and the latest jamvm to make this work. If you have those then you can tweak[1] the java-gcj-compat package to use the classpath-generics glibj.zip and jamvm runtime to run programs written in eclipse as follows: - Replace the /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre/lib/rt.jar link with a link to the classpath-generics glibj.zip. - Replace the /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre/bin/java link with a link to the jamvm binary. That will make sure that gcj itself still uses its own libgcj.jar, but the eclipse ecj compiler will use the classpath-generics glibj.zip to get access to the genericized method signatures. And that when you run any program written in eclipse it will be run with the jamvm interpreter instead of using gij which doesn't yet understand the new class byte code. Cheers, Mark [1] This will actually break the package a bit, so don't do this unless you know how to revert it. -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: SWT_AWT bridge with gcj !?
Hi, On Tue, 2005-11-29 at 09:34 +0100, Michael Koch wrote: On Tue, Nov 29, 2005 at 12:33:52AM +0100, Sebastian Menge wrote: The problem is that SWT_AWT uses a class that is only available in SUN-derived VMs. This class is in a protected namespace and not docmented publicly. GNU classpath derived VMs cannot implement it. This is some legal barrier too. GNU classpath provides a similar mechanism to embed windows in remote applications called EmbeddedWindow extension. This extension exists only in GNU classpath derived VMs. The question is if Eclipse can find a way to support both (the first for SUN derived VMs and the later for GNU classpath derived VMs). The best solution would be to submit a JSR to add an extension like this to the official Java API. Then both sides (and others too) can implement it and all applications can use the same code for all VMs. For those wanting help out. The embedded window support class from GNU Classpath is gnu.java.awt.EmbeddedWindow. Some more background on the bridge and SWT support in general can be found in the developer wiki: http://developer.classpath.org/mediation/FreeSWTTestApps And some more background can be found in this mailing list thread: http://lists.gnu.org/archive/html/classpath/2005-11/msg00162.html Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: CPL in debian?
Hi, On Mon, 2005-11-28 at 08:55 +0100, Michael Koch wrote: On Mon, Nov 28, 2005 at 01:01:16AM +0100, Sebastian Menge wrote: Especially: If I develop a eclipse-plugin under the CPL using only CPL and/or GPL software, may I put it back to debian? Well, Eclipse is in Debian which is licensed under EPL (a renamed CPL) and it is in main and not non-free. There were some discussions about the CPL on debian-legal@ mailing list. In a 5 second google search I found this: http://lists.debian.org/debian-legal/2001/12/msg00141.html There is a wiki page about the DFSG compatibale and incompatible at http://wiki.debian.org/?DFSGLicenses There is also some discussions about making the CPL/GPL-compatible (at least for verion 3). See the blog of the Executive Director of the Eclipse Foundation Mike Milinkovich: http://milinkovich.blogspot.com/2005/11/eclipse-and-gpl-30.html Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [Quantian-general] Weka Machine Learning Environment
Hi, On Sat, 2005-11-05 at 12:51 -0600, Dirk Eddelbuettel wrote: On 5 November 2005 at 12:09, [EMAIL PROTECTED] wrote: | I would be very interested in seeing the Weka machine learning environment | added to a live-DVD, such as Quantian. Weka is a powerful, open-source | data mining package with many artificial intelligence algrorithms, created | at the University of Waikato in New Zealand. It is written in Java, and so Sure, I'm aware of Weka and their book, but have never installed it as I find Java so tedious to work with. I also have limited time and bandwidth for figuring out suggested packages. If you could help with Weka, for example by installing Knoppix 4.0.2 (possibly the cdrom version) to disk and then documenting what you to do to install Weka, and make it work well, I'd be helped quite a bit. Ideally, of course, would be a Debian package encapsulating all this. It may be worthwhile mentioning this to the good folks over at debian-java -- cc'ed. [ Debian-java'ers, please CC us back directly on follow-ups. ] Sorry for the late reply. I just saw this. As part of GNU Classpath we are tracking weka as one of the applications we like to have supported. It is listed under Starts but doesn't really work yet on http://developer.classpath.org/mediation/FreeSwingTestApps If there are people wanting to test this application and give some feedback to the developers (either on that wiki or by emailing classpath@gnu.org) that would be appreciated. I must warn that it will certainly show some bugs though and you will have to get a CVS version of GNU Classpath for the latest development. (GNU Classpath is used by GCC/GCJ, Kaffe, Jamvm, etc. as core library.) Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
GNU Classpath hacker room at FOSDEM 2006
Hi all, Like the last couple of years we want to come together with all the projects around GNU Classpath and the various free runtimes, compiler and tool projects to discuss what has happened in the last year in the Free Software community and what the next year will bring us during FOSDEM. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ We were thinking of the following setup: - Saturday from 13:00 to 17:30 - End-User talks presentations to promote what we all build together to a wider audience that might have heard of what we do, but haven't actually seen it in action/put together. We might also want to have a lightning hour with lots of quick Demos of applications running on a completely free stack (5 - 10 minutes per demo). - Sunday from 09:00 to 12:30 - Developer talks presentations of things that are in progress and that people want to explain in more depth to get developers of the other projects to join in a share the fun. - Sunday from 13:00 to 17:30 - The Future hard core interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. Arnaud Vandyck, Dalibor Topic, Mark Wielaard, Michael Koch and and Tom Tromey will be our program committee this year. If you would like to present something, have an idea for a demo or discussion topic please let us know at fosdem-at-developer.classpath.org Please mention the title, a little abstract, which track and whether you want to do a quick demo, a short 30 min talk or full hour talk (we prefer 30 minute talks to give everybody a chance to present something). Deadline for proposals is December 18, so you have a month to think of something cool. Then we make sure to have some kind of formal program at the start of January. Examples of presentations and reports from previous years: http://www.gnu.org/software/classpath/events/escape_fosdem05.html http://www.gnu.org/software/classpath/events/fosdem04.html Some ideas for interesting topics: - Free Swing - The Demo! - Your GNU/Linux distro and the free runtimes - package overview. - From 0 to 100 in 15 Minutes: Getting started with GNU Classpath development using Eclipse, JamVM, Mauve, and the ChangeLog plugin! - Integrating with Objectweb through native-(gcj)-JOnAS - Writing OpenOffice.org plugins using a free software stack. - Using GNU Classpath/gcj/kaffe for games - Using free runtimes on Wine and other win32 environments - Embedding GNU Classpath in web browsers and support for JNLP - Security Auditing! - 1.5 language support in GNU Classpath, gcjx and the free runtimes - GNU Classpath/OSGi/J2ME/Library splitting and trimming - Harmony through interfacing. - Beyond JAPI: what is needed to really finish GNU Classpath Or, Beyond Java -- what we can do when we finish 1.5. Or more generally some kind of presentation about development metrics: bug rates, rates of change in japi/lines of code/tests, email volume, stuff like that. - Debugging, JDWP development efforts. - etc. Hope to see you in Brussels on February 25 and 26 2006, Arnaud, Dalibor, Mark, Michael and Tom -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Current status of your swt-gtk package
Hi, On Mon, 2005-10-24 at 16:36 -0400, Andrew Overholt wrote: So basically the information in this article applies? http://www.linuxjournal.com/article/7413 No. That's an old article and was written before gcj's Binary Compatible ABI was implemented. That was the first generation of native eclipse. With gcj 4.0 a more flexible way of mixing-and-matching native ahead-of-time compilation with interpreted code and classloaders has been added. See for a high level overview GCJ - past, present, and future http://lwn.net/Articles/130796/ No changes to Eclipse's class loaders (or those of any other app) are necessary. This way, users can run with another JVM if they want and just use the bytecode. For more informtaion, see Tom Tromey's article in the latest Red Hat magazine (sorry, I don't have a URL handy but it was reference in Mark Wielaard's latest blog entry which can be seen at http://planet.classpath.org). That is the Fedora and the J-Word article: http://www.redhat.com/magazine/012oct05/features/java/ Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: JCE Code Signing Certificate
Hi, On Wed, 2005-10-12 at 09:51 +0200, Michael Koch wrote: This is a big field which needs even bigger investigation. The free runtimes can load them but signed jars are still not supported (or was this fixed lately...). Your best action would be to just test it with kaffe or gcj or whatever and report any bugs you find. Signed jars can be loaded and the classes are assigned protection domains based on the found signatures. That doesn't mean all permission checks are done correctly or that access controller has been implemented correctly. We need to do an extensive security audit of the whole code base (compiler, runtime, core libraries) before trusting this kind of sandboxing to work as advertised. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: JCE Code Signing Certificate
Hi, On Wed, 2005-10-12 at 16:45 +0200, Florian Weimer wrote: In the meantime, it occurred to me that the certified key (including the private key) would have to be included in the source package, otherwise the package would fail to build from source. While I see nothing in Sun's form that requires us to keep the private key secret, publishing it still not be such a good idea. The key must be kept secret, otherwise it can't be trusted (i.e. people could maliciously modify the code, and then sign their modifications). And how would this be a problem? Keep in mind that it's apparently pretty easy to obtain your own certificate. (That's part of the reason why I still wonder why this signature is necessary.) I quickly looked at this and it seems this is something really specific to the proprietary jce implementation which refuses to load security providers that aren't signed by a key trusted by Sun. The free implementations based on GNU Classpath don't have any such restrictions. You are free to link against any security provider you feel would help you do your job. It is unclear to me why Sun wants to control this especially since they seem to be liberal in handing out trusted certificates which you can then share with anybody you wish (like the users of your debian packages so they have the same freedoms as the packager). Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: ant VS make
On Sun, 2005-10-16 at 23:32 +0200, Daniele Menozzi wrote: Hi all, I've always used make for my java projects, but recently I tried ant. It seems interesting, but it has a huge drawback: it is really slower than make. There is a replacement project gantt that is a lot faster, but doesn't support all traditional ant tasks yet: http://savannah.nongnu.org/projects/gantt gantt is a replacement for Apache Ant for free operating systems, written in C. It uses libxml2 and glib. gantt can be extended with tasks written as separate programs or shell scripts. Distributed under the GPL (which is a plus if your code base might not be compatible with the ASL). So theese are my questions: do ant give me some important advantages that make doesn't? What tool do you use? Not really imho. I use plain old Makefiles. The problem with ant is that you need to install it everywhere first while make is already available everywhere. Also the XML syntax it uses makes it pretty hard to quickly read and understand (especially if you are used to simple make rules). It also makes bootstrapping projects a bit harder, but that might be specific to a lot of core libraries and tools I am involved with. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
DevJam reports
Hi all, The GNU Classpath distro DevJam was a great success. It seems we brought some harmony into the hearts and minds of the different distributions (Ubuntu, SkoleLinux, Debian, Fedora, Suse, Gentoo, OpenEmbedded) that participated. And being able to talk and debug some issues with several of the upstream projects involved (GNU Classpath, kaffe, gcj, Cacao) was definitely inspirational and productive. Here is a list of other summaries and notes of the meeting: - SkoleLinux summaries and pictures: http://skolelinux.de/wiki/FreeJava/Meeting050923 - OpenEmbedded ARM TODO list: http://www.informatik.uni-bremen.de/cgi-bin/cgiwrap/rwagner/pyblosxom.cgi/computers/freejava/gcj-on-arm.html - GCJ maintainer/Fedora impressions by Andrew Haley: http://www.advogato.org/person/aph/diary.html?start=0 - Gentoo DevJam braindump by Petteri Räty (plus presentation) http://article.gmane.org/gmane.linux.gentoo.java/598 http://dev.gentoo.org/~betelgeuse/show.pdf - DevJam Arrival and Schedule/Discussion notes: http://gnu.wildebeest.org/diary/index.php?p=116 - Debian Project leader notes: http://necrotic.deadbeast.net/~branden/blog/exuberance/Debian/destination_oldenburg.html - LWN article about the meeting that is currently being published for subscribers (please support LWN it is a great magazine): http://lwn.net/Articles/153450/ Next week it will be free for all. (Please send me, or the devjam mailing-list, updates and additions.) On request of several of the participants I have setup a mailing-list so people can keep in touch and coordinate cross-distro/packaging/project things. If you are interested please send an email to [EMAIL PROTECTED] The mailing-list has a public archive accessible through: http://developer.classpath.org/mailman/listinfo/devjam And if you are interested in participating or helping out with a followup meeting please see the wiki about DevJam++: http://java.debian.net/index.php/DevJam++ Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: How to compile java files?
Hi Joerg, On Thu, 2005-09-01 at 21:40 +, Joerg Sommer wrote: Barry Hawkins [EMAIL PROTECTED] wrote: Joerg Sommer wrote: [...] And which one should I chose? sablevm, kaffe, gcj,...? Is there an default for debian packages? [...] That can be a hot topic, but I'd say the majority of us default to kaffe. Because Mark Wielaard gave me a pointer on a debug FAQ for kaffe, I tend to use kaffe. Thanks for your hot answer. :) But, but, but. That message was meant to show that you how cool gcj was and that you could just happily use gdb on native compiled programs. But that if you really, really wanted you could also do something with kaffe through some tricks that needed a long debugging FAQ to get working... :) I must admit that personally just use printf(), System.err(), Thread.dumpStack() and printStackTrace() a lot which works in any environment. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: java debugger in Debian
Hi Joerg, On Mon, 2005-08-29 at 12:18 +, Joerg Sommer wrote: exists a Java debugger in Debian? I tried jswat, but it do not work without special classes. jswat needs some jdpa infrastructure which isn't available yet. There is a lot of work going on for jdwp at the moment in GNU Classpath, but it will be a little while before that is fully finished. If that works however the rest of the jdpa infrastructure shouldn't be that hard to finish. And how I can enable gdb to debug java, I didn't find out. If you are using gcj compiled java programs you can just use gdb like normal. See also: http://gcc.gnu.org/java/gdb.html When using kaffe see http://www.kaffe.org/doc/kaffe/FAQ.xdebugging Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: DISPLAY= makes sablevm and kaffe fail
Hi, On Mon, 2005-08-29 at 22:16 +0200, Michael Koch wrote: I will start to maintain a package[1][2] used for analysing the boot process. I collects data while booting and saves they somewhere. Later the user can run a java program to render a graph from this data. If the DISPLAY variable is unset sablevm and kaffe fail to render the graph even through no graphical output is needed/made. [...] Can sablevm and kaffe render png images? Currently GNU classpath which gets used by both can only render images using GTK and these do not work headless. It will take some time to develop this upstream. This is being worked on. But note that if you have a DISPLAY set that works then bootchart should work with gcj. See for example http://www.bootchart.org/images/bootchart.gcj.png But you might need a CVS version that is compiled against cairo 0.3 and the system property gnu.java.awt.peer.gtk.Graphics=Graphics2D set. See the last NEWS item at http://www.bootchart.org/ Ziga, the bootchart author, helps from time to time with gcj and GNU Classpath development so he might know the status best. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
GNU Classpath distro DevJam Europe (Oldenburg, Germany, 23 - 25 September)
Hi all, On Wed, 2005-08-17 at 16:02 +0200, Mark Wielaard wrote: Various Debian packagers and developers are interested in coming together to improve the Free Software tool chain, the programs and the free runtime environments for software written in the java programming language. For such a meeting we would like to include packagers from various distributions to coordinate on library names, dependency and versioning. And to share experiences on how to integrate and map dependencies of tools like ant and maven when creating traditional GNU/Linux distribution packages. So we are proposing a developer and packager meeting around coordinating and improving the state of packaging of large scale applications written in the java programming language using the GNU Classpath, gcj and other free java-like tool chains for the various GNU/Linux distributions. Please see DevJam wiki for details: http://java.debian.net/index.php/DevJam We hope to get together a group of (20 till 30) people wanting to do some hands on hacking to show the state of the art in packaging. Resulting in the availability of several new packages, improvements to the free tool chains and cross-distribution packaging conventions quickly after the meeting. We got a lot of interest for this meeting and would like to announce that we will have a gathering in Oldenburg, Germany on Friday 23 till Sunday 25 September. To reduce the costs the meeting will be shared with the Oldenburg Linux Developers Meeting 2005 group: http://meeting.ffis.de/Oldenburg2005/ There will be cheap accommodation for those that bring their own sleeping bags and mattress. See for more information on Oldenburg and how to get there by car, train or plane: http://en.wikipedia.org/wiki/Oldenburg http://meeting.ffis.de/Oldenburg2004/routing.html If you haven't added your name to the interested people list on the wiki please do so soon: http://java.debian.net/index.php/DevJam We hope people can arrive on Thursday evening so we can start fresh and early on Friday 23th of September. Since we know that there has also been a lot of interest of people outside Europe we would like to make this our European meeting and schedule a Worldwide or Regional DevJam++ meeting in a couple of months to give more people the opportunity to attend. If you are interested in helping to organize that please add suggestions to the Wiki: http://java.debian.net/index.php/DevJam++ Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Bouncy Castle ready
Hi Charles,
On Tue, 2005-08-30 at 10:15 -0400, Charles Fry wrote:
Did you report those bugs to the classpath mailing list?
No, that is what I was trying to ask how to do. I know the specific test
cases that fail, but assumed that I should dig deeper into the code to
find the root cause prior to reporting it. How much detail should I
gather prior to reporting it (given my current time constraints I could
report it with little detail now, but won't have time to dig into it
more myself for a while).
Please add as much details as you have now to the bug database
http://www.gnu.org/software/classpath/bugs.html
That way the issue isn't forgotten. You can always later add more
details if you have more time. Just make sure the instructions on how to
repeat the issue are clear and simple to follow so someone else can try
to reproduce it.
Also running with kaffe gave different
failures than running with sablevm and gij (all failed on the same test
cases, in different ways); I'm not sure quite what to think of that.
The runtimes are probably not completely in sync. Hopefully it means
that the runtime with the latest GNU Classpath gives the least faults.
But it could of course be that we introduced a regression lately :{
Thanks,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
Re: Bouncy Castle ready
Hi, On Tue, 2005-08-30 at 11:51 -0400, Charles Fry wrote: I'd like to test this bug against .17, but was hoping to avoid spending a lot of time doing so. What are the prospects of getting .17 into Debian? I'd be glad to help out if there is anything I could do. :-) Try filing a wishlist bug against the classpath package: http://www.debian.org/Bugs/Reporting Since we hope to release a GNU Classpath 0.18 snapshot next week it would be nice to know if the Debian packagers are having any trouble packaging newer releases (0.14 is more then 6 months old). Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Eclipse 3.1-7 debs uploaded
On Tue, 2005-08-23 at 14:25 +0200, Mark Wielaard wrote: I am also trying to build it from source. But got the following error after a while: build.cfiles: [java] Could not find org.eclipse.swt.tools.internal.JNIGeneratorApp. Make sure you have it in your classpath [java]at org.apache.tools.ant.taskdefs.ExecuteJava.execute(org.apache.tools.ant.Project) (Unknown Source) Note that the build does not fail even though this seems a real problem. Interesting enough. After it finished and I installed the produced packages I got a working eclipse. Yeah! Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Eclipse 3.1-7 debs uploaded
Hi, On Mon, 2005-08-22 at 21:29 +0200, Niklaus Giger wrote: After installing eclipse-platform-gcj I got the next error (see attachement). What is still missing? Any hints would be appreciated That log file looks very similar to what I am getting on x86 after updating to the 3.1-7 packages. The previous 3.1-6 packages seemed to work fine (except for some minor packaging bugs that I already reported to Michael). Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Missing JSpinner component
Hi, On Wed, 2005-08-17 at 22:06 +0200, Arnaud Vandyck wrote: Waiting - and helping out - for a working swing implementation in GNU classpath. When this goal is achieved for the different applications is to be decided by the packager (who should from time to time test it IMHO). This is it :-D Eric, reporting what Swing classes are missing is very helpful because GNU Classpath devs can review some priorities when they'll have some time to add these classes... Yes please. If there is a feature/class/method missing you really need for some package to enter main please file a bug report: http://www.gnu.org/software/classpath/bugs.html We cannot promise to fix things instantly, but we are very motivated by real users with real problems we can solve. So please let us know what you want and we will do our best to get it to you! Thanks, Mark signature.asc Description: This is a digitally signed message part
GNU Classpath distro DevJam
Hi all, Various Debian packagers and developers are interested in coming together to improve the Free Software tool chain, the programs and the free runtime environments for software written in the java programming language. For such a meeting we would like to include packagers from various distributions to coordinate on library names, dependency and versioning. And to share experiences on how to integrate and map dependencies of tools like ant and maven when creating traditional GNU/Linux distribution packages. So we are proposing a developer and packager meeting around coordinating and improving the state of packaging of large scale applications written in the java programming language using the GNU Classpath, gcj and other free java-like tool chains for the various GNU/Linux distributions. Please see DevJam wiki for details: http://java.debian.net/index.php/DevJam We hope to get together a group of (20 till 30) people wanting to do some hands on hacking to show the state of the art in packaging. Resulting in the availability of several new packages, improvements to the free tool chains and cross-distribution packaging conventions quickly after the meeting. One of the ideas to keep the cost down for now is sharing the meeting with another group in Oldenburg, Germany, from September 21st to September 25th. http://meeting.ffis.de/Oldenburg2005/ If you are interested please add you name and thoughts about how to make such a meeting most effective to the wiki! And please contact us if you are interested in sponsoring the effort. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Eclipse Debian package status
Hi, On Mon, 2005-08-01 at 16:42 -0400, Charles Fry wrote: I am attempting to contact anyone who has previously expressed an interest in packaging a new Eclipse release for Debian. I grabbed everyone from the ITA, as well as the Alioth project, and the Java list for good measure. :-) I have CCed Michael Koch. He is working on 3.1 packages. Which are described and available from http://gnu.wildebeest.org/diary-man-di/ Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: GCJ Native Proposal
Hi, On Sat, 2005-04-30 at 21:30 +0200, Michael Koch wrote: We can decide to pubild only some archs to native. E.g. native libs for Eclipse make little sense on arm. Why does it make less sense on arm then on any of the other architectures? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: GCJ Native Proposal
Hi, On Sat, 2005-04-30 at 22:00 +0200, Arnaud Vandyck wrote: Tue, 15 Mar 2005 15:35:56 +0100, Michael Koch [EMAIL PROTECTED] wrote: You are right, its not always a gain. Tom Tromey told me that he is aware of one case where the native library is slower then interpreting the jar. I think it's faster when it starts up, and I think there are more than one case where native is slower the Sun's JIT! ;-) I asked Tom what he meant with that. And he couldn't remember what the context was. There are certainly (micro) benchmarks where gcj generated code is slower then when executed by some other execution model. But there are also (micro) benchmarks where the opposite is true. Anthony Green has collected a couple of those: http://www.spindazzle.org/benchmarks/ But on average gcj is comparable with other execution models. Sometimes faster, sometimes slower. Some (old) benchmarks can be found here: http://www.shudo.net/jit/perf/ These don't have gcj 4 benchmarks yet though. Note that the future looks bright. For GCJ 4 the focus was on completeness and correctness. There have not been many optimizations yet. GCC 4.0 comes with a new (Tree SSA) infrastructure to make optimization passes easier. Hopefully there will be some time to use that for GCJ 4.x. If you have any examples where gcj is not doing very well, please write to the gcj mailinglist. Sometimes the developers don't know yet that an optimization might make sense. Then having examples of badly performing code will help to correct the problem in the future. See for example this message: http://gcc.gnu.org/ml/java/2005-04/msg00119.html Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Eclipse 3.0 on GCJ test and release schema
Hi, On Wed, 2005-02-02 at 13:00 +0100, Daniele Cruciani wrote: Here is what I did: [added a line of mentors source] `apt-get source libjsch-java` `apt-get build-dep libjsch-java` `apt-get --build source libjsc` 'dpkg -i libjsch-java_0.1.19-1_all.deb libjsch-java-doc_0.1.19-1_all.deb' You probably also need (one or more of): apt-get install junit apt-get install zip apt-get install sharutils [all ok here] `apt-get build-dep eclipse` `apt-get --build source eclipse log.eclipse3.comp12` thus the log (in attach) Which indicates that the compiler cannot find the junit package. Hope this helps. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Running Eclipse 3.0.1 packages on a few VMs
On Fri, 2005-01-14 at 08:52 -0600, Jerry Haltom wrote: Yes, we've seen this before. It is not good it ignores a lock after only 5 seconds. Maybe, as a debian-specific patch we could have this timeout somewhat increased? 20s? Sounds reasonable, unless anyone has serious objections? My objection is that it works fine with Sun's VM, why doesn't it work with another VM, and fix that. Because we want it to work with free environments and if we can do that with an easy fix like this that doesn't really impact other runtime environments why wouldn't we. Besides this is not easy to fix in an interpreter like sablevm since it just isn't fast enough to complete the task in such little time. I think it would even be a good idea to make the timeout really large to be sure that it really completes since if it doesn't there is clearly something wrong with that Plugin. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Which JVM do other PPC users use?
Hi, On Sat, 2004-10-02 at 00:47, Barry Hawkins wrote: What JVMs are you other PowerPC users employing? Are there many of us? I kind of thought I was the odd bird with that. I am using gcj and gij on PowerPC and they work just fine. JamVM and kaffe also work, but being interpreters they are a lot slower. Kaffe is rumored to get a working PPC jit though. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: java-gnome vs. SWT
Hi, On Sat, 2004-09-18 at 17:29, Jan Schulz wrote: * Mark Wielaard wrote: Since SWT is distributed under the CPL, Common Public License, which is not GPL compatible, you won't be able to distribute a larger work based on it under the GPL. What is with GPL+linking exception? You can add an explicit linking exception to a work to say that it can be distributed under the GPL as a whole with an explicit exception for part of the work (SWT in this case). The GPL FAQ has an entry about this: What legal issues come up if I use GPL-incompatible libraries with GPL software? http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs And this is a practical example how MySQL handles such cases: http://www.mysql.com/company/legal/licensing/foss-exception.html Note that in general you cannot just add such an exception to the GPL without all copyright holders of the original work giving permission for that. Azaurus (sp?) is also GPL and absed on swt and tehre is already a ITP for it. Better run that by debian-legal then. It might be said that there is an implicit linking exception for SWT since it is designed to be integrated with it. But last time this came up on debian-legal when Qt was still under the QPL, which is also GPL-incompatible, debian-legal didn't like such an implicit permission (Qt is distributed under the GPL these days, so this isn't an issue any more.) It is much better to have an explicit statement about the intention to create a larger work based on GPL and non-GPL-compatible code. Or we can try again to convince the Eclipse community to distribute SWT under a GPL compatible license (or dual license SWT under the CPL and GPL or LGPL for example). Cheers, Mark BTW. For full disclosure I should add that I created a GPLed bittorrent framework which has a java-gnome client frontend. The Hunting of the Snark Project - BitTorrent Application Suite http://www.klomp.org/snark/ signature.asc Description: This is a digitally signed message part
Re: RFH: how to really assemble java packages
Hi, On Fri, 2004-09-17 at 17:10, Dalibor Topic wrote: Laszlo 'GCS' Boszormenyi gcs at lsc.hu writes: * Dalibor Topic robilad at kaffe.org [2004-09-16 11:18:00 +]: Thanks for presentig the case to upstream. I hope they will follow your suggestions. But before they asked the following question: Do you know an open source JavaMail implementation that is working? I think both ClasspathX JavaMail and Tiger JMail[1] are working and complete, but I have no experience with JavaMail myself, unfortunately, so I can't make a statement regarding their implemenation quality. I'm sure that the developers on the respective mailing lists can help them further, though. Tiger JMail is an old not-update-anymore fork of GNU javamail. GNU javamail, part of GNU ClasspathX, is packaged for Debian as libgnumail-java. Discussion mailing list is at: http://lists.gnu.org/archive/html/classpathx-javamail/ Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: java-gnome vs. SWT (I know this has been asked before..but need some clarification)
Hi, On Thu, 2004-09-16 at 22:09, Rishabh Manocha wrote: when developing a GUI application with java, is it better(keeping portability in mind) to use the java-gnome packages or the SWT packages? I know this has been asked before but this exact questions was not answered(I went through the archives). I am writing a small java application(http://jfortune.sf.net). I wanted to learn some GUI programming. I came across java-gnome and SWT. I wanna ask you guys which one of these do u think is better. I want to have the app run on both windows and linux. It will be pretty small but i still wanna learn how to make GUI's under linux. Since SWT is distributed under the CPL, Common Public License, which is not GPL compatible, you won't be able to distribute a larger work based on it under the GPL. Since jfortune is distributed under the GPL swt seems to not be an option. java-gnome can be used to mix and match with normal GPLed code. And from my experience with the API it works very nicely and it is packaged for Debian as libgtk2-java and libgnome2-java. I haven't tried java-gnome on Wine or cygwin. Best to ask on one of the java-gnome mailinglists about that: http://sourceforge.net/mail/?group_id=1522 Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Question about java-virtual-machine
Hi, On Tue, 2004-08-31 at 04:12, Grzegorz B. Prokopski wrote: Not sure it's a good idea. Given that the java-virtual-machine dependency was created to accomodate the properties shared among the JVMs and that most of JVMs, in general, is capable of running JNI code, running a JNI code is kind of expected from a package that provides java-virtual-machine. Additionaly there's no automatic or even semi-automatic way to ensure that ikvm won't be used to run some java code using JNI libraries. This is bad as there is plenty of java libs that contain some (usually minimal) native part. The best that can be done is to go case-by-case and add | ikvm do Depends: of these packages that can be effectively run with it. Note that the new IKVM snapshot (from today) has a new JNI provider which should be at least good enough to get Eclipse 3 starting up. So it should now be at least as capable as jamvm, gcj/gij or kaffe with respect to JNI. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [kaffe] kaffe/jikes makes incompatible code for jdk1.3? (was: [Detelin Batchovski] Bug#262897: libservlet2.3-java_4.0-4: Failed start Tomcat4 after upgrade)
Hi, On Wed, 2004-08-04 at 23:48, Arnaud Vandyck wrote: I built javax.servlet with kaffe/jikes/ant1.6, but when running with jre1.3, it seems there is a problem... log is attached. Seems the runtime that is used doesn't support newer versions of class file byte code (Unsupported major.minor version 48.0). You are probably using a modern version of jikes that by default generates this newer byte code. As far as I know all free runtimes in main have been updated already to support it. But you can probably downgrade the class byte code version used by giving jikes a -target 1.2 argument (see the jikes documentation). Debian: If the problem could not be solved soon, it means we'll have to build servlet with non-free JDK again! It means libservlet2.3-java back to contrib! Why? It isn't a bug with any of the free main runtimes. And it seems a upgrade of the non-free proprietary runtime that this person is using would solve the issue. I'll wait two or three days before uploading a servlet compiled with non-free jdk back to contrib, hoping kaffe guys can resolve this (but I assume it's not trivial!). Comments? If you really need to, why not create a new libservlet2.3-java-nonfree-old-runtime package and keep the current package in main since it seems to work fine with the free runtimes? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Report from the Debian Java developers meeting at FOSDEM
Hi, On Wed, 2004-03-03 at 01:19, Arnaud Vandyck wrote: If Red Hat is willing to give the work back to the community (I hope they'll do), the demo was really good. If the promises will never be available it would be *very* frustrating. Everything is out there http://sources.redhat.com/eclipse/ no trickery used during the demonstration. I actually compiled everything from source to make sure that the demo was real. You can have a native Eclipse on your Debian box now (through alien to convert the gcc-ssa, runtime and native-eclipse rpms to debs). The real problem is incorporating all the changes into the different code bases upstream. To be honest I believe this must be a bit frustrating for some of the hackers who work both for Red Hat on some of this stuff and also for the different projects like gcc. They had to make some horrible hacks for their corporate masters so they have something that at least works for them, but they cannot accept those ugly workarounds when they are wearing their GNU maintainers hat. Everybody that wants to help cleaning up some of the ugly hacks is appreciated (contact [EMAIL PROTECTED] for more info) But I can understand Red Hat spending a lot of money to finish awt and swing (I heard this, is it true?) Yes, some Red Hat hackers help a lot with trying to finish the standard java GUI core library parts. But they are not the only once working on it. It truly is a cooperative effort. I have attached an email I sent to the classpath mailinglist yesterday but which seemed to have never arrived (looks like some of those new Windows virusses are hitting the gnu.org mail servers very hard). It shows where we are at the moment and where we want to go in the future. they maybe want to be the first distribution to provide a complete free java alternative. Debian does not have this problem. I'd be really happy if we can provide a complete free java alternative six month later (it would be no problem for me!)... but I hope it'll take less time ;-) (and it'll be available for the community). Come on :) Show a bit more spirit! We might want to cooperate together with the other distributions. But that shouldn't mean they can just beat us to the punch! Cheers, Mark ---BeginMessage--- Hi all, The following is an email I send to some people wanting to help out with Swing. It is probably a good idea to post it to the list so others also know about the current status of the current efforts with respect to getting a free Swing implementation for GNU Classpath, gcj and other free runtimes. If you are looking for things to help out with then this email will contain lots of hints! I do want to add that even though I am extremely happy we are now making real progress on this front, it is still a lot of work. Even if we can keep the current rapid progress it will take many months before we will have something people can reliably use (for Swing, AWT is in a pretty good shape now). And as noted below not all of AWT and Swing is covered yet. Please don't recommend Swing to anybody except to say that if they already have free software written that currently uses non-free Swing implementation to contact us to see how we can help migrate the application to what we are working on. (For new applications that need a GUI, I would recommend the java-gnome bindings that will be part of the next Gnome 2.6 release. (http://www.gnome.org/start/2.5/bindings/ and http://java-gnome.sf.net/) The approach we are taking is making sure that we have a AWT build upon GTK+ peers (which is the most important peer implementation we want at the moment since it integrates so nicely with the rest of the GNU system). The AWT (peer) Components are mostly functional already. Testing is done with the visual-tester in Mauve (http://sources.redhat.com/mauve/). There is also a simple TestAWT program in the classpath source tree of which you can see a screenshot: http://www.klomp.org/mark/classpath/awt-04-03-2004.png Other non-component parts of AWT are not yet implemented completely, or have some stubs at the moment. These are java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.im.*. Help on these is really appreciated. GTK+/freedesktop.org has libraries for cut paste, drag drop, and internationalization that can/should probably be used for some of these. The other big problem area is java.awt.image.*. If you want to work on that package please ask on the list what the current plans are (Thomas Fitzsimmons will probably coordinate this). Swing is implemented on top of AWT and the java 2D (java.awt.geom) classes that Graydon Hoare previously created (on top of the cairo library from freedesktop.org). Although our current Swing implementation doesn't really use java 2D at all. http://people.redhat.com/~graydon/native-java2d-aug28-2003.png Some parts (JList, JProgressBar, JSeparator, JButton and JLabel) are starting to work, there is still a lot to do. But we are now seeing daily progress. See for
Re: Co-maintaining Kaffe
Hi, On Thu, 2004-03-04 at 23:27, Ean Schuessler wrote: [...] we need to talk [...] Yes! And you did. Thanks for joining us last evening on #kaffe (irc.gnu.org). I am really glad that we are communicating now. Reasonably, however, you need to acknowledge that Arnaud's efforts to work with *me* since I made my request have been less than acceptable. Continuing to NMU the package without communication, refusing to communicate requests with me in advance of making changes and all the other things I've detailed are not the kind of actions that are going to get a Kaffe strike force productively rolling ahead. You will probably still not call me reasonable. Most of the feedback you got on the list was because people know Arnaud. And they know that he communicates, that he means well, that he really wants to work together with others and that he doesn't want to offend people or do things just on his own. People don't yet know Ean (anymore). I am glad he is now talking. You said that you have seniority. And that is true. You go back to the old free java hackers. You have known about the world when kaffe was the way people learned about this java programming language. When people were amazed that the free software community could make this neat idea work. That kaffe showed that a JIT is something that works on multiple platforms. When the proprietary implementation was playing catch up. And when Sun seemed nicer about working together on standards. You probably remember the Jolt project were Eric Raymond, Tim Wilkinson and Guy Steele from Sun worked together on free java [1]. Those were exiting times! We want that world back! Nobody back then probably thought that it would develop into some fat, slow, proprietary and silly Sun thing. And we do need your help. We lost a lot of the old free java hackers. I am really glad you didn't give up like some of the others mentioned above. We might be a bit younger and have less seniority, but we make up for it by showing a amazing passion to turn this into a good thing for the free software world and Debian in particular. There are so many people writing free software in the java programming language. We want to welcome them to Debian. Make Debian the best java-like platform there is! I saw you already joined the Debian Java packaging project on alioth [2]. And even though I am not a Debian developer I did join the Pkg-java-kaffe mailinglist [3] so I am hopefully able to help with any packaging questions that need upstream guidance. Hope we will work nicely together. Thanks, Mark [1] http://linux4u.jinr.ru/usoft/WWW/www_redhat.com/linux-info/jolt/ [2] http://pkg-java.alioth.debian.org/ [3] http://lists.alioth.debian.org/pipermail/pkg-java-kaffe/ signature.asc Description: This is a digitally signed message part
Re: Co-maintaining Kaffe
Hi, As an up-up-stream maintainer for GNU Classpath, which is used by kaffe and as a kaffe developer I must say that I find some emails about maintaining the kaffe package for Debian highly unfair to Arnaud. Arnaud does all the work on kaffe and communicates with lots of other package maintainers and upstream developers about what the best course of action is to get a great kaffe platform in Debian. Ean gives the impression that people like Arnaud don't try to communicate with him. But the fact is that Ean doesn't seem to communicate at all. Except now to claim that he is still the official Debian maintainer and that everything should be cleared with him. Ean knows damn well that he never replies to any of the requests people send him or look at any of the bugs filed against the kaffe package. People on the debian-java list were really happy when Ean accepted the fact that he was essentially not the maintainer anymore and let Arnaud (and others) be co-maintainers. They respected his request to be the maintainer in name since this was his last official debian package. And they were really happy with Ean his suggestion of setting up a kaffe-strike force. But since then Ean hasn't worked together with this strike-force at all. Arnaud was the person going through all the bugs filed against kaffe. Checking with upstream whether or not they knew about it and helping fix issues for users. Arnaud was the person going through all the Debian specific patches with the upstream developers to see whether or not they were still needed or whether they could be integrated upstream. Arnaud was the person to work together with other package maintainers to setup http://java.debian.net/. Arnaud gave a presentation together with the main kaffe developer at FOSDEM to talk about issues packaging kaffe and other packages depending on kaffe. Arnaud discussed what to do about the fact that kaffe has been broken for a couple of architectures for a long time. On the kaffe mailinglist he posted the Debian buildd logs to help correct errors. And he was the person that asked upstream how they wanted the kaffe package in Debian to be handled to finally get it into testing. It feels like Ean is hiding behind some Debian policy to keep people with more enthusiasm and time from maintaining the package. They have asked Ean time and again to join them in their efforts, to communicate with them on packaging issues (through personal emails from Arnaud, emails on the debian mailinglists, filing and documenting issues in the bugdatabase, etc), but he seems to ignore all the hard work they do. I would advice Ean and Arnaud to call each other on the phone one of these days to talk it out. Or maybe that some other less involved Debian developer discuss the situation (off-list) with them to see what the most appropriate action with respect to maintaining kaffe for Debian is. Ean his idea about having a kaffe-strike force was good. But all people will have to communicate and participate in the strike force for it to work. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Report from the Debian Java developers meeting at FOSDEM
Hi, Thanks for the report! On Tue, 2004-03-02 at 16:54, Stefan Gybas wrote: - Native compilation Mark Wielaard and Tom Tromey showed a natively compiled version of Eclipse (http://www.eclipse.org) using gcj. Arnaud and I talked to them about packaging natively compiled software but this still requires patches for gcj so this is not yet an option for Debian. It will of course be interesting after the release of sarge but let's first see how well this works in the next release of Fedora/Red Hat. To my defense I must say that I did the demo on a Debian system. But indeed I build the whole thing on a Red Hat (9) system with a patched gcj-ssa. The rpms were converted to debs for the demo though since I didn't want to put a non-Debian system on my laptop. Hopefully the gcj 3.4 release will be able to run Eclipse interpreted through gij out of the box (that is not very fast, but not as slow as you would think). That doesn't solve the build issue though. It is a bit frustrating that we have all this working with CVS versions and special branches of the various projects. I understand perfectly well that you cannot package such a hodgepodge for Debian. Hope you weren't offended by my teasing that Red Hat gets it, but Debian doesn't. They do take a couple of short cuts at the moment which aren't appropriate in the long run, especially not for Debian. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Report from the Debian Java developers meeting at FOSDEM
Hi, On Tue, 2004-03-02 at 19:25, Grzegorz B. Prokopski wrote: W licie z wto, 02-03-2004, godz. 10:54, Stefan Gybas pisze: [... cutting out all things that I agree with ... ] - License conflicts with GPL'ed Java interpreters Currently Kaffe 1.1.x is the best choice for running Java applications in Debian. It is, however, licensed under the GPL so there's been some discussion whether Java software which is licensed e.g. under the Apache License (version 1.1 or 2.0) can be run with it. The opinion of the Free Software Foundation can be found at http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL, however some developers have a different point of view since Kaffe's core classes are just another implementation of the standard Java API. That there exists a standard API doesn't suddenly mean that combining a GPLed work with something else to create a larger derived work makes some terms of the GPL not apply anymore when you distribute the combination. The long-term solution to this problem is probably the ongoing merge with GNU classpath (http://www.gnu.org/software/classpath/) which is licensed under the GPL with a linking exception. In a couple of Unless I am seriously missing something, this won't change much if anything, as the Kaffe JVM engine itself still remains under GPL. The importance is that the more kaffe uses the same (GNU Classpath) libraries as all other free VMs that what works with kaffe also works with gcj/gij, kissme, sablevm, etc. If we want to think about free java not for home-only use, but so that free JVM could be distributed with variety of software (GPL-incompatible including, like Apache, Eclipse...) The Apache foundation is in talks with the FSF to try to fix the last remaining GPL-incompatibilities. We are also talking to the Eclipse Board about the issues with the CPL when people want to combine it with code distributed under the GPL (you know, because you helped write the letter). These kind of things take a long time, but in the end it is better to make sure these kind of licensing issues are really dealt with then to work around them. I'd argue that GPLed JVM is not any vital choice. From any company POV it's just too dangerous to give some venture capitalists in .jp a gun to sue for breaking the GPL (and some of us wouldn't do it for moral reasons too). They should not (try to) break the GPL period. We also need to get/keep the free JVMs working on all architectures so they move to testing. This is the part where we currently need most help so if porters have a couple of minutes (or should I say hours?) please help us. Just send a mail to the debian-java mailing list. It might be just me, but I sense Kaffe-centrism here ;-) Right. When looking at gcj/gij you will see that it basically works everywhere GCC works, so free java-like support should be everywhere even if kaffe doesn't work at the moment on some platforms. But it would still be nice to get the current build failures that Arnaud posted recently to the kaffe mailinglist fixed. See this thread: http://www.kaffe.org/pipermail/kaffe/2004-February/045308.html And for NetBSD/OpenBSD: http://www.kaffe.org/pipermail/kaffe/2004-March/045330.html We all want to make free java usable and robust. But given that there's commerically-free Suns Java, we won't get far with not truly freely usable Java. That's why GNU Classpath is under GPL _with exception_, no? The reason to switch to the GPL plus a exception clause was because we merged with libgcj which was used by some developers in a couple of embedded devices that required these terms. And to be honest, when I see what the kaffe hackers accomplish and distribute under the GPL it makes me feel silly that I ever advocated releasing software under something else then the GPL proper. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [kaffe] Re: bugwatcher problems
Hi,
On Thu, 2004-01-29 at 20:42, Dalibor Topic wrote:
Ean Schuessler wrote:
As I recall (Dalibor will need to correct me here) forking a process with
pthreads just plain doesn't work. The details escape me at this point other
than the complexities of managing the relationship between the thread and the
forked process hadn't really been worked out. Of course, this is going back
to when I talked to Tim Wilkinson about the problem. For all I know, its
fixed.
Is it fixed? If not, enabling pthreads will break many, many Ant builds.
Frankly, I don't know, I haven't hacked on kaffe's pthreads threading,
so I can't claim to know much about it :(
The last thread on pthreads and kaffe I found [1] mentions that stuff
like wait run works fine with java threads under pthreads. The
FAQ.pthreads still says that exec/fork/wait doesn't work, so it may mean
Runtime.exec, I guess.
That is easy to check. Attached RuntimeExec test program works fine on
kaffe compiled with either unix-jthreads or unix-pthreads. And I think
we would have noticed if other things were really broken under pthreads.
Since it enables working with any JNI library that does blocking in
native mode (which doesn't work with jthreads) for larger frameworks
like java-gnome or eclipse I think it got at least some testing that it
doesn work for non-trivial things. And enabling it by default would help
us expose anything that might be broken.
[1] http://www.kaffe.org/pipermail/kaffe/2002-June/039992.html
Cheers,
Mark
import java.io.*;
public class RuntimeExec
{
public static void main(String[] args) throws Exception
{
Process p = Runtime.getRuntime().exec(/bin/cat);
OutputStream out = p.getOutputStream();
Writer writer = new OutputStreamWriter(out);
writer.write(Hello World!\n);
writer.write(Have a nice day!\n);
writer.close();
out.close();
InputStream in = p.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(in));
String s = reader.readLine();
while (s != null)
{
System.out.println(cat says: + s);
s = reader.readLine();
}
}
}
signature.asc
Description: This is a digitally signed message part
Re: Bug#229001: argouml: fails to start
Hi, On Thu, 2004-01-22 at 12:08, Dalibor Topic wrote: Then it's a bug in SableVM ;) Maybe refiling it under SableVM will make Gadek implement enough of Swing to make ArgoUML run ;) Speaking about Swing. Look what Graydon Hoare just committed to libgcj (will move into GNU Classpath proper soon): http://gcc.gnu.org/ml/java-patches/2004-q1/msg00241.html I've just committed the following patch, which includes several bits of work which have been independenty approved at various times in the past, reworked slightly (mostly just javadoc'd) to conform to suggestions made on approval. it represents my best current understanding and working implementation of swing buttons. it draws and interacts with the mouse under both the cairo and plain gdk graphics implementations, depending on which system property you run it with. It is only JButton at the moment, but the basic swing framework now seems to work (with multiple backends)! Volunteers for the other Swing widgets? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: bugwatcher problems
Hi, On Wed, 2004-01-14 at 12:32, Mark Howard wrote: I was hoping that some Debian Java experts might be able to help out with a couple of problems with bugwatcher (debbuggtk package). 1) Bugwatcher works with gij or blackdown java My wrapper scripts just call /usr/bin/java, since both of the above create this. This has two problems: - my programs don't work if java alternative is set to something else I got it working (more or less, there are some little issues that I have to look into) with kaffe. But not with the kaffe package from Debian. The Debian kaffe package is compiled with unix-jthreads, but gtk (java-gnome) needs pthread support. When you recompile kaffe configured --with-threads=unix-pthreads then you can play with bugwatcher like you can with gij. (Thread system unix-pthread is also needed to run e.g. Eclipse with swt/gtk bindings). What do the kaffe developers think. Should kaffe default to pthreads on systems that support it? Cheers, mark signature.asc Description: This is a digitally signed message part
Fosdem 2004 program
GNU Classpath Friends - Free Java - Fosdem 2004 program. We now have an official program for our meeting at Fosdem 2004. (February 21/22, Brussel) And an official page: http://www.fosdem.org/2004/index/dev_room_java (Abstract for all talks will be added soon to that page.) The schedule was constructed with the following contraints in mind: - Saterday morning are the keynotes. - Sunday morning is the official java track. - The Debian people have their talks Sunday morning. (We share the room with them.) - The Embedded people will probably want to attend the fbAWT talk. Saturday morning - keynotes http://www.fosdem.org/2004/index/schedule Saterday afternoon: - 14h00 - 14h50 GNU Classpath -- Core Classes for a Diversity of Free Java Virtual Machines (GNU Classpath overview and free applications/runtimes show.) by Sascha Brawer and Mark Wielaard - 15h00 - 15h50 - SableVM - the Apache of Java Virtual Machines (Motivations and technical solutions behind the SableVM Project.) by Grzegorz B. Prokopski 16h00 - 16h50 fbAWT - Direct to your buffer (Slim Abstract Window Toolkit implementation written in java that doesn't use any peer widget library, but has direct access to either a linux framebuffer or a VNC server backend.) by Stephane Meslin-Weber Sunday morning - java/X Co. tracks http://www.fosdem.org/2004/index/schedule Sunday afternoon: - 14h00 - 15h50 Packaging Free Java Applications For Free Operating Systems (Comparing different packaging projects like Debian, Gentoo, RHUG/Naoko and JPackage, and .deb best practises.) See also the Wiki: http://java.debian.net/index.php/CommonJavaPackaging by Dalibor Topic and Arnaud Vandyck - 15h00 - 17h00 Open discussions - GNU Classpath 1.0 Roadmap - Free VM/Compiler integration/cooperation - Standardization and compatibility issues signature.asc Description: This is a digitally signed message part
Re: GR: Removal of non-free
Hi, On Fri, 2004-01-02 at 20:47, Kalle Kivimaa wrote: MJ Ray [EMAIL PROTECTED] writes: I thought there were some Java systems which could go in Debian now. Is that correct? If so, why aren't those things you named in main? I have heard that the contrib Tomcat is a particular irritation to some users. I haven't checked the exact current situation but based on the debian-java posts the situation is such that Ant is almost ready to go into main. After Ant the next candidates are parts of Eclipse and Tomcat. I don't know the status of Jetty. At the moment trying to get Tomcat or Jetty to run on say Kaffe is a non-trivial task (read: I spent a few hours last weekend trying with no success on Tomcat) but - from what I've heard - possible. You might want to take a look at how Fedora handles this. For their next release they will include native (through gcj) binaries for Ant, Tomcat, some Jakarta packages and Eclipse. See: http://fedora.redhat.com/participate/schedule/ They will do that through the Naoko, Rhug and native Eclipse projects that have already made those (and lots more) traditional java projects into native binaries and shared libraries with gcj and packaged them as RPMs. See: http://people.redhat.com/gbenson/naoko/ http://sources.redhat.com/rhug/ http://sources.redhat.com/eclipse/ Basically the parts are there (Kaffe and Classpath are mature enough to run at least Ant and Tomcat) but the conversion is not trivial. This might be a good time to announce that during Fosdem next month (February 21/22 in Brussels) the GNU Classpath, Kaffe, gcj and other free java related projects share a developer room with the Debian hackers. This would be an ideal meeting to solve some long standing packaging issues. Attached is the preliminary program from our side. One addition will be a presentation by Dalibor Topic on coordinating the packaging initiatives from debian, jpackage and gentoo. I don't know yet which Debian specific presentations and/or discussions will take place. (Wouter Verhelst and Martin Michlmayr are organizing that). But attending Fosdem http://www.fodem.org/ is always fun! Cheers, Mark ---BeginMessage--- Hi all, It is official now. We will have a developer room at Fosdem (February 21/22, Brussels, Belgium) where we will be able to meet, discuss, hack and give presentations. We will be sharing that room with the Debian people so we have to coordinate a bit who does what when, but they are nice people (and some of us are Debian people) so I am sure we will manage. Also the embedded room has invited us to give a presentation on anything related to VMs on small devices or standardization issues. The preliminary program is as follows: - Official talk by Tom Tromey (not in devroom). Hopefully we can invite people who became interested in discussing gcj some more to the developer room afterwards. http://www.fosdem.org/2004/index/speakers/speakers_tromey - Possible presentation on SableVM by Grzegorz B. Prokopski (sablevm is packaged for Debian by Grzegorz himself) - Possible GNU Classpath overview presentation by Sascha Brawer and me. Abstract attached. (It is a bit technical now, to make it more appealing to others we could probably make this into a showcase of applications and VMs that shows what is possible with free java replacements today.) Discussion topics (small hacker meetings): - GNU Classpath 1.0 RoadMap discussion (Mark Wielaard). - Free VM/Compiler integration/cooperation discussion (???). - Standardization and compatibility issues (Chris Gray?) People from the following projects will attend: GNU Classpath: Sascha Brawer, Michael Koch, Mark Wielaard gcj: Tom Tromey, Andrew Haley Kaffe: Dalibor Topic, Stephane Meslin-Weber, (Guilhem Lavaux) Debian: Arnaud Vandyck SableVM: Grzegorz Prokopski Wonka: Chris Gray Jaos: (Patrik Reali) IKVM: (Jeroen Frijters) Please let me know if you are going to attend, want to give a presentation and/or lead a discussion. The most interesting will be things that are also interesting for either the Debian or the embedded people. Please send suggestions before January 5 so we will have enough time to arrange things. Since we share the room with the Debian people it will probably not be possible to add more then one or two small presentations though. There will also be a key-signing party as Fosdem which I think will be good to attend to create a bigger and stronger web-of-trust. Please consider joining. For more info see also http://www.fodem.org/ Cheers, Mark P.S. I will be on vacation and away from my mail this week, but will make sure to read all suggestions next weekend and make a final program as soon as possible when I return. P.P.S Please feel free to invite people from related projects (share and forward away!) GNU Classpath -- Core Classes for a Diversity of Free Java Virtual Machines The goal of GNU Classpath is to provide an implementation of the core class libraries for the Java language
Re: Bug Status of Kaffe
Hi, On Sat, 2003-12-27 at 23:51, Kalle Kivimaa wrote: Umm, based on the current (1.1.1-5.2) Kaffe changelogs, not all of them are closed. The latest upstream changelog entry is from 2003-08-03 whereas bug #207998 is fixed with changelog entry of 2003-10-06. BTW. Why is Debian using such an old version of kaffe? 1.1.2 was released on 7 Oct 2003. 1.1.3 was released on 7 Dec 2003. Kaffe is really getting much better and covering more and more packages and free java programs with each release. Are there bugs in the newer versions that prevent them from being packaged for Debian? Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse
Hi, On Sun, 2003-11-30 at 19:23, Victor Niebla wrote: Hi all, has someone succeded on building and using Eclipse with Free Vm (like sablevm or kaffe) + Classpath ??? Sure. It works with most of the free runtimes now. You have your choice of: - mono + ikvm.net http://weblog.ikvm.net/PermaLink.aspx/894943be-451e-4d6c-a692-77119eb02d06 (2.1 only as far as I know, but IKVM.NET follows GNU Classpath quite closely so getting 3.0M4 working should not be that difficult.) - kaffe Kaffe from CVS (will become 1.1.3 in one/two weeks) can run Eclipse 2.1 out of the box. 3.0M4 needs some patches (that might or might not make it for 1.1.3): http://www.kaffe.org/pipermail/kaffe/2003-October/044313.html - gij (GNU Interpreter for Java which comes with gcj) Can run both 2.1 and 3.0M4 with some patches to the current CVS tree (which will become gcc 3.4). See: http://gcc.gnu.org/ml/java/2003-11/msg00024.html You can also mix and match the above and run Eclipse itself with gij, but your own projects from Eclipse with kaffe: http://www.klomp.org/mark/classpath/eclipse-gcj-kaffe.png Or combine it with the java-gnome bindings and the Eclipse project wizard plugin to get a nice free Gnome development environment: http://www.klomp.org/mark/classpath/eclipse-gnome-gij.png The only complete free build that I know of is the RedHat native eclipse (2.1) source RPMs. The build process takes a long time, but then you have a very, very fast eclipse. And it can also be used on Debian systems. http://sources.redhat.com/eclipse/ Hints to get the JDT working out of the box on Debian unstable/x86 with the above RPMs can be found at: http://sources.redhat.com/ml/eclipse/2003-q3/msg00068.html Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Undistributable java in main
Hi, On Thu, 2003-10-30 at 11:32, Dalibor Topic wrote: Jan Schulz wrote: * Dalibor Topic wrote: * figure out how you want to interpret the GPL in this case. The rest follows from that. Problems not touched: *execution* of GPL-incompatible code using GPLed libs and/or GPLed JVMs is beyond the scope of this message. Could you please take this two thing to debian-legal and get a opinion there. Agreed. That would be a good idea to do. But be careful when you talk about linking or execution. When talking about creating works under the GPL you are better off when you use derived work or work based on the program since that is what the GPL talks about. (Although linking is of course in almost all cases creating a work based on the program, but in the end it is a judgment call.) In almost every case it is best to get a clear statement of copyright holder on how to interpret their license, but also keep in mind that if a case ever comes in front of a judge the literal text of a license is also very important. And remember that besides arguing about interpretations of licenses there are also alternative solutions such as Red Hat demonstrated. The RHUG project for example provides a long list free java software works that have been made to work with the gcj environment (which gives the additional benefit of a nice speedup and real library sharing since libgcj.so is a normal shared library and not a bunch of byte codes that have to be interpreted/jitted each time your traditional java environment starts up). See http://sources.redhat.com/rhug/ for the list of available applications (which include Ant, Tomcat and lots of jakarta stuff). There are also RPMs available through the Naoko project, see http://people.redhat.com/gbenson/naoko/ Maybe this can be used as basis for Debian main packages. 1051 GPLd Java apps. By far the most popular license for Java apps. [...] I hate licenses... Don't agree. GPL is quite nice for me, the trouble is that the rest of the world sometimes uses something incompatible and then we have to play lawyers to decide what's allowed and what not ;) I agree that the GPL is a very nice way to distribute my programs. The problem we are facing at the moment is, like Grzegorz already said, similar to the old KDE mess. People like to use the GPL for their own programs or for works based on GPLed works, but sometimes fail to realize that when they also base that work on GPL-incompatible licenses (such as the Common Public License or the Apache License) that, like in the old KDE/QT case, their work becomes undistributable (unless they can give an explicit exception to the GPL for their work and the non-GPL compatible work). GPL and licenses that add extra restrictions to the freedoms of the user receiving the application/source just doesn't mix. Luckily the most important other java related license/projects can probably be convinced to help us clear this up. The FSF and the Apache project, which has a lot of nice free java software libraries, hopes that a next version of the Apache license that they are now working on will become GPL compatibl. And after the GNU Classpath workshop at Linux-kongress we briefly talked with Michael Tiemann who is on the Eclipse board and who at least understood what the problem was that the CPL that is used for Eclipse (and the SWT) library causes people who just want to create GPLed works. If you have contacts with developers using either the CPL or the Apache license then you might want to bring up this point since it would help the free java in Debian main situation a lot. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi Jan, On Sun, 2003-09-07 at 13:31, Jan Schulz wrote: Do you have a better name for 'programm, which runs java byte code'? for me 'java' stands for exactly this and I don't midn if it is actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java I would call it byte code interpreter then. Try to avoid the java name a bit since Sun claims a trademark on it. And it make it more clear that it is only one part of the environment that people might want. (The others being a byte code or native compiler and a core class library.) Not if you use the native gcj version. Yes, *if* I do that. Currently I have not done it and this proposal is not about compile to native. But I also pointed out how to get it working with a traditional byte code interpreter http://www.klomp.org/mark/gij_eclipse/. The point that I am trying to make is not that you should do it all by compiling to native applications and libraries (even though I think that will be the future). If you think that goes to far, to fast then everything that works by compiling to native code will also work by compiling to byte code and then use a free byte code interpreter. When you do that you might get a better policy. Just look at what free applications and libraries there are written in the java programming language and see what is possible at this moment with free tools that Debian can actually package and distribute. That is why is suggest you look into how all the following things are now possible with free VMs, compilers and libraries: - bcel - bouncy castle, - bsf - jakarta-commons - java-cup - ecj - gnu.regexp - ant - log4j - jasmin, - junit - jdbc-drivers - rhino - xalan - xerces - gnu.readline - log4j - oro - struts - tomcat - jython - mx4j - eclipse Except for Eclipse all these things are buildable on a recent Debian system (and as I also pointed out earlier, Eclipe can be run with the gij that Debian currently distributes with only a minimal patch. And the next kaffe version will also at least start it up. Just look at rhug for sources http://sources.redhat.com/rhug/ or http://people.redhat.com/gbenson/naoko/ for Red Hat packages. Eclipse takes a bit more work, but a simple way to at least get an idea how it would work on a Debian system is given in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html The reason I am repeating this (since I know I have pointed this out in earlier emails) is that I truely believe that by studying how this works on a complete free system gives you a much better starting point for a new Debian java policy. I would be glad to help with anything that involves gcj or the Classpath class library (and even kaffe) which doesn't seem to work correctly with the packages above. The only thing I say is, that nothing can tell me, where /usr/bin/java points to. Eclipse needs (still) a unfree VM No, it doesn't. I have it running on the Deebian system I am writing this email on and I have no non-free software installed on it. Please try it out. I am sure there are bugs and things to improve, but it does run! And I would be happy to help clear up any bugs that people find with it. , so if /usr/bin/java is sableVM, I will get a nice bugreport that 'eclipse doesn't work'. Under the current policy (BTW, have you read it?), the only thing I can do about this is 'set JAVA_HOME' and close the bug. This is why I suggest you drop the /usr/bin/java and /usr/bin/javac alternatives. They give more trouble then they are worth IMHO. But I will read up on the old policy. Most java apps are designe for this unfree VMs. If a app 'wants' a unfree one, we can do two things: satisfy this depends (- unfree interface) and test whether a less complete VM will also work. If you have a different naming, please say so. I'm also not satisfied with this names... I would just call them free vm/compiler/library implementations versus non-free ones. Then just reverse the two choices. Test whether the application or library that Debian wants to package works with a free vm/compiler/library combination. If yes - set the dependencies right to show you have tested the package with that particular combination. If no - it cannot be part of Debian and users will probably be better of installing the upstram source anyway together with some proprietary non-free vm/compiler/library combination. ot of the box, they work with the VMs, which are stated in the readme/webpage. So we can assume that a package will work with one of the 'unfree interface' versions. If we get that for free, I don't se ethe point in denying this fact to the user. Since the user doesn't get that for free. They have to install non-free proprietary software which they cannot use according to the DFSG. They might even have to accept licensing terms which make it impossible to help others working on free replacements! Any proposals? IMO the above is good enough for debian java policy. As the proposal says, /usr/bin/java is not
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi Jan, On Sun, 2003-09-07 at 13:31, Jan Schulz wrote: Do you have a better name for 'programm, which runs java byte code'? for me 'java' stands for exactly this and I don't midn if it is actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java I would call it byte code interpreter then. Try to avoid the java name a bit since Sun claims a trademark on it. And it make it more clear that it is only one part of the environment that people might want. (The others being a byte code or native compiler and a core class library.) Not if you use the native gcj version. Yes, *if* I do that. Currently I have not done it and this proposal is not about compile to native. But I also pointed out how to get it working with a traditional byte code interpreter http://www.klomp.org/mark/gij_eclipse/. The point that I am trying to make is not that you should do it all by compiling to native applications and libraries (even though I think that will be the future). If you think that goes to far, to fast then everything that works by compiling to native code will also work by compiling to byte code and then use a free byte code interpreter. When you do that you might get a better policy. Just look at what free applications and libraries there are written in the java programming language and see what is possible at this moment with free tools that Debian can actually package and distribute. That is why is suggest you look into how all the following things are now possible with free VMs, compilers and libraries: - bcel - bouncy castle, - bsf - jakarta-commons - java-cup - ecj - gnu.regexp - ant - log4j - jasmin, - junit - jdbc-drivers - rhino - xalan - xerces - gnu.readline - log4j - oro - struts - tomcat - jython - mx4j - eclipse Except for Eclipse all these things are buildable on a recent Debian system (and as I also pointed out earlier, Eclipe can be run with the gij that Debian currently distributes with only a minimal patch. And the next kaffe version will also at least start it up. Just look at rhug for sources http://sources.redhat.com/rhug/ or http://people.redhat.com/gbenson/naoko/ for Red Hat packages. Eclipse takes a bit more work, but a simple way to at least get an idea how it would work on a Debian system is given in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html The reason I am repeating this (since I know I have pointed this out in earlier emails) is that I truely believe that by studying how this works on a complete free system gives you a much better starting point for a new Debian java policy. I would be glad to help with anything that involves gcj or the Classpath class library (and even kaffe) which doesn't seem to work correctly with the packages above. The only thing I say is, that nothing can tell me, where /usr/bin/java points to. Eclipse needs (still) a unfree VM No, it doesn't. I have it running on the Deebian system I am writing this email on and I have no non-free software installed on it. Please try it out. I am sure there are bugs and things to improve, but it does run! And I would be happy to help clear up any bugs that people find with it. , so if /usr/bin/java is sableVM, I will get a nice bugreport that 'eclipse doesn't work'. Under the current policy (BTW, have you read it?), the only thing I can do about this is 'set JAVA_HOME' and close the bug. This is why I suggest you drop the /usr/bin/java and /usr/bin/javac alternatives. They give more trouble then they are worth IMHO. But I will read up on the old policy. Most java apps are designe for this unfree VMs. If a app 'wants' a unfree one, we can do two things: satisfy this depends (- unfree interface) and test whether a less complete VM will also work. If you have a different naming, please say so. I'm also not satisfied with this names... I would just call them free vm/compiler/library implementations versus non-free ones. Then just reverse the two choices. Test whether the application or library that Debian wants to package works with a free vm/compiler/library combination. If yes - set the dependencies right to show you have tested the package with that particular combination. If no - it cannot be part of Debian and users will probably be better of installing the upstram source anyway together with some proprietary non-free vm/compiler/library combination. ot of the box, they work with the VMs, which are stated in the readme/webpage. So we can assume that a package will work with one of the 'unfree interface' versions. If we get that for free, I don't se ethe point in denying this fact to the user. Since the user doesn't get that for free. They have to install non-free proprietary software which they cannot use according to the DFSG. They might even have to accept licensing terms which make it impossible to help others working on free replacements! Any proposals? IMO the above is good enough for debian java policy. As the proposal says, /usr/bin/java is not
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi, I am afraid we are not communicating very constructively. We might have to start from scratch since somehow we keep missing each others points. Let me try one last time to point out what I find important facts when deciding how to create a java policy for Debian. On Mon, 2003-09-08 at 20:15, Jan Schulz wrote: Yes, *if* I do that. Currently I have not done it and this proposal is not about compile to native. But I also pointed out how to get it working with a traditional byte code interpreter http://www.klomp.org/mark/gij_eclipse/. But this is completely besite the point that we are here discussing a policy for using 'java byte code interpreters'. If you want to have 'compiled to native' java packages, then file a bug against the packages, which you want and ask the maintainer to do it. Packages, which will do that will use the normal debian policy to do it. Sorry? Above I explain how to get eclipse running with an INTERPRETER since you seem to like that more but you keep on arguing against native compiled code. Immediately after this paragraph you quote I say: The point that I am trying to make is not that you should do it all by compiling to native applications and libraries (even though I think that will be the future). If you think that goes to far, to fast then everything that works by compiling to native code will also work by compiling to byte code and then use a free byte code interpreter. When you do that you might get a better policy. Just look at what free applications and libraries there are written in the java programming language and see what is possible at this moment with free tools that Debian can actually package and distribute. Why do you ignore that? After that I show which kind of things are currently possible with free vms. And that this can almost all be done on a current Debian system (since I have done it myself). On a recent Debian system just checkout rhug http://sources.redhat.com/rhug/ and do a ./configure make. the 'unfree interface' versions. If we get that for free, I don't se ethe point in denying this fact to the user. Since the user doesn't get that for free. They have to install non-free proprietary software which they cannot use according to the DFSG. They might even have to accept licensing terms which make it impossible to help others working on free replacements! And? If the users chooses to do so, it's their choice. I don't think that we should *force* them not to. I didn't say that you should force anybody to do anything. I just pointed out that there is a cost associated with the choice. A cost that I think is to high for people who choose Debian because of the DFSG. That is a good starting point. I am sure that I or other gcj hackers would love to help you make the gcj compiled eclipse the best eclipse out there. Please bring on the bug reports! I will do that, once I have time again to spend a complete weekend on that. And after all the RH patches have made it into the gcc in unstable. Note that for almost everything besides eclipse (the long list of 20+ programs/libraries that you also just ignored) can already be compiled with the gcj that is currently in Deebian (that includes tomcat, ant and all their dependencies). And for an interpreted eclipse you need only one missing patch to libgcj. Currently almost every java app is in contrib: eclipse, tomcat, ant. All the examples you list can soon move into main if the packagers make them work and test with free implementations. If Red Hat can do this, why can't Debian? Because RH pays someone for this work? No, rhug and the naoko packaging work are volunteer projects. Red Hat did have some people who worked on the compiler to get Eclipse running though. I will not simple drop eclipse into main until I think it will work as good as I expect it. 'just startup' is not good enough. Have you even tried it? If their are real bugs running it I would love to hear about them. I am not a heavy eclipse user myself (heay, we have Emacs :) so bug reports from users like yourself would be very helpful. Really, it takes less then half an hour to get an impression of how good the system is if you just follow the 5 easy steps pointed out in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html Yes, because tomcat and eclipse build-depend on BD java. Then those packages are currently not part of Debian... I don't see your point. But they still have to comply to the debian policy and in this case the debian java policy. You seem to be satisfied with a policy that is only really useful for contrib and non-free. Two things which are not part of Debian (and which I personally have never even used). So lets just agree to disagree on the importance of this policy. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: JAVA_HOME and ant (was: [PROPOSAL] New Virtual Packages and way to handle Classpath)
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
Ok, I don't actually mind. The only real argument I have is that it
looks better, if you have all requirements defined with comandline
arguments, not environment variables. But ok... neither gij-3.0 nor
gij-wrapper-3.0 have a -classpath option... What a --ing mess.
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
ant is IMO one of the important packages,
which should be made working out of the box.
Have you looked at how the Red Hat people have done it in Rhug or Naoke?
http://sources.redhat.com/rhug/
http://people.redhat.com/gbenson/naoko/
BTW: I think that ant in main will not work, when there is a javadoc
task specified in the build.xml. Don't know if that counts as a RC
bug...
* Javac isn't a problem, as it uses Class.forName() for almost
everything or simple assumes, that the binary is in the path. Can be
made working with alternatives, by specifying a classpath wihich
include the build.compiler.
Would it be a good idea to write a wrapper class that can be called by
the traditional Class.forName() contruct but that just invokes the
wanted compiler?
* Almost all other tasks (cvs, zipper, etc) rely on the fact that the
binary is in the path.
Which binary?
* Javah relies on a special sun.com...javah.Main class. Doesn't matter..
gcj comes with gcjh which should be able to do everything javah does
(given the -jni flag).
* some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home
or java.home/../ - big problem, if that binary doesn't exist
I don't know of a free jarsigner compatible program. But as far as I
know most (all?) free core library implementations don't implement jar
verification at all.
* javadoc relys on the fact that there is a 'bin/javadoc' in java.home
or in java.home/../. - big problem, if that binary doesn't exist.
gjdoc (which is packaged for Debian both as a traditional byte code
distribution as a normal application gjdoc-native) should be command
line compatible with javadoc.
For the last two problems see the JavaEnvUtils class.
A quick look at that class suggests that it makes all kinds of
assumptions about what class availability says about versions and the
availability of other classes. It should probably be patched to test for
more features and make less assumptions of what is/isn't available.
The problem is, that we can't really patch ant to use /usr/bin/ as a
it also uses some specific tests (mainly, whether some classes are
available in the Classpath) to determine, which version javadoc is and
set special options wich only works with that version.
Why can't we patch ant to learn it about other javadoc like programs and
which options can be used with it?
I have no idea, how we will work around this. There are several
options, which come to mind:
* Patch all VMs, so that java.home points to the right dir, which
includes this commands in the right version (symlinks, Depends:).
Why should a VM provide all the applications? I know kaffe tries to do
this and to a lesser extend gcj comes with a couple of standard java
development tools. But most VMs can probably rely other free
implementations of these tools.
* add a facade around every javadoc and java and submit a *big* patch
to ant. Same idea as javac task. Cleanes sollution, but probably not
manageable by debian-java.
Still this seems to be the solution to make Ant really work with other
free software solutions. It will be much work though and needs
cooperation with upstream to really work.
* patch ant, to include /usr/bin in the search path for any command.
Would also mean, that we have to patch ant so that it always results
in a special interface (- java Version) and make wrappers for the
commands, so that they don't fail if that interface is used.
This might also work. But seeeing that the /usr/bin/java/javac wrappers
aren't that helpfull in practice I don't know if it will be more helpful
for the other applications.
* patch ant, so that the algo for choosing a javadoc (and bin/java) is:
return, as a last option, the debian javadoc in /usr/bin. Example:
if (version == 1.4){
return /usr/bin/javadoc-1.4;
else if (...) {...}
This again confuses the version number with the features a VM,
Classlibrary and the different tools offer.
Oups, also not possible (all of this properties are used by ant...)
--8-:- snip -:-8-:- snip -:-8--
[...]
--8-:- snip -:-8-:- snip -:-8--
Can anyone test, what kaffe 1.1.1 sets as java.home?
For gcj. All system properties, their defaults and what they are used
for are described in the manual:
http://gcc.gnu.org/onlinedocs/gcj/System-properties.html
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi, I am one of the GNU Classpath developers but not a Debian developer. On Sat, 2003-09-06 at 01:47, Jan Schulz wrote: Chapter 2. Policy Packages written in Java are separated in two categories: programs and libraries. Programs are intended to be run by end-users. Libraries are intended to help programs to run and to be used by developers. Both are shipped as Java bytecode (*.class files, packaged in a *.jar archive) and with an Architecture: all since Java bytecode is supposed to be portable. It may additionally be shipped as machine code, as produced for example by the GNU Compiler for Java, in a separate architecture-specific package. For end-user programs I think it would be a good idea to mention that gcj can be used to compile programs written in the java language into normal native binaries that are quicker to run and startup. For the end user it doesn't matter that it can also be compiled to byte-code and interpreted during runtime. 2.1. Java virtual machines and runtime environments Java virtual maschines and java runtimes environments are tightly linked, so it makes no sense to seperate them. Therefore only the java runtime environment is used to describe the command java. As it is nearly impossible to treat all java virtual maschines the same, JVMs are seperated into two kinds: sun compatible and not. How is sun compatible defined? What specs should a vm/runtime implement to be regarded sun compatible? Packages should access sun compatible java virtual maschiens via the described unfree interfaces below. If it is a unfree interface should it be mentioned at all in a official Debian main policy? Other virtual maschines should be tested seperatly and, if the VM can be used to run the code, then accesed via their main binary, not via the alternative system. So the alternative system is only usable with non-free VMs? 2.1.1. bin/java A alternative for /usr/bin/java and the corresponding manpage should be setup by every package, which provides java2-runtime. This comand should not be used by any debian package. s/comand/command/ What should a package satisfy to be able to provide java2-runtime? All java virtual maschines must setup a dir struckture in /usr/lib/name (where name is the version of the virtual maschine) with this content: bin/java, which is a symlink to the virtual maschine binary. They must set the java.home property to /usr/lib/name. All java virtual maschines must depend on java-common. What does java-common provide? 2.1.2. bin/java unfree interface I would remove this section if you include it in Debian main. 2.1.3. JNI library path Some Java classes implement their routines using a native language (such as C). This native code is compiled and stored in dynamic libraries (such as JNI modules) that are loaded at runtime. If a virtual machine supports native code, it must include the directory /usr/lib/jni in its search path for these dynamic libraries, even if that has to be setup via a wrapper scripts. Are there any other requirements? Should /lib and /usr/lib be searched or not for example? 2.2. Java Development Tools As there is almost no control over different java compilers, package should only use ant to compile and build java packages, but not javac directly. The ant build.compiler is handled via the java-config system (see below). For java development kits, which aren't distributable by debian the unfree interface for ant environments should be used. Ant is used by some packages, but why mandate that ant must be used? Have you looked at how Rhug handles this? It has a more traditional auto* setup to make compiling lots of packages (bcel, bouncy castle, bsf, jakarta-commons, java-cup, ecj, gnu.regexp, ant, log4j, jasmin, junit, jdbc-drivers, rhino, xalan and xerces) with gcj easy. If debian adopted the rhug way then all the above packages would instantly go into main. 2.2.1. Ant Environment Packages, which can be used with ant to compile java code must setup a directory structure in /usr/lib/name (where name is the name of the corresponding virtual maschine (see above)), which includes bin/javadoc, which should be of the same API version as the virtual maschine, includes and includes/linux, with the JNI header files. I would try to separate the API version (which will bee hard enough to define precisely given that most free vms don't explicitly follow the API versions as defined by sun) and the version/command-line options that the javadoc like program must have. They also must include a java-config file (see below) which includes the variable declaration for JAVA_HOME, which points to /usr/lib/name, ANT_BUILD_COMPILER with the name or full qualified classname of the java compiler and the JARS entry, with the jars needed to run this java compiler. Why a fully qualified classname and jars? It won't be that hard to create wrapper classes that call the binary that the package want
Re: JAVA_HOME and ant
Hi, On Sat, 2003-09-06 at 17:29, Jan Schulz wrote: * Mark Wielaard wrote: gij does come with a normal long-option --classpath. But as the gij help output says: Options can be specified with `-' or `--'. --8-:- snip -:-8-:- snip -:-8-- [EMAIL PROTECTED]:/$ gij-3.0 --help Usage: gij [OPTION] ... CLASS [ARGS] ... to interpret Java bytecodes, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file -DVAR=VAL define property VAR with value VAL --helpprint this help, then exit --ms=NUMBER set initial heap size --mx=NUMBER set maximum heap size --version print version number, then exit --8-:- snip -:-8-:- snip -:-8-- Try gij-3.3: $ gij-3.3 --help Usage: gij [OPTION] ... CLASS [ARGS] ... to interpret Java bytecodes, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file --cp LIST set class path --classpath LIST set class path -DVAR=VAL define property VAR with value VAL --helpprint this help, then exit --ms=NUMBER set initial heap size --mx=NUMBER set maximum heap size --showversion print version number, then keep going --version print version number, then exit Options can be specified with `-' or `--'. See http://gcc.gnu.org/java/ for information on reporting bugs * Javac isn't a problem, as it uses Class.forName() for almost everything or simple assumes, that the binary is in the path. Can be made working with alternatives, by specifying a classpath wihich include the build.compiler. Would it be a good idea to write a wrapper class that can be called by the traditional Class.forName() contruct but that just invokes the wanted compiler? There are already wrapper classes for jikes, kjc and so on. basicly the algo is like this: if default, then use sun...javac.Main if 'shortname', then use wrapperclasses around the compilers if 'classanme', then use Class.forName() and call execute (or so). All compilers I know should be satisfied by that. OK. I am not a big Ant user. gcj needs a -C option to compile to byte code though. Or a --main package.MainClass and -o binary.name option for compiling to native code. * Javah relies on a special sun.com...javah.Main class. Doesn't matter.. gcj comes with gcjh which should be able to do everything javah does (given the -jni flag). But as it is now, it won't be useable form ant. Or does gij include the sunjavah.Main class? No. It is a normal program written in C. In principle gcj doesn't implement undocumented classes. * some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home or java.home/../ - big problem, if that binary doesn't exist I don't know of a free jarsigner compatible program. But as far as I know most (all?) free core library implementations don't implement jar verification at all. jarsigner is IIRC only usefull for applets. And other programs that assign protection domains to dynamicly loaded byte code classes. But I don't know of any free implementations. It shouldn't be that hard to write though if there is demand. For the last two problems see the JavaEnvUtils class. A quick look at that class suggests that it makes all kinds of assumptions about what class availability says about versions and the availability of other classes. It should probably be patched to test for more features and make less assumptions of what is/isn't available. Yes, but to make this policy os do something else is IMO not possible. Especially, if we have to consider, that ant should behave 'normaly', when used to develop java apps in, for example, eclipse. How do you define normally? If Ant can only work correctly with non-free programs or VMs then it isn't really useful for main is it? * Patch all VMs, so that java.home points to the right dir, which includes this commands in the right version (symlinks, Depends:). Why should a VM provide all the applications? I know kaffe tries to do this and to a lesser extend gcj comes with a couple of standard java development tools. But most VMs can probably rely other free implementations of these tools. So from debians POV, it shouldn't be a problem to 'construct' such 'ant environments'. Note that not the Virtual maschien should provide all this tools but a 'ant environment'. See the 3 attempt of my proposal. OK. It is just that I am not such a big Ant user so I have some difficulties seeing how this works. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi Jan, On Sat, 2003-09-06 at 22:26, Jan Schulz wrote: The problem in debian is to find out this java. This should be adressed in this proposal. Why this fixation on this one program name? I know there is a non-free environment called java that is a interpreter, byte code definition, class library specifications, development tools (RMI compiler, jarsigner, api documentation generator, etc) language to write programs in, native binary linking (JNI) etc. Since I have been working for a couple of years on free alternative for a part of this (GNU Classpath concerns itself only with what we call core classes that are essential for such an environment) I know that there is much work to do if we want to have a completely similar set of things. I personally think that trying to match this piece by piece, library by library, spec by spec will not buy the free software community that much. I do think that it will be nice to have an free environment that is similar enough and provides similar tools (and hopefully better improved variants) that can be used by people to produce new exciting free software applications or to migrate away from these proprietary tools. And I think we have much of that already. I hope that debian concentrates on this migration path. I think it would be a good idea to set some sort of policy for this. See e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have the gjdoc version that depends on byte code when there is already a normal native application? Becasue the gjdocs package will do the job fast than the native compiled gjdoc? I don't want to start a flamewar, and I haven't looked into this *at all* (only seen a discussion about some benchmarks, which said, that IBM java is faster than gcj). Having benchmarks helps (although you should always verify what they exactly mean). I made some benchmarks recently for the free VMs out there: http://www.klomp.org/mark/free-vm-benchmarks/ It doesn't benchmark any proprietary tools, but it contains links to some benchmarks that do like: http://www.spindazzle.org/benchmarks/ Which shows that gcj is at least comparable with (and sometimes much faster then) the proprietary VM from IBM. This proposal tries to eliminate the problem how to get a working java-command, which is able to run the java application. It also adresses the build environemnt, so that java packages can be compiled to java byte code and so on. Which is a good goal. But I am puzzled why you think you need to recommend and advocate proprietary tools for that. I have no idea, how far you've looked into the current implemntation to make this possible, so I just give you some of my impressions, from packaging eclipse. * Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might change that, but I haven't looked into that. gij is not AFAIK (yet)) CVS and 1.1.1 definitely improves on that: http://www.klomp.org/mark/kaffe-eclipse.html (Thanks to Helmer Kreamer! Not perfect and not as usable as with gcj, but at least it starts up.) * eclipse more or less relies on the fact, that a) JAVA_HOME is set (can be done in a rc file in $HOME) b) /usr/bin/java points to a possible JVM Not if you use the native gcj version. In the past I got Eclipse working with gij (interpreted) http://www.klomp.org/mark/gij_eclipse/ All patches, except for disabling the byte code verifier are already included in gcj 3.3, which Debian unstable ships. It must be possible to come up with a patch for gij to disable the byte code verifier through the command line. And the (fast) native eclipse can also run on Debian as I showed in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html (Yes, you need some unpackaged gcj for that, but gcj 3.4 which will be released in a couple of months will have all the needed patches.) I agree that Eclipse needs to have some patches to work nicely with alternative java like environments, but most of it works out of the box with gcj and kaffe now. As the /usr/bin/java alternative is only 'protected' by 'java?-runtime', I can't be sure, what VM I will get, when I call this binary. More or less, thsi results in a compelte mess. Debian is also famouse for teh fact that, if I install a package and the packeg instaleld correctly, this package will work. Given the above facts, this is not working. This looks like a problem only made worse by the java-policy since that says that there must be a /usr/bin/java program. Normal packages should not rely on that and should work out of the box when installed. I don't completely follow why you think that installing some random proprietary non-free, non-debian package will suddenly break normal packages unless those packages have bugs (like depending on /usr/bin/java while they shouldn't). The 'unfree interface' is a way to access unfree JVM. It's also a attempt to seperate 'incomplete' (spec and API wise) JVM from complete ones. Which is a silly
Re: JAVA_HOME and ant (was: [PROPOSAL] New Virtual Packages and way to handle Classpath)
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
Ok, I don't actually mind. The only real argument I have is that it
looks better, if you have all requirements defined with comandline
arguments, not environment variables. But ok... neither gij-3.0 nor
gij-wrapper-3.0 have a -classpath option... What a --ing mess.
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
ant is IMO one of the important packages,
which should be made working out of the box.
Have you looked at how the Red Hat people have done it in Rhug or Naoke?
http://sources.redhat.com/rhug/
http://people.redhat.com/gbenson/naoko/
BTW: I think that ant in main will not work, when there is a javadoc
task specified in the build.xml. Don't know if that counts as a RC
bug...
* Javac isn't a problem, as it uses Class.forName() for almost
everything or simple assumes, that the binary is in the path. Can be
made working with alternatives, by specifying a classpath wihich
include the build.compiler.
Would it be a good idea to write a wrapper class that can be called by
the traditional Class.forName() contruct but that just invokes the
wanted compiler?
* Almost all other tasks (cvs, zipper, etc) rely on the fact that the
binary is in the path.
Which binary?
* Javah relies on a special sun.com...javah.Main class. Doesn't matter..
gcj comes with gcjh which should be able to do everything javah does
(given the -jni flag).
* some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home
or java.home/../ - big problem, if that binary doesn't exist
I don't know of a free jarsigner compatible program. But as far as I
know most (all?) free core library implementations don't implement jar
verification at all.
* javadoc relys on the fact that there is a 'bin/javadoc' in java.home
or in java.home/../. - big problem, if that binary doesn't exist.
gjdoc (which is packaged for Debian both as a traditional byte code
distribution as a normal application gjdoc-native) should be command
line compatible with javadoc.
For the last two problems see the JavaEnvUtils class.
A quick look at that class suggests that it makes all kinds of
assumptions about what class availability says about versions and the
availability of other classes. It should probably be patched to test for
more features and make less assumptions of what is/isn't available.
The problem is, that we can't really patch ant to use /usr/bin/ as a
it also uses some specific tests (mainly, whether some classes are
available in the Classpath) to determine, which version javadoc is and
set special options wich only works with that version.
Why can't we patch ant to learn it about other javadoc like programs and
which options can be used with it?
I have no idea, how we will work around this. There are several
options, which come to mind:
* Patch all VMs, so that java.home points to the right dir, which
includes this commands in the right version (symlinks, Depends:).
Why should a VM provide all the applications? I know kaffe tries to do
this and to a lesser extend gcj comes with a couple of standard java
development tools. But most VMs can probably rely other free
implementations of these tools.
* add a facade around every javadoc and java and submit a *big* patch
to ant. Same idea as javac task. Cleanes sollution, but probably not
manageable by debian-java.
Still this seems to be the solution to make Ant really work with other
free software solutions. It will be much work though and needs
cooperation with upstream to really work.
* patch ant, to include /usr/bin in the search path for any command.
Would also mean, that we have to patch ant so that it always results
in a special interface (- java Version) and make wrappers for the
commands, so that they don't fail if that interface is used.
This might also work. But seeeing that the /usr/bin/java/javac wrappers
aren't that helpfull in practice I don't know if it will be more helpful
for the other applications.
* patch ant, so that the algo for choosing a javadoc (and bin/java) is:
return, as a last option, the debian javadoc in /usr/bin. Example:
if (version == 1.4){
return /usr/bin/javadoc-1.4;
else if (...) {...}
This again confuses the version number with the features a VM,
Classlibrary and the different tools offer.
Oups, also not possible (all of this properties are used by ant...)
--8-:- snip -:-8-:- snip -:-8--
[...]
--8-:- snip -:-8-:- snip -:-8--
Can anyone test, what kaffe 1.1.1 sets as java.home?
For gcj. All system properties, their defaults and what they are used
for are described in the manual:
http://gcc.gnu.org/onlinedocs/gcj/System-properties.html
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi, I am one of the GNU Classpath developers but not a Debian developer. On Sat, 2003-09-06 at 01:47, Jan Schulz wrote: Chapter 2. Policy Packages written in Java are separated in two categories: programs and libraries. Programs are intended to be run by end-users. Libraries are intended to help programs to run and to be used by developers. Both are shipped as Java bytecode (*.class files, packaged in a *.jar archive) and with an Architecture: all since Java bytecode is supposed to be portable. It may additionally be shipped as machine code, as produced for example by the GNU Compiler for Java, in a separate architecture-specific package. For end-user programs I think it would be a good idea to mention that gcj can be used to compile programs written in the java language into normal native binaries that are quicker to run and startup. For the end user it doesn't matter that it can also be compiled to byte-code and interpreted during runtime. 2.1. Java virtual machines and runtime environments Java virtual maschines and java runtimes environments are tightly linked, so it makes no sense to seperate them. Therefore only the java runtime environment is used to describe the command java. As it is nearly impossible to treat all java virtual maschines the same, JVMs are seperated into two kinds: sun compatible and not. How is sun compatible defined? What specs should a vm/runtime implement to be regarded sun compatible? Packages should access sun compatible java virtual maschiens via the described unfree interfaces below. If it is a unfree interface should it be mentioned at all in a official Debian main policy? Other virtual maschines should be tested seperatly and, if the VM can be used to run the code, then accesed via their main binary, not via the alternative system. So the alternative system is only usable with non-free VMs? 2.1.1. bin/java A alternative for /usr/bin/java and the corresponding manpage should be setup by every package, which provides java2-runtime. This comand should not be used by any debian package. s/comand/command/ What should a package satisfy to be able to provide java2-runtime? All java virtual maschines must setup a dir struckture in /usr/lib/name (where name is the version of the virtual maschine) with this content: bin/java, which is a symlink to the virtual maschine binary. They must set the java.home property to /usr/lib/name. All java virtual maschines must depend on java-common. What does java-common provide? 2.1.2. bin/java unfree interface I would remove this section if you include it in Debian main. 2.1.3. JNI library path Some Java classes implement their routines using a native language (such as C). This native code is compiled and stored in dynamic libraries (such as JNI modules) that are loaded at runtime. If a virtual machine supports native code, it must include the directory /usr/lib/jni in its search path for these dynamic libraries, even if that has to be setup via a wrapper scripts. Are there any other requirements? Should /lib and /usr/lib be searched or not for example? 2.2. Java Development Tools As there is almost no control over different java compilers, package should only use ant to compile and build java packages, but not javac directly. The ant build.compiler is handled via the java-config system (see below). For java development kits, which aren't distributable by debian the unfree interface for ant environments should be used. Ant is used by some packages, but why mandate that ant must be used? Have you looked at how Rhug handles this? It has a more traditional auto* setup to make compiling lots of packages (bcel, bouncy castle, bsf, jakarta-commons, java-cup, ecj, gnu.regexp, ant, log4j, jasmin, junit, jdbc-drivers, rhino, xalan and xerces) with gcj easy. If debian adopted the rhug way then all the above packages would instantly go into main. 2.2.1. Ant Environment Packages, which can be used with ant to compile java code must setup a directory structure in /usr/lib/name (where name is the name of the corresponding virtual maschine (see above)), which includes bin/javadoc, which should be of the same API version as the virtual maschine, includes and includes/linux, with the JNI header files. I would try to separate the API version (which will bee hard enough to define precisely given that most free vms don't explicitly follow the API versions as defined by sun) and the version/command-line options that the javadoc like program must have. They also must include a java-config file (see below) which includes the variable declaration for JAVA_HOME, which points to /usr/lib/name, ANT_BUILD_COMPILER with the name or full qualified classname of the java compiler and the JARS entry, with the jars needed to run this java compiler. Why a fully qualified classname and jars? It won't be that hard to create wrapper classes that call the binary that the package want
Re: JAVA_HOME and ant
Hi, On Sat, 2003-09-06 at 17:29, Jan Schulz wrote: * Mark Wielaard wrote: gij does come with a normal long-option --classpath. But as the gij help output says: Options can be specified with `-' or `--'. --8-:- snip -:-8-:- snip -:-8-- [EMAIL PROTECTED]:/$ gij-3.0 --help Usage: gij [OPTION] ... CLASS [ARGS] ... to interpret Java bytecodes, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file -DVAR=VAL define property VAR with value VAL --helpprint this help, then exit --ms=NUMBER set initial heap size --mx=NUMBER set maximum heap size --version print version number, then exit --8-:- snip -:-8-:- snip -:-8-- Try gij-3.3: $ gij-3.3 --help Usage: gij [OPTION] ... CLASS [ARGS] ... to interpret Java bytecodes, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file --cp LIST set class path --classpath LIST set class path -DVAR=VAL define property VAR with value VAL --helpprint this help, then exit --ms=NUMBER set initial heap size --mx=NUMBER set maximum heap size --showversion print version number, then keep going --version print version number, then exit Options can be specified with `-' or `--'. See http://gcc.gnu.org/java/ for information on reporting bugs * Javac isn't a problem, as it uses Class.forName() for almost everything or simple assumes, that the binary is in the path. Can be made working with alternatives, by specifying a classpath wihich include the build.compiler. Would it be a good idea to write a wrapper class that can be called by the traditional Class.forName() contruct but that just invokes the wanted compiler? There are already wrapper classes for jikes, kjc and so on. basicly the algo is like this: if default, then use sun...javac.Main if 'shortname', then use wrapperclasses around the compilers if 'classanme', then use Class.forName() and call execute (or so). All compilers I know should be satisfied by that. OK. I am not a big Ant user. gcj needs a -C option to compile to byte code though. Or a --main package.MainClass and -o binary.name option for compiling to native code. * Javah relies on a special sun.com...javah.Main class. Doesn't matter.. gcj comes with gcjh which should be able to do everything javah does (given the -jni flag). But as it is now, it won't be useable form ant. Or does gij include the sunjavah.Main class? No. It is a normal program written in C. In principle gcj doesn't implement undocumented classes. * some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home or java.home/../ - big problem, if that binary doesn't exist I don't know of a free jarsigner compatible program. But as far as I know most (all?) free core library implementations don't implement jar verification at all. jarsigner is IIRC only usefull for applets. And other programs that assign protection domains to dynamicly loaded byte code classes. But I don't know of any free implementations. It shouldn't be that hard to write though if there is demand. For the last two problems see the JavaEnvUtils class. A quick look at that class suggests that it makes all kinds of assumptions about what class availability says about versions and the availability of other classes. It should probably be patched to test for more features and make less assumptions of what is/isn't available. Yes, but to make this policy os do something else is IMO not possible. Especially, if we have to consider, that ant should behave 'normaly', when used to develop java apps in, for example, eclipse. How do you define normally? If Ant can only work correctly with non-free programs or VMs then it isn't really useful for main is it? * Patch all VMs, so that java.home points to the right dir, which includes this commands in the right version (symlinks, Depends:). Why should a VM provide all the applications? I know kaffe tries to do this and to a lesser extend gcj comes with a couple of standard java development tools. But most VMs can probably rely other free implementations of these tools. So from debians POV, it shouldn't be a problem to 'construct' such 'ant environments'. Note that not the Virtual maschien should provide all this tools but a 'ant environment'. See the 3 attempt of my proposal. OK. It is just that I am not such a big Ant user so I have some difficulties seeing how this works. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi, On Sat, 2003-09-06 at 19:15, Jan Schulz wrote: * Mark Wielaard wrote: I am one of the GNU Classpath developers but not a Debian developer. Thanks for joining anyway :) I am a Debian user though and use it for all my development machines. For end-user programs I think it would be a good idea to mention that gcj can be used to compile programs written in the java language into normal native binaries that are quicker to run and startup. For the end user it doesn't matter that it can also be compiled to byte-code and interpreted during runtime. This would mean, that the resulting package will not use 'java' to start the programm and it would be a normal ELF binary, for which all teh rules from the debian policy apply. 'java' is a big word. Such programs still use the java programming language and a set of standard libraries. The only difference is that they don't use intermediate byte code but have a build in (by linking against libgcj) execution environment. Also, this is a policy for packaging java apps and libraries. This is not really intended to be used by users, but by debian devloper. If they choose to supply their java app as a ELF binary, thats up to them. I think it would be a good idea to set some sort of policy for this. See e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have the gjdoc version that depends on byte code when there is already a normal native application? 2.1. Java virtual machines and runtime environments How is sun compatible defined? What specs should a vm/runtime implement to be regarded sun compatible? Actually I don't really mind, as long as it works. :) This paragraph should work with three VMs: Sun, IBM and Blackdown. They are similar enought to work with them based on such a interface. Re 'spec': java-virtual-maschine-1.4 will need to implement the java spec version 1.4. As Java evolves, there will be more virtual maschiens. If java packages need tighter dependencies, more virtual packages should be proposed and used. Maybe the java policy should link to a file, which holds the current state of this virtual packages. But that means that this definition is completely useless for Debian developers since there are no packages in Debian that satisfy this definition. Packages should access sun compatible java virtual maschiens via the described unfree interfaces below. If it is a unfree interface should it be mentioned at all in a official Debian main policy? Yes. Debian social contract also says: 5. Programs That Don't Meet Our Free-Software Standards |We acknowledge that some of our users require the use of programs |that don't conform to the Debian Free Software Guidelines. [...] |Thus, although non-free software isn't a part of Debian, we support |its use, [...] That says Debian acknowledges the existince of such software (a sad fact that cannot be denied), but it doesn't say that Debian should promote and advertise such things. And this unfree interface isn't even part of contrib or non-free. I'm not happy with 'unfree interface', but thats IMO the clearest name for this interface. I think it is irrelevant to Debian since it will never be part of Debian. Other virtual maschines should be tested seperatly and, if the VM can be used to run the code, then accesed via their main binary, not via the alternative system. So the alternative system is only usable with non-free VMs? Jain: The alternative system is used to setup the 'unfree interface'. It is also used to setup the /usr/bin/java binary. Due to the fact that package, which setup a alternative for /usr/bin/java are too diffrently, we can't use this binary with package. This will give packages the chance to supply specific comandlien arguments for each regular packaged JVM and use the unfree interface. This should be 'good enough'. What do you mean 'good enough'? Good enough for what? If you insist on things supporting this unfree interface you should at least give a good definition of it in the policy so packagers can make sure they have implemented it correctly. 2.1.1. bin/java A alternative for /usr/bin/java and the corresponding manpage should be setup by every package, which provides java2-runtime. This comand should not be used by any debian package. What should a package satisfy to be able to provide java2-runtime? Basicly the same requirements as now: be a java virtual maschine. Policy never made any requirements, on java2-runtime or java1-runtime. I droped the java1-runtime, because I think that most packages will not require a java1-runtime. A java virtual machine is that an interpreter for (a specific version) of java byte code? I think that although it wasn't defined in the past it should be better defined then saying that there are basically no requirements. 2.1.3. JNI library path Some Java classes implement their routines using a native language (such as C). This native
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi Jan, On Sat, 2003-09-06 at 22:26, Jan Schulz wrote: The problem in debian is to find out this java. This should be adressed in this proposal. Why this fixation on this one program name? I know there is a non-free environment called java that is a interpreter, byte code definition, class library specifications, development tools (RMI compiler, jarsigner, api documentation generator, etc) language to write programs in, native binary linking (JNI) etc. Since I have been working for a couple of years on free alternative for a part of this (GNU Classpath concerns itself only with what we call core classes that are essential for such an environment) I know that there is much work to do if we want to have a completely similar set of things. I personally think that trying to match this piece by piece, library by library, spec by spec will not buy the free software community that much. I do think that it will be nice to have an free environment that is similar enough and provides similar tools (and hopefully better improved variants) that can be used by people to produce new exciting free software applications or to migrate away from these proprietary tools. And I think we have much of that already. I hope that debian concentrates on this migration path. I think it would be a good idea to set some sort of policy for this. See e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have the gjdoc version that depends on byte code when there is already a normal native application? Becasue the gjdocs package will do the job fast than the native compiled gjdoc? I don't want to start a flamewar, and I haven't looked into this *at all* (only seen a discussion about some benchmarks, which said, that IBM java is faster than gcj). Having benchmarks helps (although you should always verify what they exactly mean). I made some benchmarks recently for the free VMs out there: http://www.klomp.org/mark/free-vm-benchmarks/ It doesn't benchmark any proprietary tools, but it contains links to some benchmarks that do like: http://www.spindazzle.org/benchmarks/ Which shows that gcj is at least comparable with (and sometimes much faster then) the proprietary VM from IBM. This proposal tries to eliminate the problem how to get a working java-command, which is able to run the java application. It also adresses the build environemnt, so that java packages can be compiled to java byte code and so on. Which is a good goal. But I am puzzled why you think you need to recommend and advocate proprietary tools for that. I have no idea, how far you've looked into the current implemntation to make this possible, so I just give you some of my impressions, from packaging eclipse. * Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might change that, but I haven't looked into that. gij is not AFAIK (yet)) CVS and 1.1.1 definitely improves on that: http://www.klomp.org/mark/kaffe-eclipse.html (Thanks to Helmer Kreamer! Not perfect and not as usable as with gcj, but at least it starts up.) * eclipse more or less relies on the fact, that a) JAVA_HOME is set (can be done in a rc file in $HOME) b) /usr/bin/java points to a possible JVM Not if you use the native gcj version. In the past I got Eclipse working with gij (interpreted) http://www.klomp.org/mark/gij_eclipse/ All patches, except for disabling the byte code verifier are already included in gcj 3.3, which Debian unstable ships. It must be possible to come up with a patch for gij to disable the byte code verifier through the command line. And the (fast) native eclipse can also run on Debian as I showed in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html (Yes, you need some unpackaged gcj for that, but gcj 3.4 which will be released in a couple of months will have all the needed patches.) I agree that Eclipse needs to have some patches to work nicely with alternative java like environments, but most of it works out of the box with gcj and kaffe now. As the /usr/bin/java alternative is only 'protected' by 'java?-runtime', I can't be sure, what VM I will get, when I call this binary. More or less, thsi results in a compelte mess. Debian is also famouse for teh fact that, if I install a package and the packeg instaleld correctly, this package will work. Given the above facts, this is not working. This looks like a problem only made worse by the java-policy since that says that there must be a /usr/bin/java program. Normal packages should not rely on that and should work out of the box when installed. I don't completely follow why you think that installing some random proprietary non-free, non-debian package will suddenly break normal packages unless those packages have bugs (like depending on /usr/bin/java while they shouldn't). The 'unfree interface' is a way to access unfree JVM. It's also a attempt to seperate 'incomplete' (spec and API wise) JVM from complete ones. Which is a silly
Running native eclipse on Debian (unstable/x86)
Hi, Someone asked how I got native eclipse running on my Debian box and how to get the JDT (Java Development Tools) and api documentation/code completion tooltips work out of the box. The following only explains how to get the needed binaries installed. For compiling from source you will need a lot more dependencies and I have only tried compiling from source on a Red Hat system. You need to make sure that you have a recent Debian unstable installation (you need glibc-2.3.x). Then get the following RPMs: (Is there a more recent snapshot?) http://people.redhat.com/~jhealy/eclipse/snapshot-20030802-eclipse-2.1.0-12.i386.rpm ftp://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/as/i386/RedHat/RPMS/libgcc-ssa-3.5ssa-0.20030801.34.i386.rpm ftp://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/as/i386/RedHat/RPMS/libgcj-ssa-3.5ssa-0.20030801.34.i386.rpm http://people.redhat.com/~jhealy/eclipse/ lists: http://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/ws/i386/RedHat/RPMS/libgcj-ssa-3.5ssa-0.20030617.24.i386.rpm http://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/ws/i386/RedHat/RPMS/libgcc-ssa-3.5ssa-0.20030617.24.i386.rpm Which don't seem to exist anymore. Run 'alien' to turn these into: libgcc-ssa_3.5ssa-1.20030801_i386.deb libgcj-ssa_3.5ssa-1.20030801_i386.deb eclipse_2.1.0-13_i386.deb And install these with dpkg --install To make the JDT work out of the box you will need to make your /usr/bin/java binary the following script: #!/bin/sh gij-ssa -Dsun.boot.class.path=/usr/share/java/libgcj-3.5-tree-ssa.jar $* (Note that /usr/bin/java is handled by the alternative system in Debian so make sure that you know what you are doing when overriding it.) Then (optionally) if you happen to have to sources of libgcj (gcc/libjava) available (or GNU Classpath) create a src.zip file with: $ fastjar cf src.zip gnu java javax org Copy this src.zip to the root directory (yes, /). That way you get automatic API tooltip documentation while typing your program as can be seen at: http://www.klomp.org/mark/gij_eclipse/code_completion.png (Actually that is from an older version of gcj, when eclipse only ran with gij, but the idea is the same.) Cheers, Mark signature.asc Description: This is a digitally signed message part
Running native eclipse on Debian (unstable/x86)
Hi, Someone asked how I got native eclipse running on my Debian box and how to get the JDT (Java Development Tools) and api documentation/code completion tooltips work out of the box. The following only explains how to get the needed binaries installed. For compiling from source you will need a lot more dependencies and I have only tried compiling from source on a Red Hat system. You need to make sure that you have a recent Debian unstable installation (you need glibc-2.3.x). Then get the following RPMs: (Is there a more recent snapshot?) http://people.redhat.com/~jhealy/eclipse/snapshot-20030802-eclipse-2.1.0-12.i386.rpm ftp://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/as/i386/RedHat/RPMS/libgcc-ssa-3.5ssa-0.20030801.34.i386.rpm ftp://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/as/i386/RedHat/RPMS/libgcj-ssa-3.5ssa-0.20030801.34.i386.rpm http://people.redhat.com/~jhealy/eclipse/ lists: http://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/ws/i386/RedHat/RPMS/libgcj-ssa-3.5ssa-0.20030617.24.i386.rpm http://ftp.redhat.com/pub/redhat/linux/beta/taroon/en/ws/i386/RedHat/RPMS/libgcc-ssa-3.5ssa-0.20030617.24.i386.rpm Which don't seem to exist anymore. Run 'alien' to turn these into: libgcc-ssa_3.5ssa-1.20030801_i386.deb libgcj-ssa_3.5ssa-1.20030801_i386.deb eclipse_2.1.0-13_i386.deb And install these with dpkg --install To make the JDT work out of the box you will need to make your /usr/bin/java binary the following script: #!/bin/sh gij-ssa -Dsun.boot.class.path=/usr/share/java/libgcj-3.5-tree-ssa.jar $* (Note that /usr/bin/java is handled by the alternative system in Debian so make sure that you know what you are doing when overriding it.) Then (optionally) if you happen to have to sources of libgcj (gcc/libjava) available (or GNU Classpath) create a src.zip file with: $ fastjar cf src.zip gnu java javax org Copy this src.zip to the root directory (yes, /). That way you get automatic API tooltip documentation while typing your program as can be seen at: http://www.klomp.org/mark/gij_eclipse/code_completion.png (Actually that is from an older version of gcj, when eclipse only ran with gij, but the idea is the same.) Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Eclipse and main
Hi, On Tue, 2003-07-22 at 10:39, Arnaud Vandyck wrote: RHUG: http://sources.redhat.com/rhug/ really is cool. The only sad thing is that it is all build as RPMs done for RedHat systems. Would be really nice to also have real Debian packages of all his stuff. (I asked him if he would like someone to maintain debian dirs/control files for RHUG and he would definitely appreciate that.) It's impressing! Cool isn't it. I believe it is one of those public secrets that somehow nobody hears about. The fact that most of it is only available through CVS as source doesn't help to promote it much. But the gcj compiled libraries and programs are so darn fast. They recently added a natively compiled Eclipse compiler (called ecj) and the binary is faster then the jikes compiler when producing byte code from java source files! But there are now a couple of people who are trying to push some of this in Red Hat their new Severn (open public community Red Hat distribution) project. That would be really cool. But I don't really like switching from my trusty and proven distribution. So I try to push a bit for Debian packages. Maybe I should apply to be a Debian Maintainer and go through the whole process if nobody else picks this up... I do not know the ant internals but why not investigating in 'ant task' for gcj (maybe it already exists!) instead of autoconf/ automake/ make? Anthony Green (the RHug maintainer) recently suggested to do this. Traditional GNU people don't like Ant that much, but it is clear that traditional java people don't like the auto* and libtool approach that much. It must certainly be possible to come up with a real Ant task that takes the information already available to create sources to classes plus jars and Manifest files and turn it into the right invocations to gcj to build shared librararies and/or native compiled programs. Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse and main (was: junit-freenet)
Hi, On Fri, 2003-07-18 at 23:52, Jan Schulz wrote: * Mark Wielaard wrote: Helmer Krämer recently fixed some things in Kaffe to get Eclipse to startup (doesn't do much more then startup, but it is a start): http://www.kaffe.org/pipermail/kaffe/2003-July/043015.html And Eclipse of course runs with gcj: http://klomp.org/mark/gij_eclipse/ (Only one of the patches on that page hasn't made it into gcj 3.3.) Nice information. The problem will be that eclipse will start using 1.4 features after M3 (end of August) and I don't know how long it will take to 'catch up'... GNU Classpath and gcj already support large parts of 1.4. And some of the support will actually be in Eclipse itself (for example it comes with its own compiler that is used to compile its own plugins so that must support all [compiler] features the plugins actually use.) But you are right this is actually a big concern for the free software community. It would be very appreciated that as soon as Eclipse enters Debian main some people would help us either convince the Eclipse developers not to use facilities that don't have free implementations or to help us develop those facilities for use on free platforms. BTW, what is actually required to get a java app into main: Running, running in most cases or running like with Sun/BD JDK? For a program written in the java language to get into main it has to be free software of course and it should be possible to compile and/or run it with free programs also available from Debian main. For most java programs (except those using the Swing GUI library) this is now possible. The nice thing is that even something as big as Eclipse can now run using only components of Debian main. This is almost possible now (although even Debian unstable doesn't have all the latest versions of the free java like environments yet). Either through gcj/gij (it is slow, but works even for CVS team working or installing remote plugins through the Update Manager). Or kaffe (although that is buggy now and is only available through CVS now). But also through IKVM.NET which can be used to run Eclipse through Mono! Really cool, although not the fastest solution: http://weblog.ikvm.net/default.aspx?date=2003-05-10T00:00:00 (What is really exciting about this last option is that it neatly combines the java and .net/C# world. That is what I call real free software innovation. You have two proprietary platforms controlled by two companies. Each trying to keep their users/developers locked into one of the two camps. But you now also have free implementations that can actually be used by users/developers to take back their freedom and combine the best of those two worlds!) Would it make sense to split libswt2.1-gtk2-java out of 'eclipse' and get it into main? This would mean that I have to rebuild eclipse (including libswt2.1-motif-java) and libswt2.1-gtk2-java and get both from CVS, as there aren't downloads for them... I most definitely think so. This is actually what Anthony Green has been doing for RHUG http://sources.redhat.com/rhug/. For example he provides the Eclipse compiler (compiled to a native program and shared library using gcj): http://gcc.gnu.org/ml/java/2003-07/msg00193.html And he also provides a snapshot for a separate SWT build for gcj: http://gcc.gnu.org/ml/java/2002-11/msg00280.html Note that he uses gcj for everything to compile it into native code.. This has two big advantages. 1) It is amazingly fast since you don't need to startup a JVM, interpret or just in time compile byte code but just have a normal binary program. 2) Since he creates shared libraries for everything the code is actually shared between processes. So a Ant process can reuse the code of the eclipse byte code compiler that might also be used by Tomcat to compile some JSP page when running on the same system. (And yes, he actually has gcj compiled Ant and Tomcat packages!) RHUG: http://sources.redhat.com/rhug/ really is cool. The only sad thing is that it is all build as RPMs done for RedHat systems. Would be really nice to also have real Debian packages of all his stuff. (I asked him if he would like someone to maintain debian dirs/control files for RHUG and he would definitely appreciate that.) Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: additions to java-policy
Hi, On Sat, 2003-07-19 at 01:50, Ben Burton wrote: But you are fooling yourself if you claim that simply removing versioning all together will bring with it stability. The sad fact with the Java world is that if your package or app uses some Java library, you have to follow changelogs to see how that library changes with each upgrade and whether your source code needs to be upgraded accordingly. Stuart Ballard wrote some tools to help with this. japitools: Java API compatibility testing tools http://japi.sab39.org/ Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse and main (was: junit-freenet)
Hi, On Fri, 2003-07-18 at 23:52, Jan Schulz wrote: * Mark Wielaard wrote: Helmer Krämer recently fixed some things in Kaffe to get Eclipse to startup (doesn't do much more then startup, but it is a start): http://www.kaffe.org/pipermail/kaffe/2003-July/043015.html And Eclipse of course runs with gcj: http://klomp.org/mark/gij_eclipse/ (Only one of the patches on that page hasn't made it into gcj 3.3.) Nice information. The problem will be that eclipse will start using 1.4 features after M3 (end of August) and I don't know how long it will take to 'catch up'... GNU Classpath and gcj already support large parts of 1.4. And some of the support will actually be in Eclipse itself (for example it comes with its own compiler that is used to compile its own plugins so that must support all [compiler] features the plugins actually use.) But you are right this is actually a big concern for the free software community. It would be very appreciated that as soon as Eclipse enters Debian main some people would help us either convince the Eclipse developers not to use facilities that don't have free implementations or to help us develop those facilities for use on free platforms. BTW, what is actually required to get a java app into main: Running, running in most cases or running like with Sun/BD JDK? For a program written in the java language to get into main it has to be free software of course and it should be possible to compile and/or run it with free programs also available from Debian main. For most java programs (except those using the Swing GUI library) this is now possible. The nice thing is that even something as big as Eclipse can now run using only components of Debian main. This is almost possible now (although even Debian unstable doesn't have all the latest versions of the free java like environments yet). Either through gcj/gij (it is slow, but works even for CVS team working or installing remote plugins through the Update Manager). Or kaffe (although that is buggy now and is only available through CVS now). But also through IKVM.NET which can be used to run Eclipse through Mono! Really cool, although not the fastest solution: http://weblog.ikvm.net/default.aspx?date=2003-05-10T00:00:00 (What is really exciting about this last option is that it neatly combines the java and .net/C# world. That is what I call real free software innovation. You have two proprietary platforms controlled by two companies. Each trying to keep their users/developers locked into one of the two camps. But you now also have free implementations that can actually be used by users/developers to take back their freedom and combine the best of those two worlds!) Would it make sense to split libswt2.1-gtk2-java out of 'eclipse' and get it into main? This would mean that I have to rebuild eclipse (including libswt2.1-motif-java) and libswt2.1-gtk2-java and get both from CVS, as there aren't downloads for them... I most definitely think so. This is actually what Anthony Green has been doing for RHUG http://sources.redhat.com/rhug/. For example he provides the Eclipse compiler (compiled to a native program and shared library using gcj): http://gcc.gnu.org/ml/java/2003-07/msg00193.html And he also provides a snapshot for a separate SWT build for gcj: http://gcc.gnu.org/ml/java/2002-11/msg00280.html Note that he uses gcj for everything to compile it into native code.. This has two big advantages. 1) It is amazingly fast since you don't need to startup a JVM, interpret or just in time compile byte code but just have a normal binary program. 2) Since he creates shared libraries for everything the code is actually shared between processes. So a Ant process can reuse the code of the eclipse byte code compiler that might also be used by Tomcat to compile some JSP page when running on the same system. (And yes, he actually has gcj compiled Ant and Tomcat packages!) RHUG: http://sources.redhat.com/rhug/ really is cool. The only sad thing is that it is all build as RPMs done for RedHat systems. Would be really nice to also have real Debian packages of all his stuff. (I asked him if he would like someone to maintain debian dirs/control files for RHUG and he would definitely appreciate that.) Cheers, Mark
Re: junit-freenet, was Re: Bug#165504 acknowledged by developer
Hi, On Fri, 2003-07-18 at 20:42, Jan Schulz wrote: I haven't tested swt with kaffe, but I think that it should work. The problem is, that it is build from eclipse source and if that runs under kaffe is something to be investigated :( Anyway it also has motif portions, so... Helmer Krämer recently fixed some things in Kaffe to get Eclipse to startup (doesn't do much more then startup, but it is a start): http://www.kaffe.org/pipermail/kaffe/2003-July/043015.html swt based application are running really well with gcj though. See http://www-106.ibm.com/developerworks/java/library/j-nativegui2/ For a nice example see http://www.freestyler-toolkit.org/ And Eclipse of course runs with gcj: http://klomp.org/mark/gij_eclipse/ (Only one of the patches on that page hasn't made it into gcj 3.3.) Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: junit-freenet, was Re: Bug#165504 acknowledged by developer
Hi, On Fri, 2003-07-18 at 20:42, Jan Schulz wrote: I haven't tested swt with kaffe, but I think that it should work. The problem is, that it is build from eclipse source and if that runs under kaffe is something to be investigated :( Anyway it also has motif portions, so... Helmer Krämer recently fixed some things in Kaffe to get Eclipse to startup (doesn't do much more then startup, but it is a start): http://www.kaffe.org/pipermail/kaffe/2003-July/043015.html swt based application are running really well with gcj though. See http://www-106.ibm.com/developerworks/java/library/j-nativegui2/ For a nice example see http://www.freestyler-toolkit.org/ And Eclipse of course runs with gcj: http://klomp.org/mark/gij_eclipse/ (Only one of the patches on that page hasn't made it into gcj 3.3.) Cheers, Mark
Re: Getting a Java package in the distribution?
Hi, On Tue, 2003-07-15 at 13:20, Stefan Gybas wrote: D.Hansmann wrote: build a java package from source (without changing it before)? There probably won't be a speed improvement... ;) Hey, that's what free/open source software is about! :-) Think for example of security updates: They are very difficult if you don't build the package from the source code. And you never know what's inside a JAR if you don't build it yourself -- there might be non-free classes in there accidentally. Very good points. And at least for gcj (the GNU Compiler for java that comes with GCC) when you have the java language source code then you can create (optimized) native binaries which are really fast and startup immediately (since they don't need to initialize a complete JVM). I havee seen some amazing speedups from using gcj compiled binaries. Especially for programs that you want to run as batch processors (for example a XSLT transformer) that can really speed up things. See for example the (RH RPMs, sorry about that) packages at: http://sources.redhat.com/rhug/ (Now that I mentioned it, it would be nice if those could be turned into Debian packages, they would all instantly go into main, since they are build using gcj.) Cheers, Mark
Re: Eclipse
Hi, On Tue, 2002-12-31 at 20:22, Mark Howard wrote: You probably have been following your ITP report (119885) and the debian-java mailing list, but I'd just like to make sure you know that a few people have packaged this unofficially and there have been offers of advice from people at RedHat who made their packages. Hopefully you will all be able to work together and make an excellent job. I look forward to trying the results. This might be a good opportunity to point to the Eclipse on gij page: http://www.klomp.org/mark/gij_eclipse/ There is still a lot todo before Eclipse will be completely supported on the free java platforms. But what we have is a decent start. Note that we have not yet been able to compile Eclipse from source with gcj, so it is a bit premature to say that Eclipse can go into main soon. (gcj 3.3 will probably only support what can already been seen on the screenshots at the above page. And it will be at least February before it is released, maybe later. And I don't know how soon Debian will adopt GCC 3.3.) The gcj hackers are currently working very hard on the next gcj (3.3) release. But if people want to try to get more of Eclipse working with gcj/gij then please let us know at [EMAIL PROTECTED] so we can help. Most of the patches mentioned on the above page have already gone into CVS (and will be part of the 3.3 release). Cheers, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse
Hi, On Tue, 2002-12-31 at 20:22, Mark Howard wrote: You probably have been following your ITP report (119885) and the debian-java mailing list, but I'd just like to make sure you know that a few people have packaged this unofficially and there have been offers of advice from people at RedHat who made their packages. Hopefully you will all be able to work together and make an excellent job. I look forward to trying the results. This might be a good opportunity to point to the Eclipse on gij page: http://www.klomp.org/mark/gij_eclipse/ There is still a lot todo before Eclipse will be completely supported on the free java platforms. But what we have is a decent start. Note that we have not yet been able to compile Eclipse from source with gcj, so it is a bit premature to say that Eclipse can go into main soon. (gcj 3.3 will probably only support what can already been seen on the screenshots at the above page. And it will be at least February before it is released, maybe later. And I don't know how soon Debian will adopt GCC 3.3.) The gcj hackers are currently working very hard on the next gcj (3.3) release. But if people want to try to get more of Eclipse working with gcj/gij then please let us know at [EMAIL PROTECTED] so we can help. Most of the patches mentioned on the above page have already gone into CVS (and will be part of the 3.3 release). Cheers, Mark
Re: j2sdk build-depends cannot be satisfied?
Hi, On Sat, 2002-11-16 at 10:12, Kenneth Pronovici wrote: [I think this is still topical to both debian-mentors and debian-java. Someone tell me if they want it moved to one or the other...] gcj is supposed to come with a working jni implementation and comes with gij (GNU Interpreter for Java) for interpreting bytecode. What exactly doesn't work with gcj? Could you please file a bug report? http://gcc.gnu.org/bugs.html That way we at least know about the issue. Also Kaffe, Kissme and SableVM (all part of Debian now) should be able to run java byte code and jni code. Wow. I'm fairly impressed. It didn't take a lot of screwing around to make this work. I had to go with gcj-3.2, and that forced me to go with gcc-3.2 as well, and then I used fastjar to build the jarfiles. I attempted to use gjdoc for Javadoc, with only limited success (more on that later). Anyway, I'm glad you suggested that I look into this. :-) gjdoc is still very alpha level code. I think your best bet is the gjdoc-native package (gjdoc compiled with gcj to native code) but I have to admit that I didn't get it working correctly just now. The biggest problem is that you will currently need the sources of the core libraries (which you can get through 'apt-get source classpath'). But even then it is not easy. You might want to file a bug report or contact the gjdoc hackers about it mailto:[EMAIL PROTECTED]. Note that you can also use the doxygen tool to generate API documentation. It was originally written to document C++ classes, but does a decent job on java source file. (Documentation can be found in doxygen-doc package. Quick start: doxygen -g myconfig; edit myconfig and search for all relevant java options and input options, don't forget to set EXTRACT_ALL and RECURSIVE; doxygen myconfig; view html/index.html). The gij java runtime would not work for my test case (just some simple server/client pairs that come with the nbio distribution) but the kaffe runtime did work. I haven't yet tried the SableVM runtime. Great! I wouldn't bother with the other java runtimes at the moment. First make sure that it works with one free vm, create a package and then just file bug reports with the others that it doesn't work :) Note, non-debian developer talking, so this might not be how Debian does it. But if it works with Kaffe and not with gij changes are high that you have just found a bug in gij. The error I got from gij (below my signature) it a little out of my league. I'm not exactly sure what bug I would file... perhaps you can make a suggestion? I'd be happy to do some more digging if you think it's worth it. The stacktraces generated by the interpreter are much more readable in the next version of gcj (3.3), but that is not released yet (probably somewhere next year). If you have a simple way to reproduce this then please send an email of bug report to the [EMAIL PROTECTED] mailinglist so I or someone else can help debug it. Thanks, all of you, for the help. Sorry if I'm rambling. It's 3:00am and I should stop hacking and go to bed. :-) Good night and thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2sdk build-depends cannot be satisfied?
Hi, On Sat, 2002-11-16 at 10:12, Kenneth Pronovici wrote: [I think this is still topical to both debian-mentors and debian-java. Someone tell me if they want it moved to one or the other...] gcj is supposed to come with a working jni implementation and comes with gij (GNU Interpreter for Java) for interpreting bytecode. What exactly doesn't work with gcj? Could you please file a bug report? http://gcc.gnu.org/bugs.html That way we at least know about the issue. Also Kaffe, Kissme and SableVM (all part of Debian now) should be able to run java byte code and jni code. Wow. I'm fairly impressed. It didn't take a lot of screwing around to make this work. I had to go with gcj-3.2, and that forced me to go with gcc-3.2 as well, and then I used fastjar to build the jarfiles. I attempted to use gjdoc for Javadoc, with only limited success (more on that later). Anyway, I'm glad you suggested that I look into this. :-) gjdoc is still very alpha level code. I think your best bet is the gjdoc-native package (gjdoc compiled with gcj to native code) but I have to admit that I didn't get it working correctly just now. The biggest problem is that you will currently need the sources of the core libraries (which you can get through 'apt-get source classpath'). But even then it is not easy. You might want to file a bug report or contact the gjdoc hackers about it mailto:[EMAIL PROTECTED]. Note that you can also use the doxygen tool to generate API documentation. It was originally written to document C++ classes, but does a decent job on java source file. (Documentation can be found in doxygen-doc package. Quick start: doxygen -g myconfig; edit myconfig and search for all relevant java options and input options, don't forget to set EXTRACT_ALL and RECURSIVE; doxygen myconfig; view html/index.html). The gij java runtime would not work for my test case (just some simple server/client pairs that come with the nbio distribution) but the kaffe runtime did work. I haven't yet tried the SableVM runtime. Great! I wouldn't bother with the other java runtimes at the moment. First make sure that it works with one free vm, create a package and then just file bug reports with the others that it doesn't work :) Note, non-debian developer talking, so this might not be how Debian does it. But if it works with Kaffe and not with gij changes are high that you have just found a bug in gij. The error I got from gij (below my signature) it a little out of my league. I'm not exactly sure what bug I would file... perhaps you can make a suggestion? I'd be happy to do some more digging if you think it's worth it. The stacktraces generated by the interpreter are much more readable in the next version of gcj (3.3), but that is not released yet (probably somewhere next year). If you have a simple way to reproduce this then please send an email of bug report to the [EMAIL PROTECTED] mailinglist so I or someone else can help debug it. Thanks, all of you, for the help. Sorry if I'm rambling. It's 3:00am and I should stop hacking and go to bed. :-) Good night and thanks, Mark
Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!
Hi, On Fri, Nov 09, 2001 at 12:29:44AM -0800, Kevin A. Burton wrote: Adam Heath [EMAIL PROTECTED] writes: It already is an issue. Look for mail.jar and activation.jar. Those are SCSL from sun. Bad mojo. ouch.. this needs to be corrected ASAP! Although I do not know the status of these libraries the GNU ClasspathX project http://www.gnu.org/software/classpathx/ is working on free versions of these apis. The activation Framework can be found at: http://www.gnu.org/software/classpathx/jaf.html The mail api seems to be only available from CVS through Savannah: http://savannah.gnu.org/cgi-bin/viewcvs/classpathx/mail/ Cheers, Mark -- Stuff to read: http://www.toad.com/gnu/whatswrong.html What's Wrong with Copy Protection, by John Gilmore -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#66540: kaffe on PowerPC: success
Hi, On Fri, Jul 21, 2000 at 04:50:18PM -0500, Ean R . Schuessler wrote: Just realizing this. :) Does someone want to pick libffi up? Interesting enough Brent Fulgham just made a libffi package when he was hacking on sablevm another Java Virtual Machine. (See mail at end.) On Fri, Jul 21, 2000 at 10:12:29PM +0200, Stephane Bortzmeyer wrote: On Friday 21 July 2000, at 12 h 6, the keyboard of Ean R . Schuessler [EMAIL PROTECTED] wrote: On this note I guess that the most sensible thing to do is go ahead and put the CVS .debs I have in incoming. Do you plan to compile them with --with-libffi? At least on PowerPC, this is mandatory (kaffe does not know the calling conventions of PowerPC/Linux). But FFI is not packaged on Debian... Cheers, Mark --- Date: Sun, 16 Jul 2000 16:48:23 -0700 From: Brent Fulgham [EMAIL PROTECTED] To: SableVM-User [EMAIL PROTECTED] User-Agent: Mutt/1.2i Subject: [Sablevm-user] Announcement: Libffi Debs Errors-To: [EMAIL PROTECTED] For any SableVM hackers running Debian systems, your build might have failed because the ffi.h header file was missing. In fact, Debian did not have a libffi package at all (which is a problem since SableVM relies on it). I have generated a libffi 'deb' file, which can be downloaded from: http://www.debian.org/~bfulgham/libffi_1.20-1_i386.deb I have also uploaded to the Incoming directory for Debian (master). It will take a week or so to be incorporated into the main archive, added to the Packages.gz file, etc. Once that happens, it will be fully under control of 'dpkg/dselect/apt'. Have fun, and let me know if you have any problems with it. Thanks, -Brent ___ Sablevm-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/sablevm-user
Re: serial port io
Hi, I have never tried it seems that RXTX http://www.rxtx.org/ would be usefull. From the Intro page: RXTX is a native lib providing serial and parallel communication for the Java Development Toolkit (JDK). All deliverables are under the gnu LGPL license. Cheers, Mark
Re: Status of Free Java Environment?
Hi, On Wed, Dec 15, 1999 at 04:39:57PM -0800, Per Bothner wrote: [...Some very nice stuff about gcj. I should really check that out now...] Note there are at least three implementations of the standard Java classes: Kaffe, classpath, and libgcj. This means some unfortunate duplicate work. One problem is different licenses. That does not preclude someone donating the same or similar code to all of them, but it does preclude whole-sale merging. I thought that both Classpath and libgjc were distributed under the LGPL and that Cygnus normally assigns copyright back to to FSF when working on GCC. Why isn't that the case now? Why haven't Classpath and libgcj merged? (The classlibrary of Kaffe is another story since that is distributed under the GPL and is not very well documented.) Cheers, Mark P.S. I saw a posting of you on Slashdot in which you said that there was only one (O'Reilly?) book on Swing (spec) details. Which book is that?
Re: jdk1.2
Hi, On Wed, Aug 11, 1999 at 08:05:00AM -0400, Gene McCulley wrote: Mark Yes, the JDK License is scary. Especially the License that Mark comes with JDK 1.2. Clause 2 of that license says: Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Mark That means that unless Debian, its mirrors and other people Mark distributing Debian (non-free) CDs get an exception it Mark cannot be distributed via the ftp archive or on CD. So we can't redistribute the blackdown version of jdk1.2, but blackdown can? Do they have a special dispensation? I don't know. You have to ask them. But we can redistribute the jre1.2, right? For my current needs, that would work fine as I can use the jre and one of the free javac implementations until we have a free jre. I don't think we can or want to distribute the JRE with Debian. The supplemental license terms of the JRE has a few very nasty clauses: 1. License to Distribute. You are granted a royalty-free right to reproduce and distribute the Software provided that you: (i)distribute the Software complete and unmodified, only as part of, and for the sole purpose of running, your Java applet or application (Program) into which the Software is incorporated; We might get away with this one since we distribute it together with Java applications bundled with Debian. But we also do want to allow people to download only the jre package. (ii) do not distribute additional software intended to replace any component(s) of the Software; But we cannot agree to this one. We want to distribute Kaffe, Japhar, Classpath, Gcj, Kopi, Fastjar, etc which are intended to replace the JRE with a Free version. Even if we don't consider non-free part of Debian (the JRE would not go into main :) I think we should not encourage software that tries to prevent Free replacements. [...] (v) may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are contained in the java or sun packages or similar as specified by Sun in any class file naming convention; My example why this is a bad clause was not so good since someone pointed out that you do not want to create something that is non standard. I do agree that we want a standard implementation of the core classes, but I also think that you should have the freedom to create non-standard classes. (Or fix bugs or stupid mistakes in the standard classes.) [...] and(vii) agree to indemnify, hold harmless, and defend Sun and its licensors from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of the Program. And I don't think that Debian (or SPI) can or wants to do that. So I am afraid that we also cannot distribute the Sun or Blackdown JRE. This isn't that bad since it is non-free software, but it is annoying. As I said before please help one of the (many) Free Java projects out there if you want to see a Free JVM, Standard Classes, Compiler, etc. in Debian. They are far from complete but they do work for most purposes. Cheers, Mark
Re: jdk1.2
Hi, On Tue, Aug 10, 1999 at 05:12:25PM -0400, Gene McCulley wrote: I was wondering about whether there were plans to package jdk1.2. I thought I would search the mailing list archives before I asked and I found this in a mail about release critical bugs: Package: jdk1.1 (non-free). Maintainer: Stephen Zander [EMAIL PROTECTED] [REMOVE] This package must be removed if its license is not fixed. 37599 jdk1.1: no permission to distribute Did anybody contact Sun? I would really miss the jdk. Anyway, what happened to the jdk1.2 alias jdk2? This is scary. Is there really a problem with having the jdk package? Yes, the JDK License is scary. Especially the License that comes with JDK 1.2. Clause 2 of that license says: Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. That means that unless Debian, its mirrors and other people distributing Debian (non-free) CDs get an exception it cannot be distributed via the ftp archive or on CD. Also note that you probably don't want to use JDK 1.2 if you are working on any of the free Java implementations. Clause 1 of the Supplemental License Terms says: [You] may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are contained in the java or sun packages or similar as specified by Sun in any class file naming convention; Which seems to prevent us from making our own implementation of the standard java classes using the JDK. (Wouldn't you love to make a java.util.bzip2.Bzip2InputStream? You can't with the jdk.) Please help one of the Free Java implementations if you want to use Java in Debian. There are a lot of projects that you can choose from: classpath: http://www.classpath.org kaffe: http://www.kaffe.org Japhar: http://www.japhar.org gcj and libgcj: http://sourceware.cygnus.com/java/ jikes: http://www.research.ibm.com/jikes/ (The new license seems to be finally really free) kopi: http://www.dms.at/kjc/ Cheers, Mark P.S. There is a nice little utility that should be included in Debian. It is called fastjar and it is a complete replacement for the jar utility written in C under the GPL http://www.engr.orst.edu/~burnsbr/fastjar/. (It saved me a lot of time since it is really fast!) P.P.S. I am still looking for a free javadoc implementation. Has anybody found such a program?
Re: Servlets, was Re: Various issues: kaffe, compilers, freeness, etc.
Hi, On Tue, Jul 27, 1999 at 10:24:17AM -0500, Ean R . Schuessler wrote: The servlet.jar in Kaffe will not work. It is only a shell. There is another LGPL implementation that was written by Paul Siegmann and Mark Wielaard. It is available at: http://www.euronet.nl/~pauls/java/servlet I have been able to get this working with Kaffe and JServ. It was not easy, per se, but not difficult. That is nice to hear. I have our classes running with Apache JServ, but since neither Paul nor I run it in a production environment we have not advertised the library very much. They really should be integrated in the Classpath project (we already assigned copyright to the FSF, but we didn't have time to really put them in the Classpath CVS). You definatly must run JServ in the manual mode. I created an /etc/init.d script to start it seperatly. If you could email me (privately) what we should change about the classes (or packaging) that would make it more easy to use with Apache JServ I would really appreciate it. I am also currently maintaining GNUJSP. (Although other people write the code, and I only collect the patches and maintain the web pages. Which reminds me that I should also release a new version since someone discovered a DOS.) Have you used it togheter with the class library and that free Kopi compiler? (Isn't the new version of the Jikes compiler also Free Software? I thought that they had changed their license.) I have Debian running now on my system, but I have not been brave enough to install the unstable release to check if the GNUJSP Debian package really works. GNUJSP and Apache JServ are in Contrib now. Would our classes (and the Kopi compiler) allow it to move to main? And how can I package our Servlet class library for Debian? Sorry to sound like a Debian newbie. But I really are a Debian newbie. A little note on the licensing issue. I personally make sure that I do not have to accept any license before I use any Specification or Javadoc. And since Sun does allow others to publish books about the various java class specifications (which do try to explain and interpet the intent of the specification). I think it is also save to implement a specification (since it is also a way to explain and interpet the specification). Why would O'Reilly be allowed to publish a book on the specification, but we would not be allowed to publish source code implementing that same specification? But I do agree that real legal advise on this subject would be nice. (I have actually bought two O'Reilly books on Java 2 security and would like to implement some classes for the classpath project. Which I could not claim to be according to the official specification since I use third party books. But since I do not use any of Suns material directly would I be clean?) Cheers, Mark P.S. I am in another city and cannot easily read my email. So please do not be offended if I do not react immediatly.
