Re: [External] : Re: OpenJDK Zero interpreter: fast bytecodes
On 06.01.2023 12:48, Aleksey Shipilev wrote: Hi Emmanuel, On 1/5/23 23:20, Emmanuel Bourg wrote: Its tricky, the arch all packages are usually built and tested on amd64 only (reproducible-builds.org also rebuilds on i386, arm64 and armhf). Rebuilding the 1500+ Java packages takes at least two days on a 4c/8t 4GHz Xeon, but on m68k it's going to take ages and that would abuse a bit the shared porter boxes. Yes, m68k (linker?) is problematic even for vanilla OpenJDK cross-builds. Since openjdk 18+ packages are already built, which I assume implies that someone would eventually rebuild/run the Java packages with them, I would just wait for bug reports then. If that happens, tell me if you need a debian-specific patch to disable/yank the change from any openjdk tree. Hi Aleksey, there is also a tool called qemubuilder [0], which may be useful if you'd like to build packages 'natively' on some (but not all, afaict) of the less mainstream Debian architectures. cheers, dalibor topic [0] https://wiki.debian.org/qemubuilder -- <http://www.oracle.com> Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann
Re: Feedback on OpenJDK jpackage tool early access builds
On 03.09.2019 18:40, Matthias Klose wrote: On 02.09.19 13:22, Dalibor Topic wrote: Hi Emmanuel, thank you for your interest - the jpackage source code can be found in the JDK-8200758-branch of the JDK sandbox repository at https://hg.openjdk.java.net/jdk/sandbox I haven't looked into that yet, but some questions first: - is the tool able to create source packages? and maybe differentiate here between pure source packages, and "source" packages just containing jar files? Hi Matthias, - jpackage is not producing source Debian packages, so it wouldn't be suitable in the current state for uploads into Debian main, etc. - jpackage is not fetching anything from network when bundling apps in Debian packages. See https://hg.openjdk.java.net/jdk/sandbox/file/67ffaf3a2b75/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java for details of the (evolving) implementation. cheers, dalibor topic - is the tool able to build without fetching anything from random websites? e.g. to create a self-contained source repository? These are two re-occurring issues when creating deb packages which can be uploaded to the Debian archives. Matthias -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Feedback on OpenJDK jpackage tool early access builds
Hi David, the jpackage tool is programming language agnostic, as long as the input is provided as modules and/or JAR files. The jpackage launcher creates a JVM instance and then calls into the "static void main(String[])" method of the specified main class, but doesn't otherwise care what is in the application. cheers, dalibor topic On 30.08.2019 19:31, David Goodenough wrote: Is this intended to work with all JVM languages, or just Java? I don't expect support for other languages, just tolerance. David On Friday, 30 August 2019 10:32:34 BST Dalibor Topic wrote: > Salut Raphael, > > thank you very much - we're looking forward to your feedback! > > cheers, > dalibor topic > > On 30.08.2019 10:37, raphael.jo...@free.fr wrote: > > Hi Dalibor, > > > > I am a Debian Java user. I would like to test JPackage on my project > > https://github.com/rjolly/linoleum . Currently, I use JDeb to package it > > in a pure Java fashion. Formerly, I was using > > https://github.com/mscurtescu/ant-deb-task , which works not bad, but is > > not included in Debian. > > > > I am downloading the JPackage early access build, and will keep you > > informed. I will manage to subscribe to the openjdk mailing list too. > > > > Best regards, > > Raphael Jolly > > > > Dalibor Topic wrote: > > > > Hi, > > > > We're working in the OpenJDK Community on a new tool for packaging [1] > > self-contained Java applications as DEBs as part of a future JDK release > > and the developers (on CC:) would love to get some feedback about the > > Linux integration, specifically on Debian Linux. > > > > So I thought this would be a good place to reach out and inquire if some > > Debian Java packagers (or users) would be interested in trying out the > > early access build [2] and letting us know how well it behaves and meets > > your expectations. > > > > If you are interested in providing feedback, feel free to respond here > > on this list, to us directly or on the core-libs-dev (at) > > openjdk.java.net mailing list, where the development of jpackage is > > currently discussed. > > > > The latest early access build's 'release notes' can be found at: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061977.h > > tml > > > > cheers, > > dalibor topic > > > > [1] https://openjdk.java.net/jeps/343 > > [2] http://jdk.java.net/jpackage/ -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Feedback on OpenJDK jpackage tool early access builds
Hi Emmanuel, thank you for your interest - the jpackage source code can be found in the JDK-8200758-branch of the JDK sandbox repository at https://hg.openjdk.java.net/jdk/sandbox cheers, dalibor topic On 02.09.2019 12:58, Emmanuel Bourg wrote: Hi Dalibor, With my Debian Java maintainer and jdeb contributor hats I'm very interested in reviewing the jpackage tool (and I would probably contribute if the project moves to Git as part of Skara). Where is located the jpackage source code in the OpenJDK repository? Emmanuel Bourg Le 29/08/2019 à 09:49, Dalibor Topic a écrit : Hi, We're working in the OpenJDK Community on a new tool for packaging [1] self-contained Java applications as DEBs as part of a future JDK release and the developers (on CC:) would love to get some feedback about the Linux integration, specifically on Debian Linux. So I thought this would be a good place to reach out and inquire if some Debian Java packagers (or users) would be interested in trying out the early access build [2] and letting us know how well it behaves and meets your expectations. If you are interested in providing feedback, feel free to respond here on this list, to us directly or on the core-libs-dev (at) openjdk.java.net mailing list, where the development of jpackage is currently discussed. The latest early access build's 'release notes' can be found at: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061977.html cheers, dalibor topic [1] https://openjdk.java.net/jeps/343 [2] http://jdk.java.net/jpackage/ -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Feedback on OpenJDK jpackage tool early access builds
Salut Raphael, thank you very much - we're looking forward to your feedback! cheers, dalibor topic On 30.08.2019 10:37, raphael.jo...@free.fr wrote: Hi Dalibor, I am a Debian Java user. I would like to test JPackage on my project https://github.com/rjolly/linoleum . Currently, I use JDeb to package it in a pure Java fashion. Formerly, I was using https://github.com/mscurtescu/ant-deb-task , which works not bad, but is not included in Debian. I am downloading the JPackage early access build, and will keep you informed. I will manage to subscribe to the openjdk mailing list too. Best regards, Raphael Jolly Dalibor Topic wrote: Hi, We're working in the OpenJDK Community on a new tool for packaging [1] self-contained Java applications as DEBs as part of a future JDK release and the developers (on CC:) would love to get some feedback about the Linux integration, specifically on Debian Linux. So I thought this would be a good place to reach out and inquire if some Debian Java packagers (or users) would be interested in trying out the early access build [2] and letting us know how well it behaves and meets your expectations. If you are interested in providing feedback, feel free to respond here on this list, to us directly or on the core-libs-dev (at) openjdk.java.net mailing list, where the development of jpackage is currently discussed. The latest early access build's 'release notes' can be found at: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061977.html cheers, dalibor topic [1] https://openjdk.java.net/jeps/343 [2] http://jdk.java.net/jpackage/ -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Feedback on OpenJDK jpackage tool early access builds
Hi, We're working in the OpenJDK Community on a new tool for packaging [1] self-contained Java applications as DEBs as part of a future JDK release and the developers (on CC:) would love to get some feedback about the Linux integration, specifically on Debian Linux. So I thought this would be a good place to reach out and inquire if some Debian Java packagers (or users) would be interested in trying out the early access build [2] and letting us know how well it behaves and meets your expectations. If you are interested in providing feedback, feel free to respond here on this list, to us directly or on the core-libs-dev (at) openjdk.java.net mailing list, where the development of jpackage is currently discussed. The latest early access build's 'release notes' can be found at: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061977.html cheers, dalibor topic [1] https://openjdk.java.net/jeps/343 [2] http://jdk.java.net/jpackage/ -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)
On 29.05.2019 03:59, Tiago Daitx wrote: On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg wrote: mercurial tags for the official releases. The advantage I see is that the tarballs are signed and do not need to be repacked, the downside being that such watch file cannot track "pre"-releases (as that helps testing the pre-releases) and won't work for openjdk-12 or openjdk-13 as Oracle does no such tarballs releases. Going to https://hg.openjdk.java.net/jdk-updates/jdk12u/tags -> click jdk-12.0.1-ga -> https://hg.openjdk.java.net/jdk-updates/jdk12u/rev/e831fc6bca9e -> click bz2 -> https://hg.openjdk.java.net/jdk-updates/jdk12u/archive/e831fc6bca9e.tar.bz2 You can also fetch the source code corresponding to the tag using the tag directly, i.e. https://hg.openjdk.java.net/jdk-updates/jdk12u/archive/jdk-12.0.1-ga.tar.bz2 (or tar.gz, etc.) Hope this helps, dalibor topic -- Oracle <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Fwd: FOSDEM 19 Debian Java talk
Hi Markus, On 12.02.2019 12:34, Markus Koschany wrote: Regarding javadoc generation we would like to see an option that basically reverts to pre OpenJDK8 and simply is less strict than the current implementation. Unfortunately, we don't plan to go back to the pre-Java 8 Javadoc implementation in OpenJDK. We do plan to remove the old doclet API in a future release, though: https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-February/000848.html , and the support for HTML4 output has been removed two weeks ago: https://hg.openjdk.java.net/jdk/jdk/rev/0d9dee001667 . With respect to strictness, the doclint feature can be turned off generally or selectively. A talklet/demo can be seen at https://youtu.be/VrI6rJNO2x4?t=829 cheers, dalibor topic -- Oracle <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 13.12.2017 11:13, Emmanuel Bourg wrote: Hi Dalibor, Le 01/12/2017 à 11:12, dalibor topic a écrit : That won't work with 10 either, unfortunately, since the old doclet has (finally) been removed. Please see https://bugs.openjdk.java.net/browse/JDK-8177511 for details. There is an undocumented --ignore-source-errors flag in javadoc since Java 9 that could compensate for the loss of the old doclet. Do you know if this flag will be kept in future releases? If it's undocumented, then it could be removed at any point. If you find the functionality useful, I'd suggest bringing it up on http://mail.openjdk.java.net/mailman/listinfo/javadoc-dev in order to discuss if there is a better way to make use of it than a hidden option. It seems that this option came into javadoc as part of http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/95d65add96a9 . The corresponding JBS issue is https://bugs.openjdk.java.net/browse/JDK-8175219 , and the motivation behind it were errors in source code, rather than making javadoc a bit less strict, fwiw. On a mildly related side note, in 10, javadoc treats failure to access a '-link-ed' URL as an error, not a warning. https://bugs.openjdk.java.net/browse/JDK-8180019 . cheers, dalibor topic That would help us greatly. Emmanuel Bourg -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Impact of the new Java release policy on Debian
On 30.11.2017 13:43, Emmanuel Bourg wrote: Do you know if Oracle intends to keep contributing Java LTS updates to OpenJDK beyond the 6 months window (i.e. after March 2019 for Java 11)? In the past, Oracle's plans for the duration of its contributions to an OpenJDK update release series have been publicized only once the update release has been well underway. Since work on JDK 11, much less its updates, hasn't begun yet, I unfortunately don't have anything to share so far. "Remove deprecated pre-1.2 SecurityManager methods and fields" As long as the SecurityManager isn't removed... There is no plan to do so in the near or middle term, per http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016526.html We use these flags in jarwrapper to detect the endianness of the JVM and initialize the java.library.path property. We'll have to use another detection mechanism (like running an actual class that dumps the sun.arch.data.model property). You could look into the 'release' file instead, per https://bugs.openjdk.java.net/browse/JDK-8179600 it also contains information on the $ARCH the JDK was compiled for. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 30.11.2017 15:08, Emmanuel Bourg wrote: If there is no hurry to remove javah I suggest waiting until JDK 12 to do so, this would increase our chances to include JDK 11 in the next Debian release. I don't think that hurry is necessarily a factor here, given that javah would have been deprecated for about 4 years prior to its potential removal in JDK 10. Waiting to remove it until JDK 12 would make that 5 years of deprecation instead of 4. If developers of an open source project have ignored a javah removal warning message for four years, I assume that they might just as well ignore it for five years, too, ultimately leaving downstream packagers in the same situation. Instead, what I think would be really useful, if you'd like to make a case for a delay of this particular change, would be to find out the kind of cases where moving projects to use javac -h instead isn't feasible for some reason or other. Those cases would then be good items to discuss on the jdk-dev list. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 30.11.2017 14:42, Emmanuel Bourg wrote: Le 30/11/2017 à 10:27, dalibor topic a écrit : Thanks, Emmanuel - in many of these cases (AspectJ, ICU, Spotbugs, Gradle, Scala) the way forward seems to be to upgrade the packaged software to the latest upstream version supporting JDK 9, often thanks to the patches provided by Chris West and the related efforts to rebuild the Debian archive with JDK 9 early access builds. Easier said than done unfortunately ;) Sadly, yeah. My humble suggestion would be to never deprecate the old source/target levels. I understand the sentiment. Unfortunately, that would steadily increase the maintenance cost of the compiler, while the potential benefit of supporting old source/target levels would steadily decrease, since most compiler users don't use it to recompile very old sources code with very new JDKs. The new annoyance with javadoc in OpenJDK 9 is the increased severity of incomplete classpaths. Before javadoc would just complain, now it stops with an error. We can work around that with the -old parameter, but it doesn't work with OpenJDK 8. That won't work with 10 either, unfortunately, since the old doclet has (finally) been removed. Please see https://bugs.openjdk.java.net/browse/JDK-8177511 for details. I personally don't understand why JAF is being removed. This barely saves 80KB in the JDK, it could have stayed there, no one would have complained. In contrast to many third party libraries, the JDK has a very regular release cycle, leading to four or more releases per year. Code that we don't need to distribute as part of OpenJDK 10, 11, etc is not code we have to patch, maintain and update as part of the regular JDK release cycle. Carrying code in the JDK that the JDK itself does not use carries both a maintenance cost (we now also need to address the technical debt in X), and increases the complexity of design decisions (how should the design of a feature interacting with X be if someone uses the JDK version of X, rather than the upstream version of X). It requires running java with -Xshare:dump on installation. See https://mjg123.github.io/2017/10/02/JVM-startup.html for an example and https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html for an example using AppCDS. Thanks for the reference. I tried the clojure example with our openjdk-8 and openjdk-9 packages but didn't measure a significant difference in execution time. Does it depend on recent kernel features? It shouldn't, though ASLR may play a role - what does -Xlog:class+load=info say? cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 29.11.2017 14:22, Emmanuel Bourg wrote: Le 29/11/2017 à 13:30, dalibor topic a écrit : I think what makes Debian GNU/Linux interesting for us regarding the OpenJDK Quality Outreach is that it's one of the first Linux distributions to do mass rebuilds of its (quite substantial) package archive with JDK 9. So it has the means and the knowledge among its contributors to potentially provide valuable perspectives about the impact of individual changes planned for future OpenJDK releases (JDK 10, etc.) that go beyond what individual FOSS projects can. FYI we have a list of bugs to be addressed to complete the transition to Java 9: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java9;users=debian-java@lists.debian.org Thanks, Emmanuel - in many of these cases (AspectJ, ICU, Spotbugs, Gradle, Scala) the way forward seems to be to upgrade the packaged software to the latest upstream version supporting JDK 9, often thanks to the patches provided by Chris West and the related efforts to rebuild the Debian archive with JDK 9 early access builds. More general information on migrating to JDK 9 is available at https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6 The removal of the old source/target in javac, Yeah, that's http://openjdk.java.net/jeps/182 . There have been some discussions about adjustments to that policy in light of the new release model at http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000108.html but no decision has been made yet. the increasing strictness of javadoc That's http://openjdk.java.net/jeps/172 . While the checks are on by default, many can be turned off using the option -Xdoclint:none. Please see https://docs.oracle.com/javase/9/javadoc/javadoc-command.htm#JSJAV-GUID-1ABCA873-009C-4BB4-9490-51A716C8AA56 for details. and the removal of APIs (javax.xml.bind, javax.activation) have been the most disrupting changes so far. That's http://openjdk.java.net/jeps/261 - while the EE APIs haven't been removed from JDK 9, they need to be explicitly resolved per https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-F640FA9D-FB66-4D85-AD2B-D931174C09A3 . The EE APIs have been deprecated for removal, though, and there is a draft JEP at http://openjdk.java.net/jeps/8189188 elaborating on that - their removal is not yet scheduled for any specific release, though. As such, the way forward for users of such APIs would be to migrate to standalone implementations, rather than the one provided in the JDK. We haven't started testing with OpenJDK 10 yet. Matthias has uploaded the openjdk-10 package to experimental last week. I guess we'll start mass rebuilds with JDK 10 once the JDK 9 issues are under control. According to the JDK 10 schedule at http://openjdk.java.net/projects/jdk/10/ the rampdown phase for JDK 10 will start mid-December. Before rampdown is often the best time to provide feedback on features and their design and implementation, while after rampdown is a good time to provide feedback on regressions. We don't ship classes.jsa with OpenJDK yet, I don't know if there is a reason for that. Does it require a specific parameter when building OpenJDK? It requires running java with -Xshare:dump on installation. See https://mjg123.github.io/2017/10/02/JVM-startup.html for an example and https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html for an example using AppCDS. Shipping an extra arch-specific package containing the AppCDS file for each worthy application shouldn't be too difficult. I'm not sure how it would play with package dependencies though. Is there a unique .jsa file for the application, or one per library? It's per application, and specified using the -XX:SharedArchiveFile option per http://openjdk.java.net/jeps/310 . What happens if the classes in the jsa files don't match the classes in the jar files? Is the data automatically invalidated and ignored? Yes. If -Xshare:on is used, then the VM will exit when it detects a discrepancy (different classpath, etc.) or if it can't mmap the shared archive. With -Xshare:auto, it'll ignore the shared archive file, and load the classes as usual. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 29.11.2017 12:46, Emmanuel Bourg wrote: Le 29/11/2017 à 10:32, dalibor topic a écrit : I'd agree with Matthias that the binaries of some builds are not by themselves newsworthy for the debian-java mailing list specifically, since Debian doesn't use third party binaries in its Java packaging. Actually these binaries can be turned into Debian packages with the java-package tool. Thanks, Emmanuel - I didn't expect that to necessarily be the case, since the package description at https://packages.debian.org/es/sid/java-package only claims support up to Oracle JDK 8, and it seems that support for Oracle JDK 9 is WIP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876426 Does java-package work for JDK 10 EA builds? For example a feature should be removed in the upcoming LTS release only if it was deprecated (with an alternative available) in the latest LTS. So for javah that would mean deprecated until Java 11, and removed in Java 12 (for the next Java 17 LTS). An alternative to javah has been available with the -h flag for javac since JDK 8 (2014). It might be removed in JDK 10 (2018). If you have a good sense how much affected Debian would be by this change, that would be great feedback to share on the thread at http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000278.html . That being said, the OpenJDK policy for removals of deprecated functionality is not tied to LTS releases. Whether it should be would be an interesting discussion to have on the jdk-...@openjdk.java.net mailing list. For some background on enhancements to deprecation (policies) since JDK 9, see http://openjdk.java.net/jeps/277 . Meanwhile, JDK 9 comes with the jdeprscan tool, which can be useful in the context of detection of potential future issues with third party code using deprecated APIs. Please see https://docs.oracle.com/javase/9/tools/jdeprscan.htm#JSWOR-GUID-2B7588B0-92DB-4A88-88D4-24D183660A62 for a reference in general, and the -for-removal flag in particular. A jdeprscan -for-removal run might be a useful check to consider adding to lintian, for example. Having the mails on the debian-java list is an opportunity to provide feedback in the Debian context and have more developers joining the discussion. That would be lost with direct emails. Indeed, but if someone feels that the early access announcement mails are inappropriate for a list they subscribed to, then I don't think that it's a good idea to send them further emails of the same kind. To be successful, the OpenJDK Quality Outreach depends on the good will of the open source developers and communities it engages with. Encouraging open source community developers to test and report issues as well as provide feedback on upcoming OpenJDK releases can't work if it's perceived as annoying or misplaced. Which is why I proposed some modifications to the format of the e-mails to potentially make them more useful for Matthias. Let's see what he thinks first. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
On 29.11.2017 10:20, Emmanuel Bourg wrote:
From my experience on other lists also receiving these
notifications I know this is a good opportunity to gather and take into
account the community feedback.
That's the general idea, yeah!
A list of FOSS projects participating in the OpenJDK quality outreach is
available at
https://wiki.openjdk.java.net/display/quality/Quality+Outreach . Not all
of them necessarily chose to receive the early access announcement mails
on their mailing lists, fwiw.
The last six monthly report on the outreach activities can be found at
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2017
, and the recording of the 2017 FOSDEM Java dev room talk on it can be
found at https://archive.fosdem.org/2017/schedule/event/outreach/ .
I think what makes Debian GNU/Linux interesting for us regarding the
OpenJDK Quality Outreach is that it's one of the first Linux
distributions to do mass rebuilds of its (quite substantial) package
archive with JDK 9. So it has the means and the knowledge among its
contributors to potentially provide valuable perspectives about the
impact of individual changes planned for future OpenJDK releases (JDK
10, etc.) that go beyond what individual FOSS projects can.
For example, a planned feature for JDK 10 is application class data
sharing ("AppCDS"), which extends the existing Class-Data Sharing [3]
("CDS") feature in OpenJDK to allow application classes to be placed in
the shared archive to improve startup and footprint. Fedora OpenJDK
packages use CDS already, afaict from the existence of classes.jsa in
their package file lists. [1]
I don't know if Debian's OpenJDK packages do - if they don't then that,
in conjunction with AppCDS in JDK 10, might be an interesting feature to
try out in order to attempt to decrease startup costs for development
tools written in Java, which might be relevant in the context of
building and testing FOSS packages.
AppCDS was pushed to the JDK (10) Hotspot forest yesterday [2], so it
should become available in a JDK 10 early access build in due time.
cheers,
dalibor topic
[0] http://openjdk.java.net/jeps/310
[1]
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/j/java-1.8.0-openjdk-headless-1.8.0.151-1.b12.fc28.x86_64.html
[2] http://hg.openjdk.java.net/jdk/hs/rev/78b2ecdd3c4b
[3]
https://docs.oracle.com/javase/9/vm/class-data-sharing.htm#JSJVM-GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
Re: JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
I think that as soon as someone objects to having mail sent to a public list, the sending should end. I'd agree with Matthias that the binaries of some builds are not by themselves newsworthy for the debian-java mailing list specifically, since Debian doesn't use third party binaries in its Java packaging. I'd also agree with Emmanuel that it can be useful for packagers to be aware of upcoming changes in the JDK sooner, so that they can provide feedback and make adjustments as necessary. For example, the javah tool is considered for removal in JDK 10 [0], which may or may not impact some packages in Debian. For the corresponding thread on the Apache Ant mailing list, please see http://mail-archives.apache.org/mod_mbox/ant-dev/201711.mbox/browser . So in light of Matthias' well-founded objection, I'm wondering if these kind of emails wouldn't be more useful to the Debian Java community if they, in addition to pointers to binaries, also included instructions on checking out the tagged sources for OpenJDK for the specific builds, so that feedback by so inclined Debian developers could also be provided on whether the upstream source code builds at all on Debian GNU/Linux (which may be well ahead of the Oracle developers in terms of the native GCC toolchains used, for example). Matthias, would that be more useful and acceptable? If not, then I'd suggest stopping further early access announcements mails to this mailing list, Rory, and sending them to Emmanuel directly instead, while anyone else interested in them could also subscribe to the quality-disc...@openjdk.java.net mailing list and receive, comment and discuss them that way. cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000278.html -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: Latest sun java5 packages
Diederik de Haas wrote: Hello, Some time ago it was decided that the sun java 5 packages should be removed from the archives (EOL) and now they have. But I have a requirement (work) for the various sun-java5-* packages and I know that 1.5.0_20 was uploaded to the archives some time ago, since it's installed on my system, but they are now removed from the archives (and apparently I did aptitude autoclean a bit too much, so they're also gone from apt's cache). I know that the _17 packages are still in the repositories for Lenny, but if it is possible I'd like to have the _20 packages. Can someone help me get those _20 packages and preferably for both i386 and amd64? Then I can put them in my own archive (or sth like that) and still use them. The raw data for them is at http://jdk-distros.dev.java.net. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:dalibor.to...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Considering removal of kaffe
Niels Thykier wrote:
Hi
After having looked at kaffe I have noticed it seems lacks maintenance
both from the Debian side but also upstream seems rather dead. We got an
120 days old FTBFS RC bug (#529872) and alternatives exists. So I
figured perhaps it was time to retire kaffe from the repositories.
I have appended a list of affected uploaders and their binary packages
(plus four packages, which dd-list failed to look up) if we were to
remove kaffe.
I will file a bug against cdbs (and other packages I find), which uses
kaffe as build-depends{,-indep}, if we proceed with the removal.
I believe that the FTBFS is fixed in 1.1.9, but since that one wasn't packaged
in
the last year or so, and OpenJDK+Zero covers most of the bases now, I think it's
OK to remove it from the repo.
cheers,
dalibor topic
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Confused about the Glassfish packages
Kumar Appaiah wrote: On Tue, Sep 09, 2008 at 01:48:10PM +0100, David Goodenough wrote: Well not really. If all they are intended to be is a source of JARs for development purposes than thats fine (but it would be useful to be told). Its only if they are intended to be all of glassfish that there is a bug. If I recall correctly, that is still the aim. But I am not sure if Torsten managed to fully package all the dependencies needed to set up and run an instance. Not yet - there is a bunch of things missing. cheers, dalibor topic -- *** Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55http://openjdk.java.net D-20097 Hamburg mailto:[EMAIL PROTECTED] Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preferred default JRE (was: Bug#411692: bootchart-view: Needs libgtkpeer.so when converting a bootchart to EPS or PNG format)
Michael Koch konqueror at gmx.de writes: On Tue, Feb 27, 2007 at 02:02:35PM +, Jörg Sommer wrote: Hi Michael, Michael Koch konqueror at gmx.de wrote: Kaffe is outdated and needs some serious updates. Its better not to use it in current state. The other runtimes are more uptodate. Sablevm is even more outdated and I dont see anyone working on it at all in Debian. Recommending those two currently is like moving the user into a really wacky house. Interessting. Sometimes ago you suggested to use kaffe as the default JRE to make things more reproducible. Now, things may have changed. What should I now put in the Dependends line as prefered JRE? gcj | java-runtime | java2-runtime Which JDK should I use for building? gcj? Currently I use kaffe. Things change over time. java-gcj-compat or java-gcj-compat-dev depending on if you need JRE or a JDK replacement. To explain it in a simple fashion, Kaffe hasn't seen a release in last year due to a fair bit of work going into making it really work with an installed GNU Classpath, rather than having to have its own slightly modified copy of GNU Classpath installed, like it did in 1.1.7, and the usual conflict between bugs, and available time fighting spirit to fix them, as I personally focused more on the soft issues around opening Sun's implementation myself, rather than hacking on Kaffe, and just recently jumped in to do a bit of fastjar maintenance, as that was one more fire to fight. So we (man-di me, wearing my Kaffe maintainer hat) have agreed to recommend gcj over kaffe as the preferred runtime for the time being a while ago. I don't think we really communicated that other than on IRC, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Marcus Better marcus at better.se writes: Andrew Haley wrote: It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source code on demand. That may be a valid argument, but there are more troubling cases. For instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? I'd suggest looking at whatever solution JPackage came up with, as well. I believe they (i.e. Ralph Apel) figured out how to package it in a way that it uses the jars in the packaging system rather than whatever the default is (network from ibiblio, I think), but I'm not sure. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JDK is GPL now! a package in main requested
Mr. Demeanour mrdemeanour at jackpot.uk.net writes: This is interesting: Sun is only releasing what will become java 7 [...] - I suppose that remains the case? AFAIK Java 5 remains the most popular Java platform (excluding J2ME, of course). See http://www.sun.com/software/opensource/java/faq.jsp#b9 When we open-source the full JDK we'll make the sources for both JDK 6 and JDK 7 available. The community will have both a stable release - JDK 6 - on which to focus quality improvements, and JDK 7, the next feature release where all the action will be for innovation and new capabilities. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openjdk-hotspot-jvm -- Hotspot JVM from Sun
Ola Lundqvist opal at debian.org writes: Hi Anyone knows what this can be? Trying to build the sun hotspot jvm... See https://openjdk.dev.java.net/hotspot/faq.html#PLTreloc0x08 cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: priorities for java alternatives
Michael Koch konqueror at gmx.de writes: We decided at FOSDEM to make GCJ then default. The rest is ok with me. Fine for me, too. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: priorities for java alternatives
Matthias Klose doko at cs.tu-berlin.de writes: now that non-free java jre's and jdk's are available in non-free, we should get some agreement about the priorities for the different tools and environments. some proposals: - things in main have higher priorities than things in contrib and non-free. Sounds fine to me. - an alternative installed as a set of alternatives has higher priority than a single tool. Do you have an example in mind where that would be useful? - tools conforming to a higher java version have a higher priority (unsure if that is necessary). We have no way to figure out which java version tools conform to, so I don't think that is possible. - ordering of the free runtimes. can we agree on some kind of order? I'd suggest a popcon based ordering. Reevaluate for every release / 6 months, etc. which should let us shuffle things around as necessary. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards Java Libre
Tom Marble Tom.Marble at Sun.COM writes: Arnaud: Please allow me to elaborate on some points not covered by David I saw a sun-jdk-source package or something... that means all those who install this package and look at the sources will not be able to help GNU Classpath. In my POV, one of the important thing we can do in Debian is helping the GNU Classpath project and friends. This is the src.zip file that is part of every JDK. You are concerned about tainting -- and you do not need to worry about this. Even if you accepted the JRL and looked at Mustang sources you still would not be tainted: http://weblogs.java.net/blog/editors/archives/2005/04/jrl_faq_18.html That's one of the things people working on free runtimes tend to have a different opinion on, because we have to look at the worst case. See for example the opinion of IBM's counsel at http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200505.mbox/[EMAIL PROTECTED] about the residual rights clause of the JRL: Notice that the residuals clause does not extend to copyrights. You can study Sun's source code under the JRL and then turn around and write your own implementation relying solely on what you remember, and you're covered for any potential trade secrets that Sun might have had. However, if your code turns out to be substantially similar (an intentionally vague legal standard), then Sun might have a copyright claim that it can assert. You need to make sure that your code is not substantially similiar. How one does that without constantly referring to the code that you're trying not to copy without looking like you're trying to copy without getting caught is an interesting question. Sun probably didn't intend this result. What they probably meant was that as long as you aren't making literal copies of material portions of their source code, you're covered by the residuals clause. If that's the case, I think their desire for brevity got in the way of clarity. They would need to expand that section a bit to make it clear that the residuals license covered copyright issues as well as long as you didn't literally copy large amounts of code. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards Java Libre
David Herron david.herron at sun.com writes: I have been subscribed to this list for 3+ weeks, listening. I suppose I could have posted a note here, but as a group we (as Tom said) were trying to be very quiet about this project until we could announce it at Java ONE. That meant not sending a note to a public mailing list like this. You know how marketing people to launch surprise announcements ... so that's what's happened. Judging by the ongoing feedback on debian-legal, transparency from the beginning would have worked much more in Sun's favour. That we already provide RPM's is a symptom of our old mindset. To get to a world where apt-get install jroller will work smoothly we have to change our mindset and interact with you guys in a different way. Cool. In order for apt-get install jroller to work in the smoothest fashion, it needs to be in 'main', i.e. to build run with one of the free runtimes in Debian, like gcj, Kaffe, cacao, SableVM, IKVM, etc. with all its dependencies. If Sun is interested, for example, in getting GlassFish into Debian's main, then it'd be nice to have Sun work with the free runtimes to get all the GlassFish components sorted out, building working on top of them. That would be at least an interim solution until Sun's own implementation is liberated. But, of course, now our focus is going to take a different direction to Sun's java joining the ranks of free implementations. Good. Please do join in the fun soon. I agree with what you say about the JCP. I used to work on IETF standards committees and those groups are completely in the open and it didn't hurt anybody. I don't understand why the JCP has a default of working behind closed doors. I don't quite understand why Sun's spec leads don't take the opportunities provided under JCP 2.6, and actually make at least their own JSRs transparent. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions about Eclipse, EMF, ecj...
Eric Lavarde - Debian deb at zorglub.s.bawue.de writes: Hi, Hi Eric, Michael Koch wrote: On Thu, Dec 22, 2005 at 01:38:16PM +0100, Eric Lavarde - Debian wrote: 3. Also for FreeMind, I tried to use kaffe but jikes dumped http://bugs.debian.org/338176 and its development seems to be quite stalled. Is there an option to use ecj as a drop-in replacement (and how)? kaffe development is not stalled. Its very active. They just not release very often. sorry, I didn't mean to say that the kaffe development had stalled, but that the _jikes_ development has stalled. A conclusion to which the kaffe team seems to have also come. Jikes development seems to have halted last autumn, unfortunately. Currently, I am only aware of three free software java compilers being actively maintained: ecj, gcj and gcjx. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I have a problem help me
David N. Welton davidw at dedasys.com writes: Charles Fry wrote: Is it just me, or is this entire thread a bit off topic for this list? Yeah, it brings to mind answers like this: http://www.uwasa.fi/~ts/http/homework.html http://home.att.net/~jackklein/ctips01.html#homework ... I love the potential standard reply for such situations: If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. Please post your instructor's email address in case I have any questions about your assignment. In fact, I have a great idea. I could just email your assignment directly to your instructor and then you wouldn't even have to go to class either! cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need jlex and cup packages
Chari-Jo Gillies charipat at yahoo.com writes: Dear Sir/Madam, I would like to know if it is possible for you to tell me where i can get the following for a mandrake 10.0 distribution:- cup - LALR parser generator for Java(tm) jlex - A Lex-style lexical analyser generator for Java jflex - lexical analyzer generator for Java I would suggest checking out the JPackage project at http://ww.jpackage.org for RPMs of such packages. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Current status of your swt-gtk package
Joe Smith unknown_kev_cat at hotmail.com writes: I'm not so certain about bycode-compiling eclipse with gcj. From http://www.backports.org/~mkoch/unstable/ eclipse_3.1-10.diff.gz it appears that first the (bootstrap) ecj compiler is built using gcj, then the rest of eclipse is compiled with the natively compiled bootstrap ecj. See eclipse-3.1/debian/rules for details. Also note that Kaffe includes some classes that are not a part of GNU classpath, so it is possible a program may work fine on kaffe, but not on a different free interpreter/native-compiler. Yes. Kaffe acts as a melting pot for some class libraries that usually find their way into GNU Classpath sooner or later. Meanwhile, they are all available from the respective upstream projects wherefrom they were merged into Kaffe. See the file THIRDPARTY in Kaffe's source code for details. There are different philosophies applied by different free runtimes, targeting different users, essentially. Some people prefer to have a lean VM, and to rely on excellent packagers to integrate it with other libraries into one nice runtime environment, others prefer to do the integration beforehand to make it easier for users and developers who don't use systems with excellent packagers. But the core class library foundation is pretty much the same for all GNU Classpath 0.18 using runtimes, for example, whether they ship their own copy or not. It'd be impossible to move it main, afaik, if it only depended and worked on non-free software. true. However if it has a depends of [free software] *OR* [non-free software], it is allowable. Yes. It's not necessary, though, afaik, simply depending on java-virtual-machine/java2-runtime should do the trick as well, as the non-free VMs should provide that just like the free VMs. And that's what the package does, afaict by the diffs, so I believe we are having a hypothetical discussion. If you want to avoid a $freevm download completely, you'd have to make sure that the eclipse 3.1 package and all its dependencies build and work fine on the non-free software in question, and don't mess with the non-free software's licensing restrictions, for example. It seems unlikely that any changes needed to support a free JVM will break the running of the program on the official JVM. Remember that the upstream version is intended to be run on the official JVM, so we know that that works. There is no official JVM that has ever ran through the official compatiblity test suite on Debian Sarge afaik, so one can't assume that an 'official' JVM will fully behave as advertised in a configuration which it wasn't certified for. See the various threads about the crashing-on-startup IBM JDK on powerpc last year. One can test, though, and through testing achieve a certain degree of confidence that a VM in question, nevermind whether its free or non-free, certified or not, does in fact successfully run the software you want to package on Debian. I can see no reason why there would be licencing issues. I am aware of no JVM that prohibits running of java bytecode that can also be run on a JVM that is licenced differently. I was thinking about some of the more esoteric clauses in non-free VM licenses, like restrictions on sub/supersetting of certain namespaces. Though I don't recall whether that was a restriction on redistribution or on use, I believe that clause got shifted around a bit between the two areas in between the releases. That has little to do with eclipse itself, but may matter for some dependencies of it, for example, if they sub- or superset some official Java technology API. The dependency graph of a big Java application like cocoon, Eclipse or JOnAS can be very huge. But then, it's still a very far fetched scenario. A more likely licensing issue would be a DD not being interested in agreeing to license terms for some non-free VM, since he wouldn't want to install non-free software on his box (who would, anyway? ;). Then it'd be up to users of non-free VMs to help the DD keep the package in a good shape wrt to the non-free VMs, with patches, bug reports and praise, when things work ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Current status of your swt-gtk package
Joe Smith unknown_kev_cat at hotmail.com writes: Off topic but just to throw this out, this would seem to be the best (in terms of speed) theoretetical JVM: This a a merged static and dynamic compilation system that gains speed in echange for a (slight?) increase in processor usage, resource usage, and diskspace usage. Kaffe has gcj-bindings for an older, patched up version of gcj. what you describe could be implemented by updating Kaffe's gcj bindings to gcj4, and running with it underneath. If you are interested in volunteering, please hop on the kaffe mailing list. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Current status of your swt-gtk package
Joe Smith unknown_kev_cat at hotmail.com writes: I understand that. What I was saying is that it seemed odd that upstream had not done this. It may be a wise dea to prod upstream and see if they will update for 3.2. I doubt the breakage is too severe. They may, but not this early in the release cycle. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=98371 for details. The new packages run on kaffe? (it sounds that way, If you used a different free jvm them just 's/kaffe/[name of other JVM]/' for the following questions.) Afaik, yes. And on gcj/gij. And surely on the various other up-to-date free runtimes in Debian, since they all use pretty much the same class libs :) Did you remove the depends on an 'offical' JVM, or do 'kaffe|...'? If you removed the depends on the 'offical' JVM rather than make it a choice, please reconsider. Explanation: I have a JVM from sun installed on my system solely for reasons of practicallity. Since I already have that installed, and that is known to run Eclipse just fine, I do not want to waste space downloading kaffe. It'd be impossible to move it main, afaik, if it only depended and worked on non-free software. If you want to avoid a $freevm download completely, you'd have to make sure that the eclipse 3.1 package and all its dependencies build and work fine on the non-free software in question, and don't mess with the non-free software's licensing restrictions, for example. That's quite a chunk of work, and since the manpower of the debian-java effort is limited, most people doing the actual packaging work tend to concentrate their efforts on Free Software, which Debian can distribute freely together. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kaffe 1.1.6 Debian package in Oldenburg
Arnaud Vandyck avdyk at debian.org writes: Wolfgang Baer wrote: Arnaud Vandyck wrote: [... about switching from jikes to ecj to build classes in kaffe] Wow! I think we should switch to ecj on mipsel too... and why not on all the arches? No, ecj is not available on mipsel as there is no gcj. For the other arches I _think_ jikes is still better in time and memory usage. Sight. Another way to solve this is to split arch-dep and arch-indep in the build. This is a waste of time and resources to build java files on each arches. Build the classes onces and only build the C files on all arches would be better. Ideally kaffe would just depend on the classpath package, but neither Kaffe nor GNU Classpath are there yet. Working on it ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to compile java files?
Mark Wielaard mark at klomp.org writes: Hi Joerg, On Thu, 2005-09-01 at 21:40 +, Joerg Sommer wrote: Barry Hawkins barry at bytemason.org 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. As a lazy Kaffe (and GNU Classpath) developer, I like to recommend other VMs, so I'd recommend JamVM. Nice, small, speedy and great maintainer. The choice of many GNU Classpath developers (who are not writing their own VM). cheers, dalibor topic p.s. I use similar debugging techniques to Mark's, but as a Kaffe dev, I also transparently use KAFFE_DEBUG=valgrind or KAFFE_DEBUG=ddd, Kaffe's xdebugging support for debugging jitted code and -vmdebug when I feel the need to know what's really going on under the hood ;) But if you want something that works in a normal JVMDI debugger, try SableVM, which is pretty cool, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy ideas (Was: Re: java2-runtime)
Charles Fry debian at frogcircus.org writes: Does this mean that bugs should be filed with packages which provide or depend on java-runtime (I noticed a few)? Should bugs be filed with kaffe, which as Peter pointed out does not provide any java runtime? Is there any reason why java1-runtime and java2-runtime are the official runtimes, whereas java-compiler and java2-compiler are the official compilers? This inconsistency does not seem helpful in establishing consistency within the runtimes. Yeah, I think the policy should be consolidated, since java 1.1 is (for all I know) not packaged or availiable in Debian. Java-package supports nonfree runtimes starting from 1.3 and above. I assume that most of the software packaged in Debian these days will require a pretty modern runtime anyway. So, I'd suggest that the java(X)-runtime virtuals are removed in favour of a general j-word-runtime virtual to be provided by all runtimes capable of running programms written in the Java programming language. I propose using j-word instead of java, because that is a time-honoured way of abbreviating four letter words that can not be said freely in English.[1] cheers, dalibor topic [1] As Sun Microsystems holds and and actively defends their Java(TM) trade mark, I would not recommend calling Kaffe a Java(TM) runtime, because, frankly, according to Sun Microsystem's rules for the usage of the trade mark, it is not a Java(TM) runtime. And that's fine by me, I don't feel that trying to rub off Sun's trade mark investment is a fair thing to do.[2] You can see on the kaffe.org web site how the Kaffe project tries to draw a clear line between Kaffe and Sun Microsystem's implementation. In order to avoid confusing people who dearly want the Java(TM) Desktop System GNU/Linux distribution, for example, rather than a free software runtime environment for programms written in the Java programming language (that is a safe use of the term Java, btw. ;). [2] Just like I don't feel that Sun Microsystems attempts to market some of their clearly proprietary software as Open Source are a fine thing to do, like they tried to do with Java3D or JAI. See my comment at http://weblogs.java.net/blog/editors/archives/2005/02/working_with_th.html for a reference. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java2-runtime
Petter Reinholdtsen pere at hungry.com writes: [Eric Lavarde] Conclusion: - if your package works with free VMs, you should write something like: kaffe | sablevm | java1-runtime. Is it not enough and recommended to list only one non-virtual package, aka 'kaffe | java1-runtime' or 'sablevm | java1-runtime'? I assume would kaffe and sablevm provides java1-runtime, but a check show that at least kaffe only provide java-virtual-machine (did not find sablevm?). How come kaffe do not provide java1-runtime? I'd say that javaX-runtime only makes sense for runtimes that have been through the compatibility tests for X, as otherwise code depending on that platform's features may not run at all. I am not sure whether a virtual means 'may, with a bit of luck, work' or 'does work, of course', though. Given that such compatibility tests have so far[1] been unavailable to free runtimes like Kaffe, it does not seem to be legally safe to call Kaffe java1/2/3/4, if one wants to avoid having to deal with Sun's lawyers at the end of the day. See Sun's trade mark usage rules, and all that fascinating legal stuff. It may make some sense to introduce a 'classpath-runtime' or 'free-runtime' virtual to be used for GNU Classpath based VMs and ahead of time compilers. But, GNU Classpath is so rapidly changing (in particular wrt to the binding between the class library and the runtime, which makes it pretty hard to run sucessive GNU Classpath release without modifying old runtime releases), that such a virtual would not be too useful in practice, other than saying that the code *may* run on at least one GNU Classpath runtime beside the one already listed, good luck finding it. :) That would not seem to be a perfect situation for users, though it would probably be an improvement over the current one. cheers, dalibor topic [1] I'm talking with them about the 1.5 tests, but that's going to take a while. A TCK license is a very long text of legalese and takes a deal of time to decipher and negotiate through. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AMD64 J2EE possible?
Joost Kraaijeveld J.Kraaijeveld at Askesis.nl writes: Hi, Is it possible to develop J2EE applications on an AMD64 using a (non)free 64 bit environment? If so, is there a HOWTO or other form of documentation of how to set up such environement? On Fedora's side, Andrew Haley is currently working on making JOnAS (Free Software J2EE implementation) work well on top of gcj/gij (Free Software runtime). gcj/gij runs on amd64, among several other architectures ;) Afaik, the work has not been fully completed yet. For the current status see http://article.gmane.org/gmane.linux.redhat.fedora.java/1001 cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AMD64 J2EE possible?
Joost Kraaijeveld wrote: On Sat, 2005-08-20 at 14:26 +, Dalibor Topic wrote: On Fedora's side, Andrew Haley is currently working on making JOnAS (Free Software J2EE implementation) work well on top of gcj/gij (Free Software runtime). gcj/gij runs on amd64, among several other architectures ;) Afaik, the work has not been fully completed yet. For the current status see http://article.gmane.org/gmane.linux.redhat.fedora.java/1001 I am afraid that I need a sollution a bit sooner (today;-)?). Jump in and squash the remaining bugs, it's that easy. If you manage to do it all today, you can party through the rest of the weekend ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bcel
Wolfgang Baer WBaer at gmx.de writes: I don't know if it can't be run with the free runtimes - I will file a whislist bug against it and ask there what the problem is. Depends on the version. The latest version tries to use NIO locking unless the respective class is removed, and NIO locking doesn't work yet, afair. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Setup a free java development environment
Michael Koch konqueror at gmx.de writes: BTW: Free Java does not exist in reality and I would not recommend to name anthing officially with Java in its name. Java is a registered tradmark by SUN. The Fedora Java effort currently thinks about a name too... I would call it Classpath community but this is only my personal preference and I'm prejudiced because I'm part of GNU classpath project. Yep. It is in my opinion simply rude to try to rub off Sun's trade marks, beside being an unnecessary legal risk. Just like I think Sun's pretty stupid when they desperately try to market their proprietary software as 'open source', I think it's equally stupid to try to pass free software off as non-free. Remember, like GNU is *not* Unix(TM), GNU Classpath/Kaffe/Gcj are *not* Java(TM). If anything, they are better, in my biased opinion, so there is no need to associate them with the negative, and by now pretty meaningless, legally dubious J-brand. I personally prefer to use the terms 'Classpath community' or 'free runtimes' to refer to the positive future of the platform :) These terms don't come with trade mark use restrictions, and moreover are not generally associated with all the negative connotations the term 'Java(TM)' has to a lot of people in the free software community.[1] Recently I've talked to a few people trying to run some 'how Sun could try to excert legal pressure if they wanted to' scenarios past me in private, and most of them involved Sun using trade marks to that end. So I am no fan of giving Sun a huge bat to smack one with, even though I believe them to be benevolent in general. cheers, dalibor topic [1] Non-free, slow, limited, resource-intensive, dubious licensing ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Setup a free java development environment
Barry Hawkins barry at alltc.com writes: [...] Classpath certainly has some momentum behind it, but that is currently referring to the Essential Libraries for Java(TM) base upon which most of our other stuff is founded. The thing about free runtimes is that it sounds generic enough to apply to Mono as well the stuff we work with. Mono is a very fine runtime for GNU Classpath, thanks to Jeroen's innovative IKVM project. See www.ikvm.net for details. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libbsf-java
Wolfgang Baer wbaer at gmx.de writes: But, kaffe is atm horrible broken for most package builds due to bug (#295014). Every second package fails due to this bug to build. libbsf-java is one of them thats why I had to switch. I already contacted upstream but didn't get any response so far. I guess that's fixed in CVS head now[1], right? cheers, dalibor topic [1] http://article.gmane.org/gmane.comp.java.vm.kaffe.general/8452/match=kaffe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libbsf-java
Robert Lougher rob.lougher at gmail.com writes: Michael Koch konqueror at gmx.de writes: Please don't use jamvm in general. It's only available on i386, powerpc and arm. It's not ported yet to other archs and Porting to 64-bit archs is hard due to the 32-bit ugliness in the upstream code. Better choices are gij, kaffe or sablevm. And with such ringing endorsements as this I seriously wonder why I spend most nights and weekends working on JamVM. Of course use the best VM for the job, but OSS is such a thankless task at the best of times. I think JamVM is excellent (and could use more developers, for all its kick ass goodness as it is what many people use to hack on GNU Classpath), and I'm sure Michael agrees, too. There is a Debian specific requirement for packaging, that's the unspoken assertion there, which mandates the broad architecture support. That being said, porting a VM around is fun and pretty educational, so if people want to see another nice fast and very lean VM on their architecture, helping out on porting JamVM is a very good idea. And Rob is as responsive and kind as a software maintainer ever gets, I think. For the record, 64-bit support is the next thing on my TODO list -- I've recently bought an AMD64 machine specifically to do this. I'm currently finishing off a port to MacOS X which people have been asking for (sadly only PPC32 because I don't have a G5 machine, but I do have a mortgage). Perhaps it's time to re-prioritise my evenings and look at the pile of books I never get time to read. I'm running into the same problems with arch availability. I have found HP's TestDrive[1] to be quite helpful for porting Kaffe and keeping it in shape on various platforms. That and getting in touch with people who develop on some platform to get an account or two. I can send you more details if you're interested, Rob. cheers, dalibor topic [1] http://www.testdrive.hp.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libbsf-java
Wolfgang Baer WBaer at gmx.de writes: Dalibor Topic wrote: Wolfgang Baer wbaer at gmx.de writes: But, kaffe is atm horrible broken for most package builds due to bug (#295014). Every second package fails due to this bug to build. libbsf-java is one of them thats why I had to switch. I already contacted upstream but didn't get any response so far. I guess that's fixed in CVS head now[1], right? Yes - that was before the test with todays CVS. Great! Excuse me while I do a little celebrational dance for Guilhem Lavaux, who's been hacking away on the core for a while to fix all sorts of ugly problems. :) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experimenting with building libxalan2-java with free vm's
Wolfgang Baer WBaer at gmx.de writes: Hi all, Therefore the first question: Are any of the free vm's capable of using the -Djava.endorsed.dirs feature to overwrite the interfaces ? Not yet, afaik. Gcjers are working on it, I plan to follow what they do, but haven't been following the discussion and implementation that closely :) As I didn't succeded with this try I moved on to jamvm - it seems that there I can override runtime classes by positioning them before /usr/share/classpath/glibj.zip in the classpath. You can do that with Kaffe, as well, afaik, using the -Xbootclasspath/p option. which is a measily workaround, I know, I know :( cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: libbsf-java]
Wolfgang Baer WBaer at gmx.de writes: The difficulty (once 64-bit support is done) with porting JamVM to these architectures is the calling convention. Other VMs (e.g. SableVM) rely on libffi to do this portably. I prefer to instead use hand-coded routines for each architecture/platform (using assembler), to make calling JNI methods as efficient as possible -- JNI is notoriously inefficient as it is. Kaffe uses its own sysdepCallMethod code but can also use libffi as an additional option. See config/$arch/sysdepCallMethod.h for details. See config/sysdepCallMethod-ffi.h for the wrapper for ffi. Feel free to merge it into JamVM, if you think it's useful. My personal plan is to merge in libffi into Kaffe as well, and use it as a default on Linux at least, and then to gradually switch to it for other platforms. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experimenting with building libxalan2-java with free vm's
Wolfgang Baer wrote: Yes, I read a bit of this thread - but I think that was (only) for some packages. As I remember the w3c package (the problem for xalan2) was one of the packages mentioned. Yeah. I though endorsed override would only work for some selected packages anyway, though. Better a workaround than nothing :-) I will try it. BTW - these options are not mentioned in the manpage - only with kaffe --help. I just searched for them . I will update the manpage in the next days and post it to the kaffe list. Awesome! Thanks! cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: libbsf-java]
Robert Lougher rob.lougher at gmail.com writes: Hi Dalibor, Dalibor Topic robilad at kaffe.org writes: Kaffe uses its own sysdepCallMethod code but can also use libffi as an additional option. See config/$arch/sysdepCallMethod.h for details. See config/sysdepCallMethod-ffi.h for the wrapper for ffi. Feel free to merge it into JamVM, if you think it's useful. I'll definately have a look at it. Thanks for the pointer. Have you done any benchmarks to see if there's any difference in method invocation speed? It's certainly a good way to get a port up and running fast. Not me, others may have. We should take that to the Kaffe mailing list, though. My personal plan is to merge in libffi into Kaffe as well, and use it as a default on Linux at least, and then to gradually switch to it for other platforms. To clarify, you mean to put libffi itself into kaffe, i.e. not use it as a separate library? I'm probably completely wrong, but I had heard something about libffi being part of gcc, and hard to find/install as a separate entity, i.e. on an embedded system. Is this why you'd merge it into kaffe? Yeah. Kaffe is a bit of a everything in a box, VM, class libs, tools, and all that, but it's also pretty highly customizable. So for people looking for an 'out of the box' solution for the common Java-related problems, merging some of the core dependencies, and resyncing with them reduces the burden on the user/packager to do some sophisticated packaging work. Kaffe runs on a lot of platforms that don't have such excellent packaging support that Debian enjoys. :) The other, more important side is of course encouraging people to hack on libffi, as with 1.7 M loc in my hands in Kaffe, I'm a firm believer in using other people's good code rather than inventing my own from scratch, and promoting those efforts :) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help on java packaging
Wolfgang Baer wbaer at gmx.de writes: gjdoc is not working in the new kaffe package :'( Also, note that the ant task call the 'javadoc' executable in JAVA_HOME ,[ ant-1.6.2/src/main/org/apache/tools/ant/taskdefs/Javadoc.java ] | log(Generating Javadoc, Project.MSG_INFO); | | Commandline toExecute = (Commandline) cmd.clone(); | toExecute.setExecutable(JavaEnvUtils.getJdkExecutable(javadoc)); ` But it was working in the old release, or ? I succesfully build my api doc with gjdoc. It worked in a pbuilder environment, so theres neither a non-free jdk present nor a JAVA_HOME set. I used the exec executable=gjdoc ... task, not javadoc ! It's a bug in latest GNU Classpath (I have no idea whether it occurs in GNU Classpath 0.13, Kaffe closely tracks Classpath's CVS head, and integrates the latest patches on a daily basis). Someone broke the generated locale information in GNU Classpath, and left out the collation information, and noone noticed till recently. I've filed a bug report and hope someone can fix that issue soon. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Raul Miller wrote: On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote: If Eclipse does use JNI, would still a question about whether or not Kaffe's JNI implementation constitute some kind of extension designed to work around the GPL or whether they are some kind of implementation of some Java standard. They are an implementation of some Java standard. Or is Eclipse 3.0 using only the facilities which Kaffe provides for arbitrary byte code? Yes. There is nothing in the FAQ that would suggest that these facilities have to be provided for a specific program. There is nothing in the FAQ to suggest that a GPLed JNI implementation has to be a problem for arbitrary code, though of course it does point out JNI as a issue that can be a problem. But for problem resolution, the FAQ is saying that certain things need to be released in a GPL-compatible way, not that no release can happen. Yes. The internals of how a GPLd interpreter goes about loading GPLd parts of itself, whether through JNI, dlopen, lt_dlopen, or by asking its users to punch holes on cards are irrelevant. Just because my long replys to anti-GPL fud cause a GPLd garbage collector to run ocassionally in a GPLd text editor that I use, doesnt mean that the authors of the text editor can restrict my long replies to be licensed under the GPL :) An interpretation of the GPL where, depending on the internals of the GPLd interpreter, the GPL of the interpreter would restrict its use to GPL-only data would go afoul of DFSG #6 and #9, I guess, beside claiming rights that are not given to an interpreter by the copyright law. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Grzegorz B. Prokopski wrote:
Yet, if you *package* this program together with a JVM, so that when
the user says I want to build this package or I want to run this
package the user gets your program with a specific JVM, then it's not
a mere aggregation, but these two are explicitely bound together.
a) it's not packaged together as Kaffe does not end up in the Eclipse
package, and no *copyrightable* parts from Kaffe either, afaik, because
Eclipse is not a derived work from Kaffe.
It's the 'HelloWorld' example over again:
public class HelloWorld {
public static void main(String [] args) {
System.out.println(Hello World!);
}
}
This is an extremely complicated Java program written against the J2SE
1.0 API. Is this work a derived work of Kaffe?
I think it's quite obvious that it is not.
Compiling this with a Java bytecode compiler against Kaffe's class
library and Sun's class library fascinatingly results in exactly the
same bytecode sequence. Is that class a derived work of Kaffe, then?
Nope. For a copyright based license to work its 'derived/copied/modified
work' magic, there needs to be something copyrightable in a work that's
created from the GPLd work. Remeber that the original work in source
code for HelloWorld was not a derived work, so something GPLd,
copyrightable needs to be added to the output of the translation between
the source code and the byte code for a derivation claim to hold.
Most of the content in the HelloWorld.class file is dictated by external
factors, like the Java class file format. There are a couple of strings
in the class file that are present in both Sun's and Kaffe's class
library, like 'out', 'println', or 'System', though. Do these strings
support a derivation claim?
Nope. They are from the non-GPLd source code, actually. The ones that
are not, are in there because of 'scenes a faire' of the java byte code
format, and the compilation to it. They are not copyrightable
expressions. No copyrightable expression from Kaffe's handful of GPLd
class libraries that implement the standard Java apis ever ends up in
the bytecode compiled against them, afaict from writing the ocassional
java bytecode compiler in my youth. :)
Unfortunately, apparently emulating a failed Unix(TM) vendor helplessly
attacking a different GPLd project, you refrain from telling which file
and line specifically in which class in the Eclipse packages where and
how you believe to infringe on which GPLd file and line in Kaffe. That
is kind of funny, since your theories about how copyright works appear
to be quite similar to SCO's understanding of it. SCO, among many other
funny things, claimed that Linux was shamelessly stolen from it, because
it contained 'int a;' somewhere in it.[2]
b) Using a GPLd program to process data does not restrict the user in
any way regarding the license of the data to process. So much for the
generic claim about Kaffe's GPL propagating through using it to build
something with it.
c) GPL allows users to run GPLd programs for any purpose without letting
the GPL'd program impose restrictions on its data. So much for the claim
about running.
cheers,
dalibor topic
[1] No, just because there is a string 'java.lang.Object' in a class
file, it does not make it a derived object of Kaffe. That's because GPL
is a copyright-based license, so 'Scenes a faire', abstraction,
filtration, and all that nice stuff from copyright law play quite a bit
of a role. While non-free, click-wrap licenses often contain clauses
where the copyright holders make claims that go beyound what copyright
law gives them, GPL is not such a license, and it shouldn't be
interpreted accordingly.
Kaffe's copyright holders couldn't claim copyright on that string any
more than they could claim copyright on the strings 'URL', 'http://' or
'stdio.h'. All these strings are part of Kaffe, afaik, but that doesn't
mean that they are original, copyrightable work of Kaffe authors. You
can't enforce a copyright-based license on something that's not
copyrightable, like the string 'int a;'.
Otherwise, it could equally be argued, using Gadek's theory of copyright
without regard for copyrightability of an expression, that if SableVM
contained single words from the JVM specification in its source code or
binaries, like 'IllegalMonitorStateException', it was a derived work
from it, and wrath of the spec's creator hung over its head and those
that distributed its packages.
Which would be, in my opinion, utter bullshit. But then, my
understanding of copyright law is obviously different from Gadek's.
[2] 'How Kaffe stole UNIX from SCO' in
http://www.advogato.org/person/robilad/diary.html?start=56
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Grzegorz B. Prokopski wrote: If you at least went on and read next paragraph of the FAQ from which you took the above. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way. Which part of other facilities do you fail to comprehend? A GPLd intrepreter can not, because of what the GPL and copyright law actually say, instead of what you may wish they said, impose restrictions of the GPL unto the data it interprets. It can bind to *itself* until it gets blue in its face, but *the interpreter* still can't impose restrictions on its *input* or *use*. The clause is there to state that even though a work A may be used on a GPLd interpreter, the GPL of the interpreter does not 'preempt'/fullfill the GPL of other works that A derives from. In simple words, for you, so that you can finally get it: You can't create a work that derives from a GPld work, and use a GPLd interpreter to work around the GPL of the work your work derives from, because the interpreter has no business in shielding you from it, even though it doesn't 'propagate' its own GPL on your work that you are using with it. Confusing? That's probably why the FSF put it in a FAQ. I guess someone tried to circumvent the GPL using a GPLd interpreter to 'shield' them, and then the FSF had to make sure people understood how things work. How Kaffe, the GPld interpreter, goes about loading GPLd parts of *itself* into memory, whether it uses JNI, KNI, dlopen, FFI, libtool, or other bindings, or whether it asks the user to tilt switches on an array of light bulbs is irrelevant to the copyright law. The GPld interpreter still can't impose restrictions on its input or use. Just like a GPLd garbage collector going off in the background of my text editor when I'm composing a reply doesn't suddendly make this reply message GPLd. Now, before you go off ranting about Kaffe's native libraries, please take a moment to let the fact sink in that while these native libraries are the result of Kaffe developers being a somewhat clever bunch at developing software and having heard about benefits of seperating one's program into sepearte modules, those modules are nevertheless *a part of the interpreter*, and as the copyright law law says, the GPLd interpreter can't impose restrictions on its input. They even get compiled in statically on Debian for debian's kaffe package. Would you please, please stop regurgitating this nonsense. The FSF's FAQ is perfectly fine. It's your casual reading of it that it wrong. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen wrote: Måns Rullgård [EMAIL PROTECTED] writes: It is compiled against an interface, not an implementation. Which particular implementation was used while compiling is irrelevant. Can you support this assertion? The program, including its libraries, which the developer intends to put on end-user systems appears quite relevant to me. For a file written in Java, all that ends up in the compiled bytecode file from a library its compiled against are a bunch of strings denoting class, interface, field and method *names* that are used from the library, if any, but not the actual content of the library, i.e. actual expressions of data structures or methods as they exist in the library. That's a major difference between Java classes and C headers. For Java APIs that are defined by some specification like J2SE 1.4, the developers of a GPLd class re-implementing it would have a hard time claiming copyright on the class, interface, field or method *names*, as they are not their own original work to claim copyright on, but are the result of the necessity of implementing an already existing specification. It would be the same as SCO's bogus 'Linux uses Unix interface names, so it all belongs to us' claim. When the *names* are not copyrightable content, then there is no way for a copyright-based license to work its magic into works that just include the *names*. If the names are original work of the authors, then they are copyrightable, and then the GPL works. If they are not, like the name java.lang.Object is not my original work, then it would be a pretty far off claim :) For the rest of the argument, I kindly refer to Andrew Suffield's analysis of Gadek's claims about 'undistributable Java in main' from 2003: http://lists.debian.org/debian-legal/2003/11/msg00010.html http://lists.debian.org/debian-legal/2003/11/msg00026.html cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen wrote: I am. I'm not talking about the .deb file containing Eclipse. If you think you can provide someone with the Eclipse IDE program without providing a JVM, I invite you to try. You mean like Fedora? Eclipse 3 nicely compiled to native with gcj, yum, and balzing fast, for all I've heard. I wish debian had better gcj support. :) When I instruct my computer running the Debian OS to load and run eclipse, the code from some JVM package and the code from the Eclipse package and from dozens of others are loaded into memory. The process on my computer is mechanical, so we should look back and see who has designed and created this particular combination. In this case, it was Debian, who took the top level Eclipse component and selected a particular JVM and particular support libraries to include. That's the 'running is illegal/GPL puts restrictions on use' fallacy. :) You can't violate the GPL of a program by running it. The GPL only talks about 'copying, distribution and modification', and explicitely says 'The act of running the Program is not restricted'. Whether the GPLd program loads non-GPLd works in memory is irrelevant. What's relevant is whether works are actually copies, modifictions or derived works. Or all my e-mail would have to be GPLd, as it's loaded into the memory of a GPLd program :) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Grzegorz B. Prokopski wrote: Your email messages do not contain calls to GPLed functions, do they? Depends on the message :) But that's not the point. The point is that the mere existance of a chunk of non GPL-compatible memory within a GPLd proces' memory does not necessarily constitute a GPL infringement. It depends on what the program does. My text editor's GPL is not violated just because I happen to load GPL inompatibly licensed files with it into its proces' memory, edit them, and save them. Neither does that coexistance of GPLs and non-GPLd works in the same process space let my GPLd text editor impose its GPL on the files I edit with it, because no GPLd part of the editor ends up in the files I save. Brian was asserting that coexistance in process memory alone of GPLd and non-GPLd works costituted a GPL infringement. That's certainly not the case. It would be pretty hard to apt-get non GPL-compatibly licensed packages, otherwise :) It's quite a stretch to compare dead data, like text, with something as dynamic, as bytecode, which not only can be created, modified, translated or interpreted by a JVM, but it can also explicitely make use of JVM functionality (which happens to be GPLed in case of GPLed JVMs). An interpreter acts like a filter to its input. The GPL gives no hand to the author of a GPLd interpreter to put restrictions on the data it is used with. That interpretation of the GPL would render it non-DFSG-free, by imposing a restrictions to running GPLd programs only on GPL-compatibly licensed data. The GPL's text doesn't make such demands. There is no such thing as dead data to an interpreter. Whatever data you feed to Kaffe, for example, it does something lively with it, like print an error message, crash (well, i haven't tested all possible data streams, so I better assume it), or interpret it, depending on the data. What sort of functionality of the GPLd interpreter is used by the bytecode during its execution, is irrelevant to the fact that the GPLd interpreter can not put restrictions on its input. No matter how convulted a linking scheme the interpreter uses, it can't get 'Super-GPL-Powers' that would allow it to impose the GPL on its input through the act of the input being run on it. Any Java bytecode makes explicit use of JVM functionality through sequences of small byecode-langiage commands like 'invokevirtual', 'add', 'sub', 'dup' and so on. The fact that the bytecode is run on a GPLd interpreter does not let the intepreter impose the GPL on its data, just because the implementation of 'add' in that interpreter is GPLd. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
Grzegorz B. Prokopski wrote: I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Voila! GPL is uselless. GNU Bash (which uses readline) makes GPL useless because it doesn't force all bash scripts to be GPLd? Wow. I'm sure the FSF will appreciate your insight on GNU Bash and the usefulness of the GPL :) Looking through the bash documentation, I can find no statement from the FSF that says 'all your scripts are belong to GPL' or an exception for non-GPLd scripts. I think your reasoning about a hole in the GPL is deeply flawed. The GPL works as it should, it just doesn't work like a click-wrap non-free license, like you think it does, and would presumably like it to do. It would truely be useless if it did work the way you think it does, as then the GPL would not be DFSG-free. There exists java.lang.System.mapLibraryName() pure java method. This method calls java.lang.NativeLibrary.getLibPrefix() and java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE methods, and are implemented by ./libraries/clib/native/NativeLibrary.c file, which is part of kaffe, and therefore available under the GPL. Those libraries are *a part of the GPLd interpreter*, so they can not magically let the interpreter impose the GPL on its input. Therefore only the second case mentioned in the FSF FAQ applies. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism. There is no contradition between the first part of FSF's statement about a GPLd intepreter not being able to restrict its input and this part. The part you quote is not about the interpreter, it is about *other* facilities that are bound to interpreted data. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen wrote: I'm not talking about running; I'm talking about making a copy of Eclipse and a copy of Kaffe and putting them both on an end-user's system such that when I type eclipse I get a program made out of both. You don't get a program made out of both any more than you get a program made out of less (GPL) and eclipse (CPL) by typing less eclipse That doesn't make eclipse a derived work of less. As I was politely asked to educate people not getting what a derived work is, let me use a nice, graphical analogy. A lot of talk about software licensing is crap, so I hope you don't mind me using terms everyone, I believe, is familar with. You can wipe your ass with 100 USD bills without violating the copyright law, for example. By doing that, you create a derived work of both your shit and the 100USD bills. Now, if the 100 USD bills came with a DFSG-free license, you could copy, modify further and distribute your modified work to other people, if they cared about 100 USD bills with your shit on them. Does the fact that you can wipe wour shit with 100 USD bills means that your shit straight out of your ass is a derived work of the 100 USD bills you use to wipe it with? No, unless you eat some 100 USD bills first, and can find bits and pieces of the bills in your feces. Even if you ate 100 USD bills, and went to shit five minutes later, it does not automatically follow that the heap shit you made five minutes after eating the bills actually contained any portion of the bills you ate 5 minutes ago. It could have been different bills, or something you ate before. That's what people mean when they say evidence is no proof. You have to examine what's happening, dig your hands into the shit, and find the pieces of the bills sticking out to prove that an original work of love and labour, the pile of shit, is a derived work from the 100 USD bills. And that's why noone with a good sense of smell likes goddamn awful long boring pissing matches on debian-legal about hypothetical license interpretations like this one. People get shit all over their hands from digging around and other people start throwing shit around. It makes everyone stink. The visualisation of what consititues a mere aggregation of shit, and what constitutes a heap of shit deriving from other people's shits, invokes unpleasant images in my head, and is best left as an excercise to the so inclined reader. Now, can we please end this discussion? cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen wrote: Måns Rullgård [EMAIL PROTECTED] writes: [large discussion of C snipped out] In the case of Java, the binding is even looser. A class might contain references to other classes which the JVM is free to look for anywhere it pleases. AFAIK, Eclipse uses only the standard Java API as published by Sun, and will run equally well with any implementation of said interface. Great -- which implementation does Debian ship it with? That's all that really matters. I disagree that it's all that matters. It also matters whether the implementation that Debian ships actually puts any restrictions on the license on its data, or whether it doesn't. Kaffe, being an interpreter, does not, afaict: When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.[1] As the GPL of the interpreter does not place any restrictions on the data, the incompatibility of intepreter's GPL and data's CPL does not matter, as the data never becomes limited by the GPL and the license conflict never happens. cheers, dalibor topic [1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
://lists.debian.org/debian-legal/2003/11/msg00010.html http://lists.debian.org/debian-legal/2003/11/msg00026.html which are quite reasonable interpretations, afaict. Deal with it. :) If you have another question in the context of the Debian project, you can ask debian-legal, I'm sure they will be able to help out. I find it tiresome to rehash the same disagreement about interpeting the GPL over and over again each time there is a new SableVM release to promote. Be it ANY JVM, but be it legally usable for the task. I would be happy if SableVM was used, because of very practical reasons. GCJ/GIJ we have in Debian has realatively old Classpath, compared to SableVM, so might not be good enough to run Eclipse. OTOH I have not noticed IKVM being packaged. Have I missed any non-GPLed VM? If not, then I think using SableVM gives the best chances of success. IKVM is packaged actually. Kissme is packaged, too. :) Look, SableVM's licensing FAQ doesn't even claim to be legally binding. So your claims about it being illegal to use other VMs (like JamVM) are based on the assumption that SableVM's licensing FAQ's claims are valid. But SableVM developers make no such claims, they say The answers provided in this FAQ are correct, as far as we can tell, but they are not legally binding. Only the licenses provided along the software are legally binding. If you are unsure, please seek legal counsel, or make contact with the copyright holders. which translates to 'IANAL, maybe it's all bogus, if you think you need a lawyer, ask for one, or ask someone who knows what they are talking about'. That's a perfectly fine advice, and I agree with that. But in this discussion you're taking something that's 'maybe true' and postulating it as an axiom from which you then derive things that you shout around as absolute truths. That's a cute rhetorical trick, but it doesn't work that well when you're obviously not so sure about the validity of your axioms yourself. :) That's very nice of you. Could you please keep personal jokes out of the picture? Thanks. No, really. It's not a joke. I think SableVM deserves a lot of popularity and success because it has some great developers, like yourself, hacking and maintaining it. You guys have done a lot of nice work to advance the state of the art in that research area, as well as to write a nice, portable VM that runs pretty well on most debian arches, as far as I hear. So I sincerely wish you most success in pursuing your goals, and for SableVM as well, because I think you're all a bunch of very nice and bright people that will make it far. I also believe that SableVM is a nice addition to Debian that makes Debian more useful to a lot of people. Keep up the great work! Just because I think that the attempts in that SabmeVM licensing FAQ to cast doubt on Kaffe's (and other VMs') legality are pretty bogus and lame, doesn't mean that I don't think that the author of the SableVM licensing FAQ is a wonderful person in general. Everyone makes ocassional mistakes of judgement, even the brightest people, that's human. As we've been thru the issue once already, I ask you to at least cut off personal attacks. Otherwise you'll gurantee we won't get to any conclusions. I'm sorry about the personal attacks, I didn't mean to hurt. I'd like to apologize for any such attacks slipping into my reply. If you point out to me where I crossed the line, I'll try hard to avoid that next time around. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running on Kaffe
Thomas Fogwill tfogwill at csir.co.za writes: This build runs fine (so far) with kaffe, but does not run at all with any other VMs: (tried: Sun's 1.4.2 JDK, SableVM, gij). As this is the case, would it not make sense to add the following to the /usr/bin/eclipse script? -VM /usr/lib/kaffe/bin/java Hm, I'd prefer to see it actually work with another VM, too, rather then tying it to a single VM. SableVM developers also reported success running Eclipse3 it, could you give the packages a try on it, as well? As Jerry said, he'll bug everyone else with bug reports, so I'm sure that whatever remaining small hacks are necessary for other VMs will happen quite quickly. I'm looking forward to Eclipse in main on several free runtimes! cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Michael K. Edwards wrote: [Regarding the compatibility of a GPL JVM with Java code under other licenses; cross-posted from debian-java to debian-legal] [cut noise about FSF] But if the Kaffe copyright holders interpret the relationship between Java bytecode and GPL code to be loose enough not to create a derivative work, I think they have at least US case law behind them. The relationship between GPL, interpreters and bytecode has been rehashed here already before (with the same participants, old hat, and all that ;): http://lists.debian.org/debian-legal/2003/11/msg00010.html http://lists.debian.org/debian-legal/2003/11/msg00026.html As you can see, bytecode does not necessarily make the relationship looser. Nevertheless, the claim that is made by a particular developer of a 'competing' VM project on debian-java about running Eclipse on Kaffe being illegal, is wrong, in my non-lawyerish opinion, because Eclipse's source code or bytecode does not derive specifically from Kaffe's interpreter or class library, afaik, but uses 'standard' Java APIs all the way. Just as explained above in the links. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running on Kaffe
Grzegorz B. Prokopski gadek at debian.org writes: FWIK soon after SableVM 1.1.8 release GNU Classpath got fully merged a version of jaxp that is capable of running Eclipse (the above instructions do not use jaxp). We should have the new, fixed version of jaxp included in 1.1.9. Great! Thanks for the good news! cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running on Kaffe
Grzegorz B. Prokopski gadek at debian.org writes: See http://sablevm.org/wiki/License_FAQ for details. Gadek, last time you've taken your claims to debian-legal, noone on debian-legal agreed with your interpretation of the GPL. Sorry. Maybe your interpretation is not all you make it up to be. ;) I find it tiresome to rehash the same disagreement about interpeting the GPL over and over again each time there is a new SableVM release to promote. I personally think that SableVM is a vey nice VM. And I wish you more success than you can handle. Seriously. May you all be rich and famous and icons of scientific research and may all your dreams come true. So that we can that fine day finally stop having to go though this ritual 'Our GPL interpretation is longer than yours, although we are not a lawyers, either' discussion each time there is another point release of SableVM. It's so cheap and boring and repetitive and repetitive and repetitive ... you get the idea. Did you try to build other architectures? If the build process involves using a JVM then it would be best to use a JVM that works on as many architectures supported by Debian as possible. Last time I asked Dalibor it still had serious troubles on many non-x86 architectures. By all means, please make it run on all VMs packaged in debian. Given that we all use Classpath now, more or less, it should all work, more or less. JamVM is another very fine choice, and so are gij and IKVM as well. I hope I haven't left anyone out, because I think all GNU Classpath-based runtimes are great. The more, the merrier. The more VMs the package runs on, the better for the users. If a VM sucks on their architecture, then they can use another one. Choice is wonderful, as most software sucks, anyway. Looking though the debian bug reports, Kaffe has a problem with nice on amd64, which I hope to have solved this week in Kaffe's CVS. The FTBFS on arm is entirely jikes fault, unfortunately. I think that's about it regarding architecture-specific bugs in debian. On the other hand, I have no access to most debian architectures, so I have no idea how well the packages work there, unless people report bugs. I wouldn't deduce from the absence of bug reports that it works great, I'd rather guess that not enough people are using it to stumble over the blunders ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: j2se1.4 for sparc
Andy Tolonen tolonen at MIT.EDU writes: Hi, I am hoping someone can help me with a java newbie question. I need to run an application that requires a JVM that supports J2SE1.4 or later. My machine is a Sun Ultra 10 (ultrasparc processor) running Sarge. It appears from blackdown.org that J2SE1.4 is not available for sparc. Is there anyway to run an application requiring J2SE1.4 on a sparc machine running debian? If not, how long might it be until this is possible? I don't think Sun supports their JVM on sparc-linux, so you're out of luck, afaict, if Blackdown hasn't got a port for it. You could try to run the app with kaffe, jamvm, sablevm, gij, ikvm, or another free runtime packaged for debian. Chances are they are able to run your app, as long as it doesn't use one of the missing features in the class library that are not implemented yet. They support the majority of 1.4, though. Help implementing what's missing is welcome, as well as bug reports. cheers, dalibor topic
Re: compiled with Kaffe, failed in Sun'J2RE
Cai Qian caiqian at gnome.org writes: Hi, I just try to get my Java packages to Main. I am using jikes along with Kaffe to compile my program and libraries. Finally it works in Kaffe (although it runs slower and has some minor problems when receiving/sending packets to network). However, while I tried it in Sun's J2RE 1.5.0_01, I got the following error. Exception in thread main java.lang.VerifyError: (class: org/eclipse/swt/dnd/DragSource$1, method: handleEvent signature: (Lorg/eclipse/swt/widgets/Event;)V) Illegal use of nonvirtual function call at org.eclipse.swt.dnd.DragSource.init(DragSource.java:174) There may be a bug in the compiled eclipse swt packages, that's picked up by sun's verifier. It could be a bug in the compiler used to build them, or it could be a bug in Sun's VM. You'll have to look at the SWT source code mentioned in the stack trace to figure it out, or to disassemble the class files and look at them sharply :) If you're using debian's SWT jars, please submit a bug report for it with a test case to reproduce it. cheers, dalibor topic
Re: ok in Sun' JDK or Kaffe but SableVM
Cai Qian caiqian at gnome.org writes: I see. Thanks for your work. Thank you for using and supporting free runtimes with your software! cheers, dalibor topic
Re: Tomcat 5.5.4 works with kaffe
Ryan Harris rharris at usapoolsupply.com writes: Thanks a lot for sharing your guide with the list, Ryan. I didn't know kaffe could run tomcat 5.5 myself, so maybe you could post it on the kaffe mailing list as well? cheers, dalibor topic
Re: ok in Sun' JDK or Kaffe but SableVM
Cai Qian caiqian at gnome.org writes: Hi, My package runs quite well in some VM such as Sun'JDK or Kaffe, but when I tried it on SableVM I got a following errors. What's a problem there? As GNU Classpath doesn't have a javax.sound implementation yet, I've merged in the one from Tritonus into Kaffe a while ago.[1] It worked pretty good for me, for playing mp3s or ogg streams using esd or ALSA, so I'm glad to hear that your application runs fine on Kaffe. One of my new year's resolutions is to see what work needs to be done for getting Tritonus merged into GNU Classpath so that it can be easily used out of the box by all the other nice free runtimes, like SableVM. cheers, dalibor topic [1] Kaffe provided a nice integration test-bed for some other projects getting folded into GNU Classpath, chances are it will be the same with Tritonus, too. ;)
Re: Free JREs
Mariano Garca mariano.garcia at optivamedia.com writes: Hi all, Hola Mariano, * I want to try a free jre (i think something like kaffe). What is the better free jre? I mean, I have some programs made with Sun JRE, so I want to try the most compatible free jre with Sun jre. There is no single best in a global sense, all free runtimes have specific advantages and disadvantages. Try them out, and use what works for you. Bug reports are welcome, too :) As noone has access to JRE's compatiblity tests, noone can say how compatible any free runtime is. * If I use Kaffe (for example) Can I use java debian package like eclipse, argouml, ... ? You can't use all of debian java packages with free runtimes yet, unfortunately. There are many reasonas for this, some of which depend on the upstream of the respective programs, and some of which depend on the upstream of free runtimes . For example, some programs have parts that are not written in portable Java. In other cases free runtimes lack specific functionality required by those packages. But you're most welcome to help with the work associated with pushing more java packages into main! cheers, dalibor topic
Re: apt and java
Omry Yadan omry_y at inter.net.il writes: I fail to see a proof of the 'it costs debian users' assertion you made in this response. Quite simple: 1. Eclipse - not in main, contrib, or non-free. Which has *nothing* to do with its ability to run on free runtimes. I'm sure Jan would appreciate your helping hand packaging eclipse. Check the list archives for details. 2. Tomcat - in contrib only. It wouldn't move to main with a non-free JDK anyway, so what's your point? 3. Azareus - not in main, contrib, or non-free. Please read the fine ITP for Azureus. There is *nothing* in it that mentions free runtimes being a stumbling block for it. Whatever your beef with free runtimes is, it's not based on facts. Spreading FUD how making 'good java programs' run on Kaffe and others 'costs debian users' something is *not* aiding your case. Please, put a bit of effort in it and check your facts before you post. If you could refrain from using broken analogies, that would be great, too. Having Sun's JDK around is not a matter of life and death. It can't be that urgent, as Debian has done just fine without it. Relax. If you need the JDK, you know how to get it. Slapping Sun's JDK into debian would not automatically make an eclipse package appear in debian, or an Azureus package. Those things have close to nothing to do with each other, except that java programs need some sort of a runtime and the JDK happens to provide one. You, personally, can make an eclipse package appear without having Sun's JDK in debian, just like tomcat is in debian without the JDK being around. But it takes work. More work than this discussion, certainly. It takes good people to make packages. The availability of runtimes is just a side issue, that has already been solved, afaict. As I said, you can be part of the solution, by adopting packages, fixing bugs and bringing more Java software into debian in general and (if you can get rid of that anti-free-runtime bias) by helping move them to main by making them build and run on free runtimes. But on the other hand, you don't have to, it's up to you. cheers, dalibor topic
Re: apt and java
Omry Yadan omry_y at inter.net.il writes: Dalibor Topic wrote: How much does making 'good java programs' run on free runtimes 'cost' Debian users? ;) Now, that depends on the maturity of free runtimes. both in terms of stability (which I don't know anything about yet), and in terms of level of compatibility to sun's jvm's provided API's. I fail to see a proof of the 'it costs debian users' assertion you made in this response. Its not about me. its about all those poor souls out there, looking to install their favorites free java programs, only to find that there is no trace of them anywhere in apt. Then please help those poor souls that you care about by testing free software written in java with the free runtimes and giving a hand to the developers packagers of the respective software, for example by telling the packagers that some software now works with Kaffe, sablevm, gij, IKVM or JamVM. Or that it doesn't. It's that easy to reach what you want. I recommend checking out http://java.debian.net/index.php/MovingJavaToMain and helping to get things moving faster. I will find a way to run what I want, but for most users, who are spoiled by the excellence of the apt system, it will be too hard. When a package is in main, it's the usual apt-get excellence. I don't see a problem there. So let me state again what I am after: To provide users with the ability to install most java programs seamlessly, today. Good, me too. :) not when the programs have been modified (if needed) to work with the free runtimes, or when the free runtimes are ready for them. As Debian can't legally safely distribute Sun's (or any other sun-derived) VM, that's not possible, afaict. If you don't like that, you can try to get Sun to fix their broken licenses. Good luck, though I think it's a major waste of effort :) I want to achieve it in a way which still pushes the free runtimes forward, and does not make them obsolete. That would not make them obsolete. They are simply playing in a different league from Sun: they are free, unencumbered software. Just like Solaris 10 doesn't make Debian obsolete. :) and of course, I want to achieve it in a way which is legal (from sun's point of view), and that is compatible with the Debian spirit. People have been looking at various Sun's (and other proprietary VM vendor's) licenses for 7 years now, and there was no way to do what you want in the context of Debian. The licenses are filled with hillarious, contradictory claims, and are legally amibiguous, to say the least. So Debian is not going to get into the risk of distibuting such dubiously licensed code. And it's definitely not in the 'Debian spirit' to force or even encourage people to use dubiously licensed code, so your effort, though no doubt well-meant, is beating on the wrong bush. There is nothing Debian can do to support Sun, because Sun *does not want* to be supported by a volunteer project like debian according to their license terms. That ball is in Sun's park. You can either chose to continue beating the dead horse, or do something about it. If you chose the latter, you can either go and tell Sun to do what you want them to do, or you can help to make that sort of questions irrelevant by improving the support for and from free runtimes. People who have done the latter, have made some great progress on getting Java programs into Debian's main distribution. You, too, can be a part of the team working on the solution, rather than spending your time on something that you can not influence (Sun's licensing policy). And you can back up that 'pretty much garanteed' claim? clearly not, besides common sense, and some experience. Postulating your 'commons sense' and 'some experience' as a fact does not count, so ... claim dismissed :) cheers, dalibor topic
Re: RFP: jrockit -- A virtual machine for Java
Johan Walles wrote: I've attached the re-distribution license agreement to the RFP at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273693;. It's in MS Word format, but it opens fine in OpenOffice. Argh. It's a software license. There is no need to make MS Word files out of it, afaict. Sigh. I couldn't spot any show-stoppers in it, but then again, I might be biased :-). No problem, that's what you got debian-java for (and debian-legal for the real test) :) 2 (iii) Distributor may modify the Software in accordance with the Documentation solely to allow for interoperability with Distributors internal MIS systems. seems to prohibit distribution of packages. In practice, packaging 3rd part software not written for Debian usually means making a tweak or two to the software to get it to fit into the distribution. The word 'internal' seems to indicate that such modifications may not be distributed to others. On a side note, what is MIS? 2 Any such modifications made in (iii) above shall not be derivative works, and Distributor shall not create or attempt to create any derivative works from the Software. Uh, tricky. Does a package consitute a derivative work? :) Distributor may not disclose the results of any performance benchmarks to any third party without BEAs prior written consent. This would speak against using it in buildds to build java packages. The buildd results and timings are public. 2.1 Distribution License. BEA grants Distributor a non-exclusive, non-transferable license to (i) Reproduce and bundle or otherwise include the Software together with the Value Added Solution, and (ii) sublicense and distribute the Software, either directly or indirectly through multiple tiers of distributors, for use by End Users who agree to be bound by an End User Agreement. 2.2 Restriction. Each Value Added Solution must significantly enhance the features and/or functionality of the Software. That requires users to agree to an 'End User Agreement' that's not part of the license document. That's got a few weird clauses of its own,like ' If the version of JRockit you are licensing under this Agreement is a pre-final, beta, technology preview, or similar pre-production release (collectively, Pre-final Versions), as a condition to this license you agree to discontinue your use of the Pre-final Version and replace each copy of such Pre-Final Version with the successor general availability release as soon as it becomes available from BEA.' which is impossible to satify as BEA does not provide debian packages. The definition of 'value added solution' is fishy. On one hand, it is prohibited to create derivative works, on the other hand, it is required to distribute JRockit with works that 'significantly enhance the features and/or functionality of the Software.'. Sound like it's impossible to satify both, so one can't distribute it. Confidential Information shall be limited to the Software, the terms and pricing under this Agreement, and all information clearly identified as confidential. So the license agreement is confidential? Are you sure that you're allowed to post it to debian-java? That would explain why there is no URL to it ... 5.4 Distributor Indemnity. Distributor agrees to indemnify, defend and hold BEA harmless from and against any costs, losses, liabilities, claims or expenses (including reasonable attorneys fees) arising out of representations or warranties made by Distributor or its agents in the distribution of any Value Added Solution. For any claim arising hereunder, BEA agrees (a) to reasonably cooperate with Distributor, (b) to notify Distributor promptly in writing of the claim, and (c) that Distributor shall have sole control of the defense and all related settlement negotiations. I'd doubt that Debian would like to indemnify BEA any more than they would like to indemnify Sun. :) That's always been one of the showstopper clauses with Sun's JRE, no real difference here, afaict. I didn't use a very fine comb, though, so a review on debian-legal could turn up more problematic sections. On a side note, the fear of benchmarking in the license is funny. Sun eventually got enough courage in their implementation to strike a similar passage out of their licenses in 1.4 :) cheers, dalibor topic
Re: RFP: jrockit -- A virtual machine for Java
Johan Walles wrote: -Original Message- This represents Management Information System. This is generally a system based on a mainframe or minicomputer. Some companies have a department labeled MIS that may serve various puposes in the company, generally networking related. Thanks for the reference! Debian's apt infrastructure would probably qualify, which would solve the problems of packaging and derivative works. It would be better to have something like that in the license, though. Any idea how to creatively interpret the 'internal' bit? I thought the buildds didn't build stuff in non-free? And even if they did, the build process for JRockit would only consist of taking a JRockit tar file distributed by BEA and shuffle the files into a Debian package. Thus, the build times wouldn't contain any benchmarking of the JVM. Oh. I'm sorry about that confusion. I wanted to say that it would speak against using jrockit to build other java packages, like tomcat or ant in buildds. ' If the version of JRockit you are licensing under this Agreement is a pre-final, beta, technology preview, or similar pre-production release (collectively, Pre-final Versions), as a condition to this license you agree to discontinue your use of the Pre-final Version and replace each copy of such Pre-Final Version with the successor general availability release as soon as it becomes available from BEA.' which is impossible to satify as BEA does not provide debian packages. I don't follow you. Why would this clause require BEA ship Debian packages? If I get a 'beta' package for jrockit, then I must 'replace it with the successor' version of JRockit as soon as it becomes available 'from BEA' and discontinue my use of old JRockit version. That means when BEA releases a new version I have to stop using the old version, and wait till someone creates a package for it. Since BEA doesn't make debian packages available, it is impossible to 'replace each copy' 'with the successor' 'available from BEA'. The 'available from BEA' bit is ambiguous: shall I update my debian package with a tarball from BEA? The clause doesn't require BEA to ship packages. It requires that I stop using JRockit as soon as they update a beta I'm using, which is kind of inconvenient :) It would also need to be clarified what that would mean for debian packages of betas: do they have to be purged from FTP servers as soon as BEA releases an update? I asked to get a copy of it for the specific purpose of having it disected. But I agree the clause sounds silly, I'll ask about it. Thanks! I'd doubt that Debian would make any representations or warranties [...] in the distribution. So unless Debian promises the world to users of the JRockit .deb, this point is a no-op for Debian. Not necessarily. An indemnification clause is financially quite risky for a volunteer project, and it's never clear how those things would end up being interpreted in court. Let me try to draw up a completely hypothetical example: Let's say Debian includes JRockit as 'A virtual machine for Java'. Java is a trademarked term, and there are a lot of funny restrictions on its use to label software. BEA is a SCSL licensee, afaik. So, let's say another commercial SCSL licensee that happens to be a JVM vendor downloads Debian-sid with JRockit on it, runs the JDK TCK, and notices deviations in spec compliance on Debian-sid. Then he convinces Sun to sue BEA for abusing the Java trademark by letting Debian ship a non-compliant SCSL-derived JVM. [1] After the legal battles are settled, BEA can come to claim the cash spent on lawyers back from Debian, because it was Debian that said that 'jrockit is a virtual machine for Java', but BEA doesn't make claims that jrockit is certified on Debian. Of course this is not likely to happen, and it's a purely hypothetical example. It's intended to show that any indemnification clause puts the Debian project at the risk of becoming collateral damage in big corporate legal battles. cheers, dalibor topic [1] The claim does not have to make sense in order to go to court. It only needs to make enough sense to a judge not be rejected flat out. As soon as it gets to court, BEA could pull the 'Debian did it, not us!' joker and ask for Debian to pay up. I'm not saying that they would, I'm saying that the license offers the ability to do so.
Re: apt and java
Omry Yadan omry_y at inter.net.il writes: Making Java and Debian closer is simple: use free runtimes, report bugs help us make them better than Sun's Java implementation is all respects that you care about. This approach is costing Debian users many good java programs which rely on sun's jvm, or at least have never been tested on any other jvm. How much does making 'good java programs' run on free runtimes 'cost' Debian users? ;) correct me if I am wrong, but you are concerned mainly about these issues: Unfortunately, those are not my main concerns ;) *if we allow sun's java in in a standard way (not necessarily as a real deb), it will mean free java programs which rely on sun's jdk will not be able to into free. No. Java programs can go into main when they build work with a free runtime. That has nothing to do with some non-free Java implementation. * and it will mean less QA for the free java runtimes, because less people will risk using the free one, when they have the reliable one from sun. It is not certified for Debian, so you're making reliability claims that Sun doesn't make. I'm curious, on what factual, verifiable basis do you make them? not all users want to live on the bleeding edge. If you don't like some aspects of the current free runtimes, you're most welcome to help fix the problems you have found with them. If that's not good enough for you, you can simply ignore them 'till they are ready for your needs. Noone is forcing users to use them. You make it sound I like proposed to get the binary, hack the license out of it, and re-distrebute it. :) I was under the impression that you were looking for ways to include Sun's code into debian but to avoid Sun's license. I'm sorry if I somehow misinterpreted you. ;) yes, sun does not officially support debian, but its pretty much guarentied to work on a any system which is as Linux as the intersection between the two Linux distrobutions sun does offecially support, practicly meaning any Linux. And you can back up that 'pretty much garanteed' claim? Searching for 'jvm crash debian' on google suggests otherwise, as does the LD_ASSUME_KERNEL experience a lot of people had on ix86 with Sun's JVM. Googling for 'mozilla java linux crash' gives me more than 80 000 hits. Pretty much guaranteed to crash, I guess. ;) Jan proposed some descent things, I did not see any objections, yet - one year later, its still no where to be found in either main or contrib. Then you haven't read the whole thread. I've objected to a lot of things he said during the discussion, so have others. Of course it does. Without gcj you couldn't run Java code on a few dozens of platforms. Sun's 'anywhere' barely covers a handful of platforms. Kaffe, for example, has been ported to more than 70 platforms, including playstation2, arm-riscos or linux-sh, for example. Kaffe has been actively helping the portability of java code since 1996. you mean compile java code, not run java code. You can compile it down to native or to bytecode, and run the resulting executable code natively, or run the bytecode with gij, or another runtime engine. gcj enables you to run to compile java code. once its native, its no longer java. What do you think a JIT makes out of java bytecode? ;) although the idea of playstation2 java is cool ;). Yeah :) The craziest Kaffe port so far is for Cray, though ;) If they prove to be good enough, then someone comes up and writes better programs as free software. Happened with Unix. Happened with C. Happened with C++. Happens with Java right now. You too can be a part of it, you don't have to put yourself in a position where you depend on Sun and their choice of licensing. Well, I`ll find some time to have a look, sounds interesting enough. You're most welcome. cheers, dalibor topic
Re: RFP: jrockit -- A virtual machine for Java
Johan Walles walles at mailblocks.com writes: Unforturnately not; it's supposedly available upon request from jrockit-partner at bea.com. Thanks for the quick reply, Johan. Your first mission, if you chose to accept it, will be to get someone inside BEA to put up the redistribution license online, in case one exists. If there is no such license, then debian can't ship it anyway ;) cheers, dalibor topic
Re: apt and java
Omry Yadan omry_y at inter.net.il writes: A question comes into my mind: Was the discussion focused on how to get make java and Debian closer, or on how to avoid the horrendous sun licensing? Making Java and Debian closer is simple: use free runtimes, report bugs help us make them better than Sun's Java implementation is all respects that you care about. Avoiding Sun's licensing is simple: just don't use works covered under it. Working around Sun's licensing is pointless: if the copyright holder has weird ideas about licensing, you'd better not try to provoke them to unleash the army of lawyers on you. In particular when that army of lawyers extracted USD 2*10**9 from Microsoft. You're much better off avoiding the weird legal mess that Sun's JRE/JDK/SCSL license is, unless you have a) lots of cash to burn potentially in court, b) good lawyers at your disposal that can make sense out of the licensing mess, c) cash to burn on a commercial Java redistribution license, d) a business that can bring back the money you lose on licensing the thing, e) people willing to risk their financial existance for distributing non-free code As you can imagine, all 5 are not very likely for debian for a lot of good reasons ;) If you don't like Sun's license, don't use their code. If you don't like the free software alternatives, put some effort into making them suit your needs. I mean, there might be a way to achieve both: Maybe its possible to create a standard stub for sun's jvm? say, we add a standard JVM slot, and have java programs depends on the existence of a JVM. than, we create a deb for each free JVM (kaffe and friends?), and a standard stub for sun's jvm. if a user wants to install a java application through apt-get and he has no JVM deb installed, apt will give him a choice (can apt ask user how to resolve dependency conflict, or is it always automatic?) as to which JVM he wants to use. Going out of one's way to support software that one can not legally support is as b0rked as suggesting that Debian should support MS .net runtime through Wine as the default C# environment instead of Mono/pnet. Sun does not support Java on Debian. The JDK is *not certified* on Debian, ie. it is *not* guaranteed to be compatible with the JDK on, say, Windows or anything else. Sun does not care about Debian, they care about Red Hat SUSE, Solaris Windows, according to their download page, as that's what they certify. Check out last year's archives from September/October for a detailed discussion of similar proposals between Jan Schulz and others and why they are broken. I will have a look, sounds interesting. but it does not help java portability. Of course it does. Without gcj you couldn't run Java code on a few dozens of platforms. Sun's 'anywhere' barely covers a handful of platforms. Kaffe, for example, has been ported to more than 70 platforms, including playstation2, arm-riscos or linux-sh, for example. Kaffe has been actively helping the portability of java code since 1996. I know everyone here are open source advocates, but face it: 1. good programs sometimes comes without the source. If they prove to be good enough, then someone comes up and writes better programs as free software. Happened with Unix. Happened with C. Happened with C++. Happens with Java right now. You too can be a part of it, you don't have to put yourself in a position where you depend on Sun and their choice of licensing. 2. not all users are interesting in compiling the programs they run, it scares the shit out of some users. As long as it happens as part of your normal apt-get routine, as it happens with, say, emacs lisp programs, I don't see why it could be a problem. Does apt-getting emacs scare the shit out of you? ;) Java is portable, JVM's are not. Well-written VMs are portable, and are getting ported widely. For a nicely portable VM, I'd suggest checking out SableVM, Kaffe, JamVM, or even JikesRVM, which is written almost entirely in Java, and has a great scientific community behind it. cheers, dalibor topic
Re: GPL related question
Rishabh Manocha rmanocha at cs.utexas.edu writes: if it is allright to take GPL'ed code, edit it and use it in your own application?? Read the FAQ: http://www.gnu.org/licenses/gpl-faq.html If you copy GPLd code into your application (or link to it) then you must license your whole application under the GPL. cheers, dalibor topic
Re: RFH: how to really assemble java packages
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. cheers, dalibor topic [1] http://tjmail.sourceforge.net/
Re: RFH: how to really assemble java packages
Thanks for presentig the case to upstream. I hope they will follow your suggestions. cheers, dalibor topic
Re: Sun's JVM in non-free
Ricky Clarkson ricky.clarkson at gmail.com writes: I think the JRE is a bit more lenient, but I hardly ever use just a JRE, so I don't read the licence for that very often. from http://java.sun.com/j2se/1.4.2/j2re-1_4_2_05-license.txt B.License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs, the 'unmodified' bit would prohibit distribution of debian packages that fix the shell scripts for debian, for example (unless some README says so). [snip] (iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file), conflicts with, for example, distributing free runtimes, compilers or jar tools, as far as I can tell from it. [snip] (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, That's essentially a joker to sue at will if Sun feels endangered in their interest. Someone replaces JDS with Debian? Sue 'em for not protecting Sun's interest :) and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. Unless someone wants to foot Sun's bill for anyone Sun's legal department decides to sue, that casually happens to have installed j2re from non-free via apt, that's not an option, I guess. On a side note, all the references to 'applicable README' are really unhelpful to understand the precise licensing terms. It means that you can't see everything that you are agreeing to in the click-wrap license. So if some intern at Sun sneaks in 'and if you are using Debian, you agree to pay Sun a $699 license fee' into some 'applicable' README, that you can not read when you accept the license, you're bound to have some fun in court. Non-free licenses are there to screw you. Avoid them. IANAL, and all that. cheers, dalibor topic
Re: RFH: how to really assemble java packages
Daniel Bonniot Daniel.Bonniot at inria.fr writes: Is there any chance to have a non-Sun implementation of com.sun.*? Pretty much zero. For two reasons: a) legal. Since it's unspecified undocumented, it'd be very hard to write without going to the source. As SCSL is evil, I don't think anyone would want that. b) practical. As it's undocumented and unspecified, Sun is free to change it any time. They do shuffle their sun.* classes around a bit with each release, afaik, so code that uses them works by pure accident anyway. That limits the usefulness of a sun.* implementation, as you'd be stuck supporting all sorts of incompatible variants of an unsupported API. Doesn't sound like a good plan to me. :) In my experience, it's more productive to submit a bug report to upstream to write to documented APIs instead, and propose a few alternatives[1]. That way, everyone ends up being better off in the long run: the code eventually works in a predictable fashion, so upstream is happy, and it works on free runtimes, so debian users are happy. cheers, dalibor topic [1] Or even volunteer to do it, if the code really matters to you. :)
Re: [kaffe] kaffe/jikes makes incompatible code for jdk1.3?
Arnaud Vandyck wrote: Mark Wielaard [EMAIL PROTECTED] writes: 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). I did -target 1.3 ... and serlvet api is still in main, sorry for the whistle ;-) No problem ;) cheers, dalibor topic
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)
Arnaud Vandyck wrote: Hi everybody, I built javax.servlet with kaffe/jikes/ant1.6, but when running with jre1.3, it seems there is a problem... log is attached. Thanks to help. 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! 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? Salut Arnaud, Sorry for not being able to respond sooner. The problem is in the class versions. Depending on which version of jikes you use, it generates class files for different target vms by default. More recent versions of jikes target more recent versions of JDK. The same thing could happen if you had used JDK 1.4 to build the classes. Since Sun changed[1] the byte code format with every major JDK relese (and ocassionally in-between releases), you need to tell Jikes explicitely which is the lowest JDK version you want to target. If you are using ant, you can do that by setting the target attribute of the javac task to the runtime version you ant to target. Caveat: If the code uses APIs or language features from a different version of Java and JDK, then compiling to an earlier byte code format would not solve the problem. But if libservlet is supposed to work with JDK 1.3, then changing the build.xml file to target 1.3 by default and filing a bug upstream should be a quick solution. cheers, dalibor topic [1] And didn't document the changes, of course. :)
Re: [kaffe] kaffe/jikes makes incompatible code for jdk1.3?
Mark Wielaard wrote: Hi, On Wed, 2004-08-04 at 23:48, Arnaud Vandyck wrote: 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 tend to agree with Mark on that. If it's a problem with some code outside debian (i.e. the JDK), then it shouldn't be necessary to kick packages out of main to acommodate for problems in non-free software :) But then, I tend to view the JDK like the Netscape Navigator: it was great that it was around, but after a while it was less and less needed, since free software alternatives made it unnecessary for free operating systems. :) cheers, dalibor topic
New mailing list for discussion of common java packaging
Hi all, Thanks to Guillaume Rousse fron JPackage project, we've got a mailing list for our common java packaging discussion set up on https://www.zarb.org/mailman/listinfo/cojapas . The idea behind it is to add a discussion forum to the Common Java Packaging wiki on http://java.debian.net/index.php/CommonJavaPackaging . I hope it will be more convenient for everyone involved in this effort, and that it will let us progress at a faster pace than the wiki alone could. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which libre alternatives to javamail, java activation framework, jwsdp exist? [long]
Hi Karl, Karl Trygve Kalleberg wrote: Thus, as I see it (IANAL, TINSTAAFL, TTFN, etc) we (the Gentoo project, but I suspect this will hold for at least Debian as well) are not able to redistribute these products as currently licensed. Does anbody know of suitable replacements? So far, I have found: ) GNU javamail - replaces Sun javamail ) GNU JAF - replaces SUN JAF (both are part of GNU classpathx) ) JWSDP consists of # JavaServer Faces (JSF) http://www.marinschek.com/myfaces/tiki/tiki-index.php (LGPL) # XML and Web Services Security Oh, I first thought that was about SPKI/SDSI, for which a free software implementation exists: http://jsdsi.sourceforge.net/index.html But that seems to be basically about using https with JAX-RPC. And for that you can use Apache Axis: http://ws.apache.org/axis/ or possible Apache XML-RPC: http://ws.apache.org/xmlrpc/ # Java Architecture for XML Binding (JAXB) JaxME from Apache: http://ws.apache.org/jaxme/ # Java API for XML Processing (JAXP) - GNU JAXP # Java API for XML Registries (JAXR) I think the Apache JUDDI project will include some JAXR implementation. http://ws.apache.org/juddi/ . But there is also http://ebxmlrr.sourceforge.net/ which seems to include some jaxr implementation according to google. # Java API for XML-based RPC (JAX-RPC) Axis :) # SOAP with Attachements API for Java (SAAJ) I think http://www.amberarcher.org/ should have it. Axis possibly too. # JavaServer Pages Standard Tag Library (JSTL) http://jakarta.apache.org/taglibs/ # Java WSDP Registry Server # WS-I Supply Chain Management Sample Application I don;t have time to google something up right now :( cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SwingWT
Hi Robin, Robin Rawson-Tetley wrote: On Fri, Mar 26, 2004 at 09:52:37PM +0100, Dalibor Topic wrote: For Kaffe, you should be able to just grep | sed s/swingwt\.awt/java.awt over the SwingWT sources (much more reliable than mastercl and without any overhead translating classloader calls). You might have to remove the AWT/Swing stuff from classpath - unless Kaffe supports -bootclasspath (which I'm too lazy to look up right now). It supports BOOTCLASSPATH, i.e. setting it via environment variables. :) But I'll add a real -bootclasspath option soon, as I'm rewriting argument parsing to use GNU AutoGen, and need it for merging in GNU Classpath's AWT and the various AWT implementations from PocketLinux. SwingWT CVS seems to work well with Kaffe from CVS, according to http://www.kaffe.org/pipermail/kaffe/2004-March/045747.html, so I'll be interested in trying to merge in SwingWT into kaffe eventually, as another Swing/AWT alternative, beside Kaffe's own Xlib and Qt-based ones, and the forthcoming GNU Classpath gtk based one, as well as the 10+ implementations from Pocketlinux Kaffe port and mighty cool Odonata[1] from Stephane Meslin-Weber. Cheers (and keep up the great work with Kaffe!), Thanks for the praise, and thanks for making Swing over SWT possible, something I always thought was impossible until I discovered your outstanding work. I'm glad I was wrong :) cheers, dalibor topic [1] http://fbawt.adorphuye.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [JPackage-admin] maven-1.0-0.rc1.jpp ready
Salut Nicolas, Nicolas Mailhot wrote: Le mar, 30/03/2004 05:02 -0500, David Walluck a crit : Ralph Apel wrote: What about a maven section, for maven itself and mavenized packages? I thought we would not bother mantaining a maven repository and instead replace it with rpm resolution (for now this can even be done with System.exec()). I think this would be less work than constantly maintaining a maven repository, but it's up for debate. I'd rather we focus on the general java framework the Debian wiki is about, and teach maven packages to use whatever resolution mechanism we agree on later. Of course this will be less painful if someone with deep maven knowledge (ie not me) checks the competing proposals for maven compatibility now. Short-term maven packages will remain the oddball they are now. My impression from trying to talk about software management (i.e. package management, something different from software distribution alone) with Maven developers was that they don't care, maven works for them, and that was pretty much the end of it. They had a lot of trouble understanding why people would want to build from source, mantain distribution-specific changes, or avoid grabbing stuff from some unsigned binary only repository off some webpage somewhere. My explanation is that in the Windows world, Maven beats anything people have ever seen in terms of software distribution. So when you try to tell them that there are better ways to do such things, and they have been used on Linux for a while, you get shouted at because you're threatening the new hype/consulting revenue model :) Some people had a hard time grasping that neither the 'source-only' nor 'binary-only' approach fits everyone. Software distribution systems on Linux usually evolved to support both, because there are mighty good reasons to do so. Thus, I would not expect that much support from the core Maven community, unless they have managed to wrap their minds around providing sources for the binaries as well, for example. I think that they have a few years to go, till they reinvent apt-get/urpmi/fink/emerge for Java in Maven 2.0. :) OTOH, some people told me that writing Maven plugins was rather easy, so I assume it would be possible to hook up Maven somehow to work with native packaging systems, instead of working around them. In order for that to happen, though, we need to work something stable out for the 'Common Java Packaging' effort, as Nicolas says. I'm glad there is some progress on the descriptor front, btw. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian package for sun's j2sdk
Pierre Machard wrote: Hi, On Tue, Mar 16, 2004 at 10:57:30PM +0100, Heretik wrote: Hi I've just read the Debian GNU/Linux Java FAQ and i installed sun's j2sdk on my debian unstable with a lot of difficulties. I've read in the FAQ that a debian installer for sun's jdk1.4 is to be made so i'd like to help doing it. As i often install debian on some friend's computers, i need a simple way to install a single debian package for full java toolkit. So if i can help doing this, please tell me how i could start. Matthias Klose already packaged the jdk1.4 from blackdown: http://swt.cs.tu-berlin.de/~doko/tmp/ http://swt.cs.tu-berlin.de/~doko/tmp/j2re1.4_1.4.1.01-1.1_i386.deb http://swt.cs.tu-berlin.de/~doko/tmp/j2sdk1.4_1.4.1.01-1.1_i386.deb No need to reinvent the wheel. If that's the original JDK he *may* be violating the license, since it only allows distribution under specific conditions and *unmodified*. Splitting the original download into a few debian packages can be seen as creating a derived work, i.e. modification of the original work. In that case, downloading it from him *may* give you no license to use it, since Sun's license is non-transferable. [1] IANAL, and all that. cheers, dalibor topic [1] http://java.sun.com/j2se/1.4.2/j2sdk-1_4_2_04-license.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian package for sun's j2sdk
Hallo Juergen, Juergen Kreileder wrote: Dalibor Topic [EMAIL PROTECTED] writes: Pierre Machard wrote: Hi, On Tue, Mar 16, 2004 at 10:57:30PM +0100, Heretik wrote: I've just read the Debian GNU/Linux Java FAQ and i installed sun's j2sdk on my debian unstable with a lot of difficulties. I've read in the FAQ that a debian installer for sun's jdk1.4 is to be made so i'd like to help doing it. As i often install debian on some friend's computers, i need a simple way to install a single debian package for full java toolkit. So if i can help doing this, please tell me how i could start. Matthias Klose already packaged the jdk1.4 from blackdown: http://swt.cs.tu-berlin.de/~doko/tmp/ http://swt.cs.tu-berlin.de/~doko/tmp/j2re1.4_1.4.1.01-1.1_i386.deb http://swt.cs.tu-berlin.de/~doko/tmp/j2sdk1.4_1.4.1.01-1.1_i386.deb No need to reinvent the wheel. If that's the original JDK No, it's the Blackdown J2SE he *may* be violating the license, since it only allows distribution under specific conditions and *unmodified*. Splitting the original download into a few debian packages can be seen as creating a derived work, i.e. modification of the original work. and *these* debs are OK. Thanks for setting that straight. Would it be possible to host them on blackdown mirrors as well? All that's available on ftp://ftp.tux.org/pub/java/debian/pool/non-free/j/j2se1.4-i386/ for example, are a few betas, but no final release. That would also remove any kind of licensing confusion. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Has anyone looked at swingswt?
Hi Jerry, Jerry Haltom wrote: Changing the hard coded package names would mean one could no longer use the program with a non-free Swing implementation such as Sun's. This sounds like a non-starter to me. If SwingSWT were to be repackaged to java.awt and java.swing, this would be possible. Is that possible??? Might warrent talking with the upstream authors. See http://swingwt.sourceforge.net/faq.php and http://chrriis.brainlex.com/projects/mastercl/ I haven't played with it, but I'd like to know if and how well it work with Kaffe, for example. My ultimate dream-demo being running NetBeans over SwingWT over MasterCL over Kaffe :) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Signal 11 running Eclipse
Aurélien Labrosse wrote: Hi, I have some trouble using Eclipse, on a Debian Sid. Software versions: j2sdk : 1.4.1-6 (Blackdown) eclipse: 2.1.2-1 kaffe: 1.1.4-2 * Using blackdown jvm : [EMAIL PROTECTED]:~$ eclipse Including user settings ~/.eclipse/eclipserc... Using /home/aurelien/eclipse as default workspace... Using JAVA_HOME and /usr/lib/j2se/1.4//bin/java as java virtual machine... An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x400F2F79 Function=__libc_free+0x49 Library=/lib/libc.so.6 * Using Kaffe: [EMAIL PROTECTED]:~$ eclipse Including user settings ~/.eclipse/eclipserc... Using /home/aurelien/eclipse as default workspace... Using JAVA_HOME and /usr/lib/kaffe//bin/java as java virtual machine... WARNING Bad bytecode! Illegal exception table entry: start_pc=139980500 is not lower than end_pc=139980500 in method org/eclipse/core/internal/resources/Workspace.getResourceInfo((Lorg/eclipse/core/runtime/IPath;ZZ)Lorg/eclipse/core/internal/resources/ResourceInfo;) See Java Virtual Machine Specification 2nd Edition $4.7.3 for details. Please report this bug to the developers of the application you're running on kaffe. A simple fix might be to use another java compiler to build the application. you mean it works better on kaffe than on blackdown? then we're surely making some progress ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java in main for ofbiz
Arnaud Vandyck wrote: Adam Heath [EMAIL PROTECTED] writes: These are the jars I need to have packaged still. Slightly smaller list, as I found some replacements in debian already. Re-ordered: 1° Maybe already in Debian: components/content/lib/iText.jar libitext-java - Java Library to generate PDF on the Fly works on kaffe components/minerva/lib/jdbc2_0-stdext.jar components/minerva/lib/jta_1.0.1.jar I think they are in kaffe and classpath (and in j2sdk) yes, I don't know how well they work, though. components/entity/lib/jdbc/hsqldb.jar works on kaffe I don't know about the rest from the top of my head. I'm checking in some RMI improvements now, and then we'll give JBoss a beating. The developement in the last few days has been quite intensive wrt to getting XScale, PowerPC-no-fpu, and MIPS to run again, with patches flowing in at very high rate. Regarding Kaffe: I plan to merge in gjdoc + libxmlj, since we need a working free javadoc replacement, and then merge in an ORB (probably JacORB) so that running those enterprise applciations that need corba actually starts working on free runtimes. If the things continue at this pace, we may consider doing kaffe-cvs releases more regularly for interested people to play with. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: good day for kaffe 1.1.4 and ofbiz 2.1
Hi Adam, Adam Heath wrote: kaffe 1.1.4 can now run ofbiz 2.1. I haven't tried a later version of ofbiz. Thanks for the great news! Could you add the information on how to get it to run to the Moving Java to Main wiki on http://java.debian.net ? There are some issues, however. Startup time under sun 1.4 is 11s. kaffe, 15.2. You could try running kaffe with -prof to see where it spends its time in the class library. There may be some hot spots that could be implemented better. Kaffe complains about an invalid bytecode at startup, while sun doesn't. WARNING Bad bytecode! Illegal exception table entry: start_pc=140851621 is not lower than end_pc=140851621 in method org/mortbay/util/Resource.newResource((Ljava/net/URL;)Lorg/mortbay/util/Resource;) See Java Virtual Machine Specification 2nd Edition $4.7.3 for details. Please report this bug to the developers of the application you're running on kaffe. A simple fix might be to use another java compiler to build the application. That's a bug in Sun's VM and the compiler used to generate the JAR file. The virtual machine spec says that the start PC of an exception table entry must be lower than the end PC. Sun's VM seems to ignore such bad bytecode. In order to stop people from filinf bug reports against Kaffe for not being able to run broken bytecode, we ignore it too, but nevertheless print a warning message so that the bug can be fixed by the upstream developers by picking a better compiler. Also, shutdown hooks in kaffe are not run. OK, that's bad. Do you have a small (5-10 lines) test case? Attached you will find the entity engine performance test, which is available under webtools. Seems that kaffe is slower than JDK at the tests. That's something that can be fixed though, given enough interested developers ;) For example, kaffe's jitter is rather simplistic, and could generate better machine code given some effort. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Co-maintaining Kaffe
. Drop me a line if you have interest or success stories. And they can also hop on our mailing list on [EMAIL PROTECTED], and on the IRC channel #kaffe on irc.freenode.org for some hands-on introduction to the code base. Fixing the compiler warnings should be an easy excercise to get you started. cheers, dalibor topic [1] I'm not a debian developer. I work closely with some of them, though. I'm also one of the people behinds a few efforts to make packaging java applications in debian easier, and to foster cooperation with other packaging efforts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report from the Debian Java developers meeting at FOSDEM
Hi all, Stefan Gybas wrote: Arnaud and Dalibor gave a talk about packaging Java software which covered JPackage (http://www.jpackage.org/), Gentoo, FreeBSD and of course Debian. One goal of this talk was to improve collaboration between these projects and Red Hat's effort to package Java software which is compiled to native code using gcj (http://gcc.gnu.org/java/). I talked to Gentoo-java developers on IRC later, and had the feeling they were quite interested in more collaboration. Maybe we can catch up for the RMLL this year and start devising plans to take over the world :) larger applications work. So the Wiki page at http://java.debian.net/index.php/MovingJavaToMain which was started by Arnaud is also useful to them. In the future, the Debian Java maintainers will try even harder to make their packages work with free JVMs and send their results to them. I've discussed that with Jim, and I think I'll start adding the instructions how to run applications with Kaffe to that wiki, to make the life of our packagers a little easier. Main discussions with Java developers Besides the issue of better collaboration we also had a lot of technical discussions: - The proposed new Debian Java Policy by Jan Schulz That's got time till the next debian release is out, I guess. There were also a lot of other discussions which are more or less relevant for Debian. For example, Chris Halls and Rene Engelhard talked to Dalibor about ways to build the Debian Openoffice.org packages with Java support. Hey, we've actually got a mailing list now ;) And I've made some commitments to clean up some code to start things off. Next steps We'll try to get more Java packages from contrib to main. gjdoc will be a major step for this since this would allow us to build Javadoc API documenation for library packages in main. We will also try to set up some testing environments for building Java packages with Kaffe and SableVM so we don't have to manually try each new upstream version. Yeah! 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. For kaffe, I'd say hours. I'd start with cleaning up all the compiler warnings shown in the buildd logs, though. Volunteers are invited to come to #kaffe on irc.freenode.org if they want to lend a hand to kaffe. But you might as well help out Grzegorz on SableVM, which seems to be much less work to port and fix. I believe that SableVM could always use another good developer and tester, as well, just like gcj/gij and other GNU Classpath based free runtimes would welcome new users and developers. Feel free to join in, if you're interested. We're all a noisy bunch, ocassionally slapping each other silly with licensing questions, but pulling free java in the same direction[1] nevertheless. cheers, dalibor topic [1] Ahead, of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report from the Debian Java developers meeting at FOSDEM
in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library. FSF is free to license their code as they see fit. If you want truly freely usable software, you should put it in public domain. I, for one, am quite happy with the compromises on liberty made by the GPL. PS: As Jim Pick explained at FOSDEM - Kaffe has been GPLed exactly for this purpose: to prevent its usage with GPL-incompatible software. I don't think anything changed in GPL interpretation since then. Sure it did. Transvirtual and the Kaffe core developer team publicly stated in their FAQ on the old kaffe.org website that they consider running commercial applications on kaffe to be ok. I've posted the link to archive.org last time we had this discussion [2]. I can do it again, it it makes you feel better. Given that Transvirtual and the Kaffe core developer team were the only/major copyright holders on the Kaffe source code, I think their opinion weighs more than FSFs. And given that such a permission has been granted by the copyright holders, it'd be rude to pretend that hasn't happened. While the Kaffe copyright holders could change their mind, FSF can not be so flexible. So the FSF has to stay with the interpretation they worked out with Transvirtual initially, when Transvirtual thought they could make a business selling java runtimes. After a while Transvirtual realized that the business case was not as solid as they thought, apparently, and changed their mind, as far as I can tell from the website archive. It's no different than Linux Torvalds saying binary modules are OK, in my opinion. As a copyright holder, he's free to interpret the GPL in his own way. Just like you and the FSF are free to disagree. But remember that only copyright owners can sue for copyright violations. Anyway, SableVM is a very cool virtual machine. It's as good a choice as any other Classpath using virtual machine, maybe even better, depending on your needs. I'm glad to hear it's progressing so nicely. Keep up the good work! cheers, dalibor topic [1] My assumption is that as a new stable SableVM release comes out, and the initial excitement is over, SableVM developers try to force me into yet another licensing discussion in order to fish for users/developers. Or maybe because they are bored, I can't tell. SableVM 1.1.0 came out last week, and promptly Etienne attacked Kaffe on debian-java, followed by Grzegorz's attacks yesterday. The Kaffe licensing attacks from last year in October/November seem to have been preceeded by a set of SableVM 1.0.9 test releases. Note that I said *assumption*. Feel free to make your own judgements. [2] And the time before that, I believe. And I guess the time before that as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: eight packages could possibly go to main!
Salut Daniel, Etienne, Daniel Bonniot wrote: I was asking you a yes or no question about what you meant in your message: you agree the GPL would only apply to programs that can run only with Kaffe, and cannot run with, say, Sun's JVM? Looking at the message you linked to, I would assume yes, based on: A given java program does not require this class library in order to function, because it will also work with a range of other class libraries from different vendors, and therefore is not a derivative work. Therefore, the GPL does not cross this so-called interface boundary to which you agreed, stressing the range ... vendors. The other question might rather be to Dalibor: do you know of any program that falls into that category? I'm not aware of any programs in Java that require kaffe's class library in order to function, and won't function with other (possibly non-free) class libraries. Following from that, I'm not aware of such programs that are not licensed under the GPL. The biggest problem is that Kaffe is licensed under the GNU GPL, so if an application/library can only be compiled with Kaffe, it must be licensed under the GPL too (or at least be license compatible with the GPL). It's an interesting question whether compilation with a GPL'd program causes the output to be GPLd. I don't see an FAQ entry on the FSF page for that, so I'd propose to take the discussion to debian-legal, if necessary. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tomcat4 and Kaffe - partial success story
Hi Kalle, Kalle Kivimaa wrote: I've been running Tomcat4 on top of Kaffe in my testing/unstable server for a few weeks now. It works fine for a few days and then it simply stops responding (connections to the HTTP connector close immediately). A restart will always help. Has anybody else had this problem and/or ideas on what is going on? Sounds interesting, like some sort of leekage of ressources would happen. Do the tomcat logs provide any clue (like runtime exceptions)? cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
