Re: Policy change proposal - JVMs Provides: requirements
--- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz > B. Prokopski wrote: > > I don't know what 99% or what 80% is. Fact is that > aside of Kaffe, > > the other free JVMs use indirectly (like gcj) or > directly one single > > source of it's classpath lisbrary - GNU Classpath. > I really doubt if this > > project has reached 80% of what java 1.2 > (especially in the area of > > graphical interfaces) should be. I think that *I* > would use GNU > > Classpath as the 100% here (then we can have JVMs > that support more > > than 100% ;-). But I don't really expect you to > write it down to > > the policy. > > Hmm. It it that bad. I was not aware of that > actually. In some way > we have to define java1-runtime in a good way. > Define it against > a moving target (like classpath) might not be a good > thing. On the > other hand it might be the best way... Well, seems like you guys are looking for some numbers ;) Check the japitools JDK API compatibility pages at http://rainbow.netreach.net/~sballard/japi/ > > As for my proposals, I think I'd do it this way: > > 1. Define exactly what requirements must be met > for JVM to be able > > to _legally_ provide java-virtual-machine, > java*-runtime etc. > > Then we can agree on that. The problem is to define > it... :( I don't understand the term 'legally' in this context. What legal requirements are there? best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal - JVMs Provides: requirements
Hi Grzegorz, --- "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> wrote: > > ;) Check the japitools JDK API compatibility pages > at > > http://rainbow.netreach.net/~sballard/japi/ > Thanks for the link. However in this case the APIs > are compared, > not if they really work. There's a lot of stubs in > GNU Classpath, > so I doubt if this comparison method is sutiable for > our purpose. > Every JVM that uses GNU Classpath would get same > results. It's > comparison of classpaths not JVMs. I'd say there are three states an implementation of functionality from an API goes through: 1) not there 2) there and defect 3) there and perfect The stubs in classpath count for me as 2). They let you compile programs against the stubs, after all, and thus are definitely more useable than 1). I think this was one of the reasons the OpenOffice guys went ahead with Classpath and not kaffe's class library for their debian build work. Classpath has at least free software stubs for swing, while kaffe has none, but works well with sun's implementation. Using kaffe + sun's non-free swing would have kicked OpenOffice out of 'debian-free', if I understand the debian policies right. In my opinion, stubs that haven't been filled yet, should be treated as bugs, and incite people to provide their own implementations. Actually, you need to take into account that semantics of some methods have changed between different versions of the API. So you may get runtime incompatibilities no matter what you decide on java*-provides. I think the matter is no different than when deciding whether gcc is a good enough C/C++ compiler. It may not support all of C99, it may still lack some C++ features, it may even have some bugs, but in a lot of situations, it's a very useful tool. But there must have once been a time when gcc was not very useful for compiling most C & C++ programs ;) Talking of whether things really work should be done within the context of the mauve test suite, in my opinion. It would be a great service to the free java community if someone could set up a site similar to the Japitools page, that would pull the latest CVS source for gcj, kaffe, sablevm, wonka, kissme, etc., build them, and run them against the latest mauve from CVS, and publish the results. Give people some graphs, to track progress, too ;) There is a perl script in the japhar CVS that can convert the output from mauve into html. Unfortunately, I can't do it. Most importantly because I'm a regular kaffe developer. I'd prefer to see someone more "vendor-independant" than me do it to avoid any bias. Plus the usual lack of time; I'm busy enough fixing bugs in kaffe ;) best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hi Ola, --- Ola Lundqvist <[EMAIL PROTECTED]> wrote: > Well then we have to have an alternative approach to > this. > > javaX-core-classes (I assume that there are > differences between versions there) > javaX?-awt > javaX?-swing > > Then java1-runtime depends on java1-core-classes, > java1-awt and java1-swing > > Is that a better proposal. I'll make that package if > it is accepted. Only so far that Swing never officially was part of JDK 1.1, but there was a swing implementation for JDK 1.1 that could be downloaded as an extension. For extra fun, I assume it was slightly different from the Swing shipped with Java 1.2.0, as it was labelled swing-1.1.1 FCS. I think trying to formalize what features free VMs support by breaking the feature set into smaller bits and pieces is a sure way to end up having javax-with-reflection-but-without-the-necessary-security-checks and similar tags to label deficiences of particular implementations instead of fixing them. Blindly assuming that an application will work on one free VM because it works on another is, at the current state of things, also dangerous. If I may make a proposal, as someone who's just a lurker here, I'd say remove the 'provides javax-runtime' tag from the free VM releases that obviously lack the functionality of the tagged JDK release, according to japitools. But only allow Java programs to get into 'debain free' if they explicitely name in their requirements a free VM as the default choice and the maintainer has gone through the work of testing it, and getting it to run with either kaffe, gcj, sablevm, or some other free VM included in 'debian-free'. This approach provides two benefits: on one hand, the free VMs get more testing and bug fixing work, then they would otherwise. On the other hand, having a debian maintainer state that his package works with a free VM is a badge of honor for both the free VM and the maintainer. Given that the VM developers usually can't test everything all the time, it would provide additional insurance to the users that the free VMs they got on their debian systems actually work for something ;) The downsides are probably many. As I said, I am not a debian developer, so I don't know if putting this additional burden of work on the maintainers is a good idea or not, if it's in line with other debian policies, etc. best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hi Ben, --- Ben Burton <[EMAIL PROTECTED]> wrote: > I see java-runtime as a similar situation. I take a > simple Java app > that will run on any JVM that is reasonably > complete, and I want to just > have Depends: java1-runtime, allowing the user to > download whatever JVM > they see fit. I don't want to have to keep track of > the multitude of > JVMs available in debian and keep the Depends: line > updated as they all > shift and change. I'd like to point out that I wasn't advocating that the debian maintainer tracks all VMs available for debian all the time. Just that she specifies a (i.e. at least one ;) free VM that the application works with in order to be in 'debian-free'. You'll also note that I used 'either' when I wrote about getting a Java application to run with a free VM for inclusion in 'debian-free'. ;) In practice, I'd assume that a debian Java app maintainer picks one VM, and tests the app with it prior to uploading. My idea is to have the maintainer say, "it works with this free VM, YMMV with others" in order to get into 'debian-free'. I am not a debian maintainer, just a casual user, so my ideas should be treated with a big grain of salt. Choose what works best for debian and maintainers like yourself. cheers, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
Hi Ben, --- Ben Burton <[EMAIL PROTECTED]> wrote: > > > I'd like to point out that I wasn't advocating > that > > the debian maintainer tracks all VMs available > for > > debian all the time. Just that she specifies a > (i.e. > > at least one ;) free VM that the application works > > with in order to be in 'debian-free'. > > Mm.. what worries me about this is that if I (say) > choose Kaffe as my > working JVM and my package has Depends: kaffe, then > all other users are > forced to install kaffe even if my package happens > to work on most or > all other JVMs. > > Perhaps Depends: kaffe | java1-runtime to show the > user that I know it > works on kaffe but to allow a user to install some > other JVM instead? That seems logical to me: if you know that your app works on gcj, kaffe and sablevm, then you'd specify them explicitely, for the unknown rest you'd use javaX-runtime, cross your fingers and wait for the bug reports. How many bug reports you get will from users of not-explicitely specified VMs depends on how liberal the maintainers of these VMs handle javaX-runtime, and that's probably out of your control. And of course, if users of a not-explicitely-specified VM contacted you telling that it all works great, you could add them to the "officially endorsed" mix. But I guess that's where that debian java policy thing comes in ;) The drawback is that it all makes your dependencies larger, and probably kills most of the benefits provided by having a purely virtual javax-runtime. On the other hand, given that the state of things is as it is, I think it's a good compromise between locking down users to a single VM that works out of the box, and implementing all the missing functionality in all the free VMs out there ;) I assume (i.e. I don't know, and I don't feel like digging through years of debian-java archives) that prior to having a unified javax-runtime, debian has used a system like that. Why was it changed? Did the expected benefits materialize? cheers, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library problem with gnome|gtk-java?
--- Juergen Kreileder <[EMAIL PROTECTED]> wrote: > Arnaud Vandyck <[EMAIL PROTECTED]> writes: > > > What about a port of 1.4.x for powerpc? > > There are some people working on porting HotSpot to PPC. Do you want > to help? Unfortunately, working with Sun's code means you can't contribute to clean room efforts any more, so I one has to pick sides: help Blackdown with Sun's code, or help clean-room efforts to write powerpc jits [1] ;) [1] Kaffe-based JanosVM 1.0 has the beginning of a powerpc jitter. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kaffe-1.1.1 package available for tests
Salut Arnaud, thanks for making an updated package for kaffe. Did you manage to get in touch with Ean? --- Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Thenewupstreamreleasecloses #196867(Kaffe1.1.0 > available). According to Dalibor Topic (in the same bug report), the new > upstream release will close these bugs: > > #51230 No exception raised when an external program is not found > #61264 config.* in the libungif dir are too old for ARM port > #75800 config.sub outdated > #77869 Upstream changelog and other docs missing > #116802 portability problem in kaffe/kaffevm/debug.h > #141597 FTBFS: tries to include non-existant headerfile on mips(el) > #158743 Math.round is broken > #170021 does not handle -classpath in a good way. > #170059 jar uf doesn't work for me > #193263 FTBFS: syntax errors A few more are closed, actually: #196254, #197617, #202779 (the jitter works again, though it would need some alpha developer to look over some of the regression test failures), #81389 (in 1.1.1, if no gnu gmp is found, kaffe switches over to use a pure java implementation of java.math), #200434 A few *may* be closed: #82555 talks about classes.zip from Sun, I assume. Kaffe has been using it's own java class library implementation for a while now. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kaffe-1.1.1 package available for tests
--- Ben Burton <[EMAIL PROTECTED]> wrote: > I understand the problem, and the reasons you cite are reasons for > wanting to NMU in the first place, not for doing a highly irregular new > upstream NMU right now. For such a significant change I'd allow Ean > ample time to respond (and perhaps this response will be "yes please, go > ahead"). Recall that NMUs are generally used to fix bugs whilst > minimising unrelated changes. Presumably this is because with a large > software package like kaffe, there may be all sorts of subtleties with > packaging, upgrade paths, etc. that the maintainer is familiar with but > an NMUer might not know about. Bug-fix-only NMUs generally do not fall > prey to such problems. New upstream release NMUs do. Being a kaffe developer, I'd recommed that the NMU includes Ben's fix for the /usr/lib/jni lookup thing. We won't fix that in kaffe, as it's debian specific. Other than that, I believe that all other rc bugs are fixed in 1.1.1 > > Wouldn't it be more efficient to focus on making ant go into main? > > Assuming that needs fixing free JVMs and/or writing library code, it > > would be work useful to other projects, instead of duplicating work to > > work-around the issue. > > Say I maintain package foo. My options are: > > (i) Read through the ant XML file for building foo (a package whose > sources I'm quite familiar with), work out what needs to be done and > write a few makefiles; > > (ii) Dive into the source code for ant itself (which I'm completely > unfamiliar with), rewrite portions of this source code to eliminate the > need for packages outside main, submit patches and then wait for the > ant maintainer to verify and apply them. > > Sure, (ii) is nice in the long run since it helps everybody. But if I > don't have a lot of time then option (i) is more efficient for me, gives > faster results and is more likely to be done correctly. the trouble is that you, and everybody else does (i) over and over again whenever a package is released that needs ant to build itself. in the long run, (ii) is the rational choice. while (i) may seem to be more efficient, it's just a distributed waste of time ;) if you want to do a massive distributed waste of time project, i believe that time would be better spent persuading the FSF and ASF to get together on their licenses and make either the GPL ASL compatible or the other way round. who kknows, maybe you won't waste the time and they get their ideals/egos out of the way and work out a compromise. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kaffe-1.1.1 package available for tests
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote: > > >But ... the FSF doesn't think that code licensed under a GPL incompatible > >license can be allowed to run on a GPLd VM (i.e. kaffe). > > > Could you give a link that details this point? read the threads: http://lists.debian.org/debian-legal/2002/debian-legal-200208/msg00055.html http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL http://www.mail-archive.com/[EMAIL PROTECTED]/msg02268.html it's been done over and over before. instead of relicensing kaffe, i think the solution that benefits the community most is to get ASF and FSF to agree on mutually compatible licenses. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kaffe-1.1.1 package available for tests
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote: > >The gij interpreter is quite advanced and for me works better than kaffe > >in almost all cases where I've done a comparison. There is no reason > >(in most cases) that an out-of-date kaffe should be a bottleneck for > >packages progressing into main. > > > In my experience kaffe worked better than gij. I might highly depend on > the type of program you are running. Maybe I should also try again with gij. depends on the program, usually. in some areas kaffe's better, in others it's gcj. We're slowly converting kaffe to use classpath where their code is better, so being a kaffe developer, I hope that kaffe comes out on top ;) But seriously speaking, we're converging to a common ground (GNU Classpath) in class libraries, allowing different java vm implementations to differentiate from each other on other terms than just 'it can run my code'. I hope that GNU Classpath will be able to run just about anything thrown at it in a year or two. Mark Wielaard is leading a very energetic bunch of developers, and the kaffe guys will be slowly joining in the fun as well. > In any case, kaffe 1.1.0 is much better than 1.0.7, so it would be great > to have it in Debian. > > >Incidentally, several java packages could move from contrib into main if > >the maintainers could simply take the time to write their own Makefiles > >instead of relying on the default ant build system which is in contrib, > >e.g., #163168. It's a bit of work but it's certainly possible - see > >jython for an example. > > > Wouldn't it be more efficient to focus on making ant go into main? > Assuming that needs fixing free JVMs and/or writing library code, it > would be work useful to other projects, instead of duplicating work to > work-around the issue. Mind you, Jim Pick has got ant 1.5.2 to work on kaffe 1.1.0 in the kaffe-extras module in kaffe's CVS with a few patches. You may want to start by looking there. But ... the FSF doesn't think that code licensed under a GPL incompatible license can be allowed to run on a GPLd VM (i.e. kaffe). So it may not be what debian wants/needs ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [kaffe] Problem with the unofficial package of Arnaud Vandyck.
Salut Pierre, --- Pierre Machard <[EMAIL PROTECTED]> wrote: > Hello, > > I am testing the new testing package of Arnaud and I get the following > error. > > compile: > [javac] Compiling 433 source files to > /tmp/jext-sources-3.2pre3/build > > BUILD FAILED > file:/tmp/jext-sources-3.2pre3/src/build.xml:110: Unable to find a javac > compiler; Ant only looks for Sun's javac compiler *and tries to load its proprietary java class*. If you donät have it installed, then you have to tell ant to use a different compiler for builds, like kjc (comes with kaffe), or jikes. The simplest way to do it is to do ant -Dbuild.compiler=kjc though you can also store these settings in a .*rc file for ant, I think. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Ean, --- Ean Schuessler <[EMAIL PROTECTED]> wrote: > and so forth... or alternatively you could use something more symbolic > than version numbers. For instance: > > depends: > java.lang.reflect.Proxy > java.text.Bidi.reorderVisually > java.io.ObjectOutputStream.useProtocolVersion.int that seems like the most sane solution to me. List all the classes an application needs from the standard libs, and list all the classes a vm implementation provides. and then just match. > Before anyone freaks on how much work this might be for VM maintainers > keep in mind that we may be able to leverage a tool like the mauve test > suite to generate dependency information automatically. you can use japitools to see how much of the java class librararies a particular free implementatiomn has covered. you can also use a tool like the bcel verifier to recursively determine the 'class cloud' of an application. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
, breaking ant on every VM that doesn't come with a com.sun.whetever.javac.Main class. That's why you specifically have to tell ant to use kjc as the build compiler on kaffe using -Dbuild.compiler=kjc. The clever way would have been to spawn the build.compiler executable in the PATH in a separate process. then JVMs could come with their own javac wrapper scripts for whatever compiler they wish, with the name javac used as a default for the compiler. that's the real world. It's full of people who sacrifice portability for performance. ;) Obviously, in those cases, using a free VM means having to figure out the quirks of the aplication and to work around them. > IMO, our priority should be on the first. Debian does not gain > anything, if we have a setup, which will fail in some/most cases. > If we do that, we again end up in the same situation as now, where > everybody Depends on $JAVA_HOME/bin/java, where JAVA_HOME is searched > for by a ever again script snippet. Then you don't want to use a free virtual machine. you want to use Sun. There is no certified Java free VM and there won't be as long as sun's licensing policy doesn't change. As long as you don't have a certified java runtime, you can forget about not failing in some cases, because there will be cases where your implementation differs from sun's *within the scope of the spec* (which is quite bad for some classes. Try implementing java.io.StreamTokenizer from the spec if you want to have some fun on the weekend). cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > I will still ask, that all 'java' alteratives (kaffe, gcj, etc) will > add as much API to their bootclasspath as possible. I can only speak for kaffe, but we are gradually trying to merge in as much of the free, GPL-compatible implementations of java APIs that are out there, as possible. After the recent RMI update to Classpath's more recent version, the next goal is to merge in an ORB to implement the CORBA APIs, and to pull in rxtx for javax.comm. > >but that is no guarantee. A later version of JDK may add more > >methods to an interface (Sun has been known to do this), and if > > Sun to an interface? They broke JDBC interfaces quite badly, for example, when they switched to the next JDBC version in java 1.4. > >You can also "java-compatible-with-jdk1.3" but no Free JVM > >are likely to satisfy such a constraint anytime soon. > >(compilatible-with-jdk1.1 is getting close, though!) > > You mean because of swing? There is no full free software javax.swing implementation yet, nowhere. there is no javax.imageio and javax.print. We're trying to get the rest covered by merging in other people's great GPL-compatible work into kaffe. javax.crypto is going to be problematic because of american ammunnition export laws, I guess. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > >B. It doesn't matter what proprietary software provides. This is Debian. > > Yes. And we should at least make this situation for our users as easy > as possible. The situation now is IMO not. part of the problem is that the free vms are not covering everything from jdk, but the other, much greater part of the problem is application writers who assume that the whole world uses sun's jdk. Thus they muck around with $JAVA_HOME, try to load sun.* classes, try to put a non-existant $JAVA_HOME/jre/tools.jar in their CLASSPATH, and so on. When I posted a bug report to ant developers once why their CVS bootstrap script sucked so much on free java environments and whether they would like to fix it, the answer was basically: go away, it works for us. So for example you'll se a lot of broken build.xml files, that assume the java compiler is greedy, and automatically tracks down files needs to compile a class if they don't appear on the command line. Well, surprise, kaffe's java compiler, kjc, does not, and there is no spec saying a compiler needs to do it. > I haven't done it, but this is IMO the way how someone would install > Tomcat on a debian server: > apt-get install apache > apt-get install tomcat4 # does not work, as there is no j2sdk in debian > # two ways: get BD packages, which are outdated by almost a year and > # beta. Or use equies and a -bin downlaod. Or, worst: install BD and > # then get a -bin download and hack the /etc/default/tomcat4 > apt-get install tomcat4 > > Similar things for the browser plugins. there are no free software java browser plugins (yet). Kaffe has a rotten implementation with unknown status, Michael Koch is working on one for gcj, and japhar also had something a few years ago. But you don't want to include a free java plugin without being reasonable sure tha the underlying VM is secure enough. Kaffe and gcj are both getting a verifier implementation at the moment, which is just the first step. The second step is a permission based security architecture, with policy files, code signing and all that. There is no such thing in the free software java world (yet). Glasspath has laid some foundations , though. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
which will satisfy the needs of almost every java app out of > the box. Unfortunatelly we can't package them for debian. This policy > proposal, together with the inclusion of a patched mpkg-j2sdk, will > make them at least useable from debian packages. Without any > improvment, it will become more and more messy, the more API changes > are between the original java2-runtime and, for example, 1.5. Yeah, but I don't really care about sun's java packages ;) If they want to package their java for debian, fine. If they don't, I don't understand why you're all so keen on doing it, instead of trying to make the free alternatives better. I mean, this is debian, it's all about writing, using and promoting free software, right? I'm not a debian developer, but that was my impression as an innocent bystander. > The other thing is, that IMO noone wants to run tomcat under full load > on a JVM, which doesn't do any JIT compilation. This is real world, > too... Then those people should write a jitter for the VM of their choice. Kaffe actually comes with a jitter on many platforms. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> I will still ask, that all 'java' alteratives (kaffe, gcj, etc) will > >> add as much API to their bootclasspath as possible. > >I can only speak for kaffe, but we are gradually trying to merge in as much > of > >the free, GPL-compatible implementations of java APIs that are out there, as > >possible. After the recent RMI update to Classpath's more recent version, > the > >next goal is to merge in an ORB to implement the CORBA APIs, and to pull in > >rxtx for javax.comm. > > So what will happen if we want to have all this classes shared between > other fre JVM? Say kaffe and gcj Depends: classpath, ... Will that > actually work? If yes, on packager level, we can solve this already > now. I assume that those VM's using GNU classpath can share a significant bit or their rt.jars. But there is all those little internal classes with native methods that need to be different (like reflection, class loading, references, etc.), so you can't just share everything, unless you split the rt.jars into a 'common GNU classpath rt.jar' and a 'VM specific GNU classpath rt.jar'. Package sealing may interfer with that, although I doubt any GNU Classpath based VM actually uses a crypto signed and sealed rt.jar. In any case, you'd end up doing a lot of work, with little practical value. Just like many jakarta apps come with tons of differently versioned binary jars in their libraries directories, free VMs come with different, and adapted versions of GNU Classpath that suit their needs best. > >> >You can also "java-compatible-with-jdk1.3" but no Free JVM > >> >are likely to satisfy such a constraint anytime soon. > >There is no full free software javax.swing implementation yet, nowhere. > there > >is no javax.imageio and javax.print. We're trying to get the rest covered by > > So, basicly, these packages are the problems? If thats the only problem, we > could make > java2-runtime-1.4 > -> if all but this is present on the bootclasspath > -> alternative for /usr/bin/java-less-1.4 > java2-full-1.4/java2-unfree-1.4 > -> if this three are on the bootclasspath > -> alternative for /usr/bin/java-full-1.4 > (better names welcome) Uh, I don't think it's an elegant approach. It encourages people to regularly flame each other on debian-java whether package java.x.y is important enough to be a requirement for letting a VM provide java2-runtime-1.z, or their VM would be blocked from being a 'debian-blessed' java2 runtime. > >merging in other people's great GPL-compatible work into kaffe. javax.crypto > is > >going to be problematic because of american ammunnition export laws, I > guess. > > Isn't that foolishing over? Don't know, IANAL nor am I a javax.crypto hacker. ;) > Jan, never much bothered about lizensing... you should. it's very rewarding and fun ;) your 'mix-and-match' bootclasspath has some serious licensing implications. For example, if I take a LGPL-d javax.something implementation, and add in a GPL+linking exception licensed javax.something.else to my bootclasspath, the resulting application needs to be licensed under the GPL, as the lowest common license, AFAIK. It works for kaffe, since kaffe is GPL and we make sure that we only merge in GPL-compatible code, but an ad hoc 'let me quickly add this missing package to my bootclasspath for some application' approach could cause some trouble. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >but the other, much greater part of the problem is application writers who > >assume that the whole world uses sun's jdk. Thus they muck around with > >$JAVA_HOME, try to load sun.* classes, try to put a non-existant > >$JAVA_HOME/jre/tools.jar in their CLASSPATH, and so on. > > eclipse has a really nice policy about such things... for the 3.0 > release, the break a lot of things, but it all well documented. And > they have a really fine tuned API system, down to which methods are > API and which not. Sun also has a (depending on your needs, not so) nice API documentation. Problem is that a lot of people don't really care about it, but use internal details of Sun's implementation like JAVA_HOME that aren't part of the Java APIs. > >So for example you'll se a lot of broken build.xml files, that assume the > java > >compiler is greedy, and automatically tracks down files needs to compile a > >class if they don't appear on the command line. Well, surprise, kaffe's java > >compiler, kjc, does not, and there is no spec saying a compiler needs to do > it. > > IMO, in this cases its better to go with 'everybody'... This should be > a one line change... I don't think so. You have to somewhat intelligently search through source directories to see if you can find the missing files somewhere. If you find an old version somewhere you're going to have some trouble ;) If you find multiple instances of the missing source file as well, and so on. All of that takes more than one line in my book ;) But my point is that the problem is not kjc, but people sheepishly relying on undocumented behaviour. There is no need to fix kjc in this respect, one needs to educate the other developers not to rely on specifics on Sun's platform if they want to be portable / be a part of free software offerings in debian. > >there are no free software java browser plugins (yet). [...] > > Then at least the unfree should be made working with our packaging. I can't tell people what to do with their time, though I'd prefer to see people helping to make free as in speech java implementations rock, instead of making it easy to trade freedom for comfort. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >but the other, much greater part of the problem is application writers who > >assume that the whole world uses sun's jdk. Thus they muck around with > >$JAVA_HOME, try to load sun.* classes, try to put a non-existant > >$JAVA_HOME/jre/tools.jar in their CLASSPATH, and so on. > > eclipse has a really nice policy about such things... for the 3.0 > release, the break a lot of things, but it all well documented. And > they have a really fine tuned API system, down to which methods are > API and which not. Sun also has a (depending on your needs, not so) nice API documentation. Problem is that a lot of people don't really care about it, but use internal details of Sun's implementation like JAVA_HOME that aren't part of the Java APIs. > >So for example you'll se a lot of broken build.xml files, that assume the > java > >compiler is greedy, and automatically tracks down files needs to compile a > >class if they don't appear on the command line. Well, surprise, kaffe's java > >compiler, kjc, does not, and there is no spec saying a compiler needs to do > it. > > IMO, in this cases its better to go with 'everybody'... This should be > a one line change... I don't think so. You have to somewhat intelligently search through source directories to see if you can find the missing files somewhere. If you find an old version somewhere you're going to have some trouble ;) If you find multiple instances of the missing source file as well, and so on. All of that takes more than one line in my book ;) But my point is that the problem is not kjc, but people sheepishly relying on undocumented behaviour. There is no need to fix kjc in this respect, one needs to educate the other developers not to rely on specifics on Sun's platform if they want to be portable / be a part of free software offerings in debian. > >there are no free software java browser plugins (yet). [...] > > Then at least the unfree should be made working with our packaging. I can't tell people what to do with their time, though I'd prefer to see people helping to make free as in speech java implementations rock, instead of making it easy to trade freedom for comfort. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >thanks for taking the time to write a well thought-out, and pointed > >response. I wasn't sure whether my reply was a bit vitriolic ;) > > :) This discussion is nothing against being 'Proponent' of a new > german newsgroup... ouch, i sense frustration ;) > > [free, but not full featured] > >> featured. Most likely, this will end up in many people complaining, > >> why there program isn't running. > >Yes. Send them our way so we can educate them to fix the problems they are > >complaining about by writing the missing pieces ;) > > I'd actually do this (I haven't have time yet to test eclipse with > kaffe...). But I know my skills and they are definitelly not enough to hack > on kaffe or any other 'bigger' non java app. Just by packaging > eclipse, I'm learning more about binary libs than I ever thought I > would... sure. but quite often it's not as hard as it looks. You see that some application A doesn't build on, say, kaffe, due to a missing class,method or field. You look it up in the API docs to see what it does, take a look at GNU Classpath to see if it is already there. If it's not there, you ponder a few minutes whether implementing the field, method, class or interface is within your skills. If you think you can do it, you hop on the mailing list, and we work together on the code, or you take the lead, as you wish. If you think you can't do it, you hop on the mailing list, and tell us what you need implemented and what you need it for, so that we can priritize things a little bit. That's the ideal case, in practice it can take some time until you get a response since there is only few developers compared to the number of bug reports ;) that's also the reason why we need more developers on Classpath and Kaffe and so on. Java APIs are huge, and a lot of work. Currently all the great work is being done by a few handful of highly skilled people (that are pleasure to work with ;). If you don't want free java to always drag on years behind non-free offerings, you should join GNU Classpath and help them implement missing java APIs faster ;) > Seeing that debian is famous about 'that it works', I would say, that > we should have a policy, which: > > * makes all our packages working with every JVM, which will run it: > . free ones > . unfree ones by a well defined API and a installer script that's a great goal. it needs people who test & build java programs on debian on every java implementation in debian. I believe some of that could be actually done automatically, like the buildd setup for normal packages. So let's try another idea: A java package is uploaded for debian. It goes into the java-buildd, which tries to build it under all free java VMs and non-free ones. Where it passes, it also runs the regression tests, if any. If the package passes any free java VMs, it goes into main, otherwise into wherever the java application packages currently are (as you can see I'm not very familiar with debian's package directory system). Where it doesn't pass the free java VMs, bugs are automatically entered into the bug tracking system for the respective package. The dependency information for the package is then set to require one of the free VMs it passes on, and non-free ones it passes on. If the package passes on sun's offerings as well, the lowest java release it passes on is also added as java-1.passed-runtime. so in practice, if someone makes a new ant package, it goes unto the java build environment. There it is tested on kaffe 1.x, it breaks during compilation, and a detailed, automatically generated bug report is added to kaffe's bug list. It turns out to work fine on gcj 3.y, so it is marked as going into main and the gcj >= 3.x requirement is added to ant's depenedency information. Testing with sun's java runtimes reveals that it works with jdk 1.1.8 and above, so it is also made to automatically depend on java-1.1-virtual-package. That means, if someday a free implementation can claim java 1.1 compatibility (without being sued ;) all those packages could move into main. For java VMs, there should be a similar process. When a VM release is updated, the new package goes into the java build demon, and all packages that worked with the older release are rebuilt and tested with the current release. If a package fails, a bug is files against the new release of the VM. If the result of the package failing on the new release would be the removal of package from main, since no other free VM can run it, the new VM release is not allowed to enter 'testing' (if my debian branch terminology is right). that would be a *great* way for d
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
it's the Java APIs as defined by the java platform API specs. It does *not* contain such things like how javac interprets -classpath. It just contains a description of syntax and semantics of all classes available to java programmers in a particular release. The problem is all the developers who just want to make things work and use the rest of the JDK and believe that gives them a right to call it an 'API' ;) If an application uses anything beyound the java programming APIs, it is not portable by definition, not even between different releases by Sun. It may work by sheer luck, but it doesn't have to. As I said, sun has changed their 'API' to java and javac executables in the past, and I assume they will continue to do so. Sun also keeps breaking compatibility between java releases, so saying that a package requires java 1.1 doesn't mean that it will run or run the same on Sun's java 1.2, 1.3 or 1.4. See Sun's docs for any java release for more information. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
hi Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Ross, > Anyway, I'm quite biased, as until now I was only a 'consumer', and > this and other 'unfree' lizenses never happend to limit what I wanted > to do. Are you sure you've read Sun's license? ;) > I might need a bit debian-legal reading to get into a different /the > right mind for Debian :) I know that if you just want to get stuff done, and simply use java, all this fundamentalist criticism from the side lines is no great help. But experiance taught some of us that freedom is better than temporary comfort ;) Read up on some of the GNU philosophy on the gnu.org web pages, that should be a good start to learn more about the value of freedom as in speech ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > Just a short reply. I'm running out of time... :) And BTW: no need to > CC me. I hope I have set the required headers... Sorry about the CC:, I use to hit the reply all button automatically ;) > * Dalibor Topic wrote: > So again, this is a no-no. I just thought, that it's always this tree. > I get more and more the impression, that the only way is to > > * interface to unfree VMs (wqhich should be ~100% sun compatible And this means providing some java & javac wrapper scripts, setting CLASSPATH etc, right? > * test all free java versions. > * interface to ant, so that the build time testing is as easy as > possible. what's an interface to ant? Do you mean setting up ant for use with a particular VM/compiler combination? > >> Jan, never much bothered about lizensing... > >you should. it's very rewarding and fun ;) > > I can see that :) I just saw a bit from the GFDL discussuion on > debian-legal. That's even better that the de-admin.news.groups > discusions... You should come to our semi-annual 'Does kaffe's GPL license apply to code running on kaffe' mailing list bursts. Pure fun. Sometimes it even spills over to debian-legal ;) > BTW, wasn't there something, that SUN considers API information also > under their lizense? Makeing CLASPATH basicly illegal? Hm, I'm too > lazy to google... I think their licensing terms for the java API specs are very ... uh ... limiting. But as I said, kaffe is not java not a replacement for sun's offering. > >but an ad hoc 'let me quickly add > >this missing package to my bootclasspath for some application' > >approach could cause some trouble. > > Not even, when you do that in a wrapper script via --bootclasspath? Or > in the wrapper script of the app? That's the perfect kind of question for debian-legal ;) My gut feeling is that one needs to be very careful as a distributor of copyrighted works not to create derived works that violate the licenses of involved works. Adding missing classes to kaffe's bootclasspath from Sun's rt.jar for example, would violate the GPL. It may work for other VMs, I don't know, but I doubt that Sun's distribution terms allow it. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Ben, --- Ben Burton <[EMAIL PROTECTED]> wrote: > > Just a note: > > > People will always complain, as long as the free java implementations > > are not equivalent to sun's on all accounts. Frankly, as long as they > > don't want to put the little extra effort, and work with us to fix the > > issues (for example by implementing and contributing the missing APIs > > to GNU Classpath), I don't care that much about it. The free java > > implementation efforts need contributing users and developers, people > > who just say: it doesn't run my Swing app, it sucks! are not that > > helpful. > > It's not always as black-and-white as this. I for instance have had to > look inside sun's src.zip at times in the past to be able to work around > their bugs. AIUI this means I cannot contribute to implementing the > missing APIs. I presume I am not the only person who cares about free > JVMs who is in this situation. You can always continue to make great bug reports, as you do ;) Writing the code is just one of many ways to help. Writing documentation, testing the code and writing useful bug reports are also great ways to contribute. Or participating in creation of a new java policy for debian ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> * makes all our packages working with every JVM, which will run it:
> >> . free ones
> >> . unfree ones by a well defined API and a installer script
> >that's a great goal. it needs people who test & build java programs on
> debian
> >on every java implementation in debian. I believe some of that could be
> >actually done automatically, like the buildd setup for normal packages.
> [nice idea about a buildd like infrastruckture to test, whether it
> works on free VMs as well]
>
[snipped out good comments on why it won't work]
> All in all, I think we first need a better working policy, before we
> could start thinking about such a project.
Fair enough. I think that such a project is crucial to making free java
software work well in debian.
> I also think that this can only added 'next to' the packaging system,
> maybe sending the apropiated BTS mails ('Wishlist: Your package is compiling
> with XYZ now' 'Grave: Kaffe will not build 'XYZ' anymore'). Again,
> this needs well defiend interfaces so that this here is not anymore
> nessesary:
>
> in debian/rules
> |JAVA_HOME_DIRS="..."
> CDBS, ant classes:
> JAVA_HOME = $(shell for jh in $(JAVA_HOME_DIRS); do if [ -d "$$jh" ]; \
> then echo $${jh}; exit 0; fi; done)
>
> This is basicly the workaround in every java package I've seen so far.
> In eclipse debian/rules, I've a similar line in (but I Build-Depend on
> BD Java) and its repeated in /usr/bin/eclipse [1]. It only works
> with BD packages, as we know the place, where they are added. Free VMs
> would need to be complient to JAVA_HOME use (gcj isn't...), work with
> ant (Kaffe? Sable VM?).
What do jh and JAVA_HOME do (in this case)? What does eclipse need JAVA_HOME
for?
> >noble goal, but as I explained in the other mail, there are
> >differences in the behaviour that some java/javac implements. Some of
> >it is intentional.
>
> BTW, does kaffe support '-cp'? I just had a bugreport about this
> (actually that eclipse "does not work" because it fell back to
> /usr/bin/java, which was kaffe)
Kaffe 1.1.1 does.
> BTW, javac 1.4.2 added that option as well...
Well, this raises the question what the interface to javac should be: the one
from javac 1.0, 1.1, 1.2, 1.3 or 1.4, or 1.4.2? Should it include all options,
or just the important ones? And so on ... the same for java. Does debian's java
policy proposal cover that? Otherwise it would be useless in the eclipse vs.
-cp case ;)
> >Though, now I think the java build demon aproach is better, as it
> >actively figures out what works and what doesn't instead of relying on
> >API descriptions.
>
> The Mainatainer of the package will be the "Java Build Demon". :/
> Hopefully helped by as much policy and helper scripts as possible...
I think that puts too much burden on the maintainer. Having a good policy is
all well, but without actually being able to confirm that a package works with
a VM on say superh-linux, it's not really helpful, beside placing additional
buerocratic load on the maintainer, I think.
> >> First of all, it will work with packages like xerces, which already
> >> now can be updated 'endorsed dir' or so, or simple adding a newer
> >> version to bootclasspath.
> >fine, but for example you can't put xerces into kaffe's bootclasspath as its
> >licensed under GPL-incompatible ASF license.
>
> Not even with a java -bootclasspath `getclasspath --boot` -cp ... at
> packaging level (by Depending on the debian xerces package)?
>
> If thats not possible, I simple give up... :(
No, I'm not saying it's not technically possible, you're just not allowed to do
it/distribute it by the provision of the conflicting free software licenses
involved.
> >they set it because they want their internal compiler instead of sun's. if
> >build.compiler is not set, it default to sun's compiler.
>
> Eclipse compiler is 'free', so we have already a Java1.4a/1.3 compiler,
> which passes all of suns 'testing Kits'... Maybe I should split this
> package out so that it can go into main.
it passes the regression tests from sun? do you have a link? how does it fare
on jikes' compiler test suite jacks?
the rhug guys sperated it out, and apparently made it faster than jikes by
compiling it with gcj ;)
cheers,
dalibor topic
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > >> Then at least the unfree should be made working with our packaging. > >I can't tell people what to do with their time, though I'd prefer to > >see people helping to make free as in speech java implementations > >rock, instead of making it easy to trade freedom for comfort. > > But IMO, we shouldn't force them to it. Or punish them with fixing a > problem, which could easily be dealt with at packing level. especially > as we are not talking about some tiny special program, but java. By the way, how is C# handled in debian? They should have a similar set of problems: several incomplete free runtimes and an unfree commercial one. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote: > > >What interface do you suggest? The discussion her pretty much showed, > >that you can't rely on anything. This would mean: > >* -classpath is probably save (-cp already not...) > > > I think we should define an interface in the Java policy, then write > wrappers for the different compilers, and install the wrappers as the > alternative (this is already done for jikes-* at least and for the gij > JVM). So we can indeed handle -cp in the wrappers. > A precise interface should be discussed together. Off my head: > -classpath, -cp, -sourcepath, -O, -d, -g, -deprecation I'd remove a few things from the list, since javac 1.4.2 doesn't support -cp and javac 1.4.2 doesn't support -O. > >* setting up rt.jar? in javac or in the calling script? The script > > doesn't know the location, so we would be better off with > > /usr/lib/java-dev-env, which would be relative easy to maintain. > > > rt.jar could be defined by default, but overridable with -bootclasspath > (handled in the wrapper if necessary). This matches Sun's javac > behaviour, so it should make more existing scripts work out of the box > on Debian. -bootclasspath is somewhat tricky. I'm not sure how to do this with kjc, which is intergrated into kaffe. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: info request about p2p framework (fwd)
Ciao Stefano, Freenet releases that don't use NIO should run on latest kaffe (1.1.1), as well as Mark Wielaard's java bittorrent client snark. cheers, dalibor topic --- MJ Ray <[EMAIL PROTECTED]> wrote: > Stefano Maffulli <[EMAIL PROTECTED]> asked me the following question, > after being asked about Java peer-to-peer software. I will mention > bittorrent to him as something to look into. I don't know the answer > to the jxta part, so I'd appreciate it if anyone on debian-java could > cc him a reply. > > Stefano wrote: > Now the question: are there any p2p infrastructure based completely on > free software around? Or do you know if jxta can work on > Jikes/Kaffe/gnuclasspath ? Feel free to ask your colleagues and > friends too :) > > A friend passed me this link, but it mixes free/non-free > http://www.openp2p.com/pub/q/p2p_category > > let me know, > regards > stef > > TIA, > -- > MJR/slef My Opinion Only and possibly not of any group I know. > > RFC3156 defines security multipart formats for MIME with OpenPGP. > ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > 2.1. Virtual machines > > As it is nearly impossible to treat all java virtual maschines the same, > JVMs are seperated into two kinds: sun compatible and not. The first ones > should be used via the below interface, every other virtual maschine has to > be called seperatly. > > Sun compatible virtual maschines of a certain java spec version have to > provide the virtual package java-runtime-version (where version is the > curent spec version number) and setup alternatives for /usr/bin/java-version > and the corresponding manpage. They must depend on java-common. > > Packages, which want to contribute a alternative for /usr/bin/java and its > manpage must provide java-runtime. The alternative must accept the option > '-classpath', which sets the classpath and autmatically adds the right > rt.jar. The must depend on java-common. You need to specify what you mean by setting the classpath more closely. Preferably, explain the semantics you want using an example. Current wording is too vague. > Priorities should be set as follows: highest Spec version multiplied with > 100 (1.4 -> 140), free VM may add 30 points, for incomplete spec > compatibility subtract 30. Revisions may add 1 point, as appropiate. Uh, is this really necessary? It seems like a quite awkward spec compliance rating system. > 2.2. Java Development Tools what about javap, rmic, rmiregistry ? > Chapter 3. Issues to discuss > > The following points are discussions about the policy, either because they > have to be studied more, or are controversial. > > * Name and existance of the repository. It was removed in the latest >version. > * Core classes (java.*). More study needed. > * Sun's Community Source Licence. Can we use it? How? The 2.3 >version of the text can be found [19]here. I doubt it, since it's not free software in the DFSG sense. It was not even open source last time I looked at it;) > * Should there be a default classpath, similar to a repository? >Which jars should be included in that? A standard and one optional >part? If there are a default classpath (in the wrapper) how should >it be overridden? Adding unnecessary packages to the classpath can increase application startup time, since the java API spec requires the system class loader to search linearly through the bootclasspath, system extensions, and the classpath. So I'd recommend against a default classpath setting. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > 2.1. Virtual machines > > As it is nearly impossible to treat all java virtual maschines the same, > JVMs are seperated into two kinds: sun compatible and not. The first ones > should be used via the below interface, every other virtual maschine has to > be called seperatly. > > Sun compatible virtual maschines of a certain java spec version have to > provide the virtual package java-runtime-version (where version is the > curent spec version number) and setup alternatives for /usr/bin/java-version > and the corresponding manpage. They must depend on java-common. > > Packages, which want to contribute a alternative for /usr/bin/java and its > manpage must provide java-runtime. The alternative must accept the option > '-classpath', which sets the classpath and autmatically adds the right > rt.jar. The must depend on java-common. You need to specify what you mean by setting the classpath more closely. Preferably, explain the semantics you want using an example. Current wording is too vague. > Priorities should be set as follows: highest Spec version multiplied with > 100 (1.4 -> 140), free VM may add 30 points, for incomplete spec > compatibility subtract 30. Revisions may add 1 point, as appropiate. Uh, is this really necessary? It seems like a quite awkward spec compliance rating system. > 2.2. Java Development Tools what about javap, rmic, rmiregistry ? > Chapter 3. Issues to discuss > > The following points are discussions about the policy, either because they > have to be studied more, or are controversial. > > * Name and existance of the repository. It was removed in the latest >version. > * Core classes (java.*). More study needed. > * Sun's Community Source Licence. Can we use it? How? The 2.3 >version of the text can be found [19]here. I doubt it, since it's not free software in the DFSG sense. It was not even open source last time I looked at it;) > * Should there be a default classpath, similar to a repository? >Which jars should be included in that? A standard and one optional >part? If there are a default classpath (in the wrapper) how should >it be overridden? Adding unnecessary packages to the classpath can increase application startup time, since the java API spec requires the system class loader to search linearly through the bootclasspath, system extensions, and the classpath. So I'd recommend against a default classpath setting. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > >My gut feeling is that one needs to be very careful as a distributor of > >copyrighted works not to create derived works that violate the licenses of > >involved works. Adding missing classes to kaffe's bootclasspath from Sun's > >rt.jar for example, would violate the GPL. It may work for other VMs, I > don't > >know, but I doubt that Sun's distribution terms allow it. > > So that basicly means, tat you have to reimplement everything by hand > and can't uses things like xerces? No. You can still use xt or saxon ;) > So when I write > kaffe -bootclasspath xerces.jar .. -cp ... Main > I can't do it, because its against the GPL/whetever License? I'm not sure. Technically of course you can do it, but I don't think you can distribute the resulting work. So when your bootclasspath script modifies the boot class path, it effectively changes what classes link to each other. The FSF has a very strong position on it: GPL propagates through class usage. See the thread starting at http://www.kaffe.org/pipermail/kaffe/2002-August/040251.html for some information on different interpretations. As I said, it's up to debian-legal to figure out whether your bootclasspath scripts don;t violate licenses, IANAL. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gcj version of Jar
--- David Goodenough <[EMAIL PROTECTED]> wrote: > Does anyone know that the GCJ version of Jar is? If not is there an open > source version of Jar somewhere. Its close to zip of course, but just not > quite close enough, and the options are more like those from tar. gcj comes with a jar tool written in C or C++ called fastjar. Kaffe comes with a jar tool written in java called, well, jar. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> So when I write > >> kaffe -bootclasspath xerces.jar .. -cp ... Main > >> I can't do it, because its against the GPL/whetever License? > >I'm not sure. Technically of course you can do it, but I don't think you can > >distribute the resulting work. So when your bootclasspath script modifies > the > >boot class path, it effectively changes what classes link to each other. The > >FSF has a very strong position on it: GPL propagates through class usage. > See > >the thread starting at > >http://www.kaffe.org/pipermail/kaffe/2002-August/040251.html for some > > I've read that thread and as far as I understood it (my brain shuts > down on this things... whoever made licenses viral should be sued for > the braindamage in my head.), I haven't found such a thing. > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states > that such things happen when you use JNI with GPL code. Anyway, I'm > neither a laywer, nor in any way experienced enough with such a > question. The ugly point is that almost every VM contains some native code that's being linked to. You couldn't otherwise implement java.lang.Process, for example, except on pure java operating systems. > *IF* thats the case, then we have to treat kaffe almost completely > apart from every other javaVM. As there are a lot of unfree libraries > which can be pulled in via such nice things as Class.forName() > (eclipse plugins, ant tasks for example), I'm not sure, if that is > even controlable in any case. I don't think you can or should prevent your users from using Class.forName with kaffe. But as a distributor, you need to be careful what your shipped binaries link to. > If we have kaffe, ant can be run with it and the users then installs a > non-free ant task and uses it. Who will be sued? I am not a lawyer ;) But I doubt anyone can be sued, if the user doesn't distribute the derived work, which she can't without violating the GPL, so it's not your business ;) In any case, you can't control how your users violate the licenses. > How can the API be actually differently licensed than the sun > one? That's exactly the question that I think is a crucial argument against FSF's argument: if you don't know you're linking to a GPLd implementation, you can't be bound to it. But again, I think you need to consul debian-legal for answers to those questions. > >information on different interpretations. As I said, it's up to > >debian-legal to figure out whether your bootclasspath scripts don;t > >violate licenses, IANAL. > > If this whole is true, than we should fork this thread to debian-legal > and ask there... Yes. But as I don't think that you need bootclasspath, I don't think you need to go there if you drop it ;) > BTW, why is bootclasspath any different from classpath? As far as I > understood it, the only difference is the position, where the libs are > included (bootclasspath, internal, bootclasspath) and so which version > is found when a app wants to get a instance of a class. Bootclasspath is where the VM finds its runtime classes, ie. the crucial stuff it needs to work. You break it, you break any application automatically. Runtime classes sometimes don't use the published APIs, since it would be impossible to implement all of java's class library with just the published APIs. If you mix and match classes in there, you should know your VM inside out or you will break things. I don't think such lowlevel hackery belongs into the policy. It's basically as if debian tried specifying a kernel module API for kernels debian should run on. In order to be able to exchange binary modules between kernel revisions and versions, with the goal to run the linux nvidia drivers on windows. > Other options? Drop the bootclasspath proposal altogether. It creates problems for VMs that don't support java 1.3 class loading features. There is a lot of good code that doesn't need bootclasspath modifications to work. The nly good use of bootclasspath is when you are implementing a java API and want to try some updated code without regenerating the whole rt.jar. If eclipse needs remixing the bootclasspath in order to work, then eclipse is the exception, and its misbehaviour shouln't be endorsed by debian java policies. You can't just assume that you can stuff xerces into the BOOTCLASSPATH and all will be well. Kaffe for example uses GNU JAXP, which doesn't use xerces, but uses Aelfred2 and libxml2 to do the work. So stuffing an updated xerces.jar into kaffe's bootclasspath shouldn't have the effect you&#
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> A precise interface should be discussed together. Off my head: > >> -classpath, -cp, -sourcepath, -O, -d, -g, -deprecation > >I'd remove a few things from the list, since javac 1.4.2 doesn't support -cp > >and javac 1.4.2 doesn't support -O. > > I thought that javac 1.4.2 actually added -cp? Anyway, we can seperate > the interface for java and javac. I don't actually mind, if we have > -cp, as patching programms to use -classpath should be fairly easy. It didn't, according to http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javac.html > java > -classpath -bootclasspath -jar -dxx=xx > > javac > -classpath -sourcepath -bootclasspath -d -target -g > > In my opinion it is better to use a jitter than -O, especially if we > have more that one JVM. -O is also known to be broken on java 1.1's javac at least. It performs some illegal optimizations. > I thought it doesn't put the rt jar on the claspath, when you specify > -classpath. So add the -bootclasspath before the rt.jar (or whatever That shows how tricky -classpath handling is without an exact specification of what you expect to see. In general, the concensus seems to be that -classpath puts something on the CLASSPATH. Where exactely it puts things has changed between java 1.1, 1.2 and 1.3, so that now it puts something on the CLASSPATH, but doesn't touch BOOTCLASSPATH, which still contains rt.jar and is sought for classes first. > it is names) and it should be fine. If thats the search path for > classes... Without, we probably can't use kjc, as a javac replacement > or ant compiler, as the result would be unpredictable, especially when > a programm wants to have a newer version of one of teh included APIs I think programs that want to have a news version of the included APIs should wait for an updated java API, come with their own VM & class library or use something sane like their own ClassLoader to link to the classes they want. No userland program should touch bootclasspath. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> Packages, which want to contribute a alternative for /usr/bin/java and its > >> manpage must provide java-runtime. The alternative must accept the option > >> '-classpath', which sets the classpath and autmatically adds the right > >> rt.jar. The must depend on java-common. > >You need to specify what you mean by setting the classpath more closely. > >Preferably, explain the semantics you want using an example. Current wording > is > >too vague. > > It seems that the interface specification will get really long (see > the other post asking for more options to be included in that list) > -classpath :, where is a full path to a > Java Archiv file. > ... So you've just forbid the use of directories in -classpath per policy. Are you sure you want to do that? ;) What's wrong with relative paths? And finally, what's the effect of -classpath a.jar:b.jar supposed to be? How does it alter the class lookup? What about the current directory? Is that included automatically? And so on ... A lot of these are questions that you get to ask yourself when you write system class loaders in a VM. I'm trying to get you to realize that Sun has changed their CLASSPATH spec a couple of times in incompatible ways and that you can't cater for them all, so you have to pick an interpretation and stick to it. Different VM writers will pick different interpretations. Codifying a particular behaviour in the spec doesn't really help, unless you want to put pressure on the maintainers to *reimplement* Sun's class loading in java 1.1 to match the debian java spec's idea of class loading taken from java 1.4. I'm trying to show you that some parts of your java policy are quite good, while others are too vague. When I try to pin down the vague parts, we get into the morass of different specs by Sun. To me, this means you should drop the vague bits if they can't be specified exactly ;) > >> Priorities should be set as follows: highest Spec version multiplied with > >> 100 (1.4 -> 140), free VM may add 30 points, for incomplete spec > >> compatibility subtract 30. Revisions may add 1 point, as appropiate. > >Uh, is this really necessary? It seems like a quite awkward spec compliance > >rating system. > > IMO yes. This will ensure, that when using java, the best and > latest version of instaleld JVMs will be /usr/bin/java. This will be > the best and wanted case in most cases. Then you need some authority to determine the 'best and latest version' of free VMs for those people who don't want to install non-free software (a lot of debain users, I think). I propose the creation of a debian-who-s-got-the-best-free-java mailing list for bug reports about VM compatibility ratings, flame wars about whose CLASSPATH is longer, and of course the never-ending religious wars between kaffe and gcj zealots. No, please don't do that. ;) > >> * Sun's Community Source Licence. Can we use it? How? The 2.3 > >>version of the text can be found [19]here. > >I doubt it, since it's not free software in the DFSG sense. It was not even > >open source last time I looked at it;) > > So this part should be removed, if thats clear. According to the debain Java FAQ: http://www.debian.org/doc/manuals/debian-java-faq/ch5.html 5.3.1.2 What are the problems with Suns' new license? Sun has moved to a new license the Sun Community License, like the GPL it is a viral license, but making all it touches subject to Sun licensing fee. The SCSL even goes so far as to define any implementation of a Sun specification as a "Modified Work". Basically, this means that if you implement any part of the new 1.2 API or Jini API, even from scratch, Sun will "own" your implementation and you will have to pay them for the right to use it. 13. "Modification(s)" means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Ean Schuessler <[EMAIL PROTECTED]> wrote: > I'm afraid that I agree with Matt. As much as I like the idea of > abstract dependencies it seems that it will become much more complex and > much harder than just depending on a runtime that is known to work. The > core issue being that there are far fewer VMs than there are possible > base class library dependencies. Easier just to say "j2sdk1.4 | kaffe | > orp" if that is what is known to work. That's my proposal as well. Instead of relying on some (pointless for free implementations) notion of abstract APIs write down what works. If it doesn't work, let people who need it to work investigate, and get in touch with the developers to fix the problems. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Matt, > [snip] > This interface is not for the free ones but only for the sun complient > ones (Sun, BD, IBM). The rest will be handled independently. [snip] > With this interfaces you can install a package and know that it will > run, even if you have a non complient VM installed. Therefor this > packages will get more attention: currently, you have to do some work > to get java working. Together with kaffe in main and the packages > using it, most people will not bother to get a unfree one. I sense a contradiction here. Either the interface is meant for non-compliant free VMs as well, then the first paragraph is weird, or the free VMs will be handled separately, but then there is no interface, so the second paragraph is, huh, weird ;) [snip] > Debian has a reputation, that it works. Not that the users are the beta > testers. Then tell me, how does having an interface that noone implemented make things magically work? I'm sorry, but I don't see how that will help free java in debian. It may get more bug reports submitted to kaffe & co, and make releases take longer because all of that has to be sifted through, bit it won't really help. Here's another one: you'll have to keep updating that interface with every new release of Sun's VM, because they add things here, and break things there. If you feel like having the next discussion on the virtues of adding a way to select a compiler that supports the assert keyword for packages that may use that, then why stop there? You may also want to consider adding a switch to the interface to make sure compilers generate the code in a compatible byte code format with the VM the code is supposed to run on. Sun has changed the byte code format as well between releases, so code built with jikes 1.18, for example, may not run on some VMs. And so on: next year, when java 1.5 somes out, sun will be adding a few more changes to the language, like generics. You'll need to take care of that, too ... I think that codifying a status quo is such a good idea. It makes the policy obsolete quite quickly. I'd prefer a policy that tells maintainers to explicitely tells maintainers to test their packages with free VMs and mark those that work. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > And the thing is, it will work. JAVA_HOME is not advertised anywhere, > but almost every startscript uses it. man ant, man eclipse, man > tomcat4 (oups: "No manual entry for tomcat4", which tomcat4: > /usr/bin/tomcat4). All use it, but no word in the man page (eclipse is > my package, so consider this as 'will be fixe din the next > upload'...). Then those packages are borken ;) That was apparently the concensus reached the last time JAVA_HOME has came up on this mailing list: http://lists.debian.org/debian-java/2003/debian-java-200301/msg3.html If the packages need java, the executable, they should use whatever 'java' is in the PATH. If they need it to load sun.only.dedicated.morons.use.this.api.Main, then they are broken and need to be fixed. There is no reason to use JAVA_HOME. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Ean, --- Ean Schuessler <[EMAIL PROTECTED]> wrote: > Something I have just now thought of that might make more sense. What if > we use Classpath as the standard instead of the Sun VM releases? > > Therefore, > Kaffe: provides: Classpath-0.5 > ORP: provides: Classpath-0.5 > J2SDK1.4: provides: Classpath-0.5 > Tomcat4: depends: Classpath-0.5 > > The only trouble is that Classpath-0.5 is Classpath's actual version and > not some sort of intentional demarcation of features. Maybe what we need > is some sort of Free Java feature spec that is loosely based on > Classpath. I think Classpath is pretty representative (if not > fundamental) for the various Free VMs that are out there. In a way, yes. But different VMs use different (i.e. adapted, partial, old, or straight from CVS) versions of Classpath. So it could again cause more confusion than good. > Kaffe is actually mostly compatible with the JAVA_HOME "standard" now > that I use symlinks for Debian compatibility. It might be worth making > the JAVA_HOME structure part of Debian policy. GCJ and friends could > create some simulation of it by symlinking stuff into a fake JAVA_HOME > structure. I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should be in there, or how it should work. It's just a part of the ugly java folklore, like trigraphs in C. ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states > >> that such things happen when you use JNI with GPL code. Anyway, I'm > >> neither a laywer, nor in any way experienced enough with such a > >> question. > >The ugly point is that almost every VM contains some native code that's > being > >linked to. You couldn't otherwise implement java.lang.Process, for example, > >except on pure java operating systems. > > So suns VM is breaking licenses? No, as long as they don't link to GPLd code. But if debian distributed Sun's VM linked to a GPLd libc, *debian* *could* be breaking the GPL. I don't know about the implications of the GPL when all the offending code is doing is using some 'standard' API. Anyway, it doesn't matter in the context of our discussion. > >That's exactly the question that I think is a crucial argument against FSF's > >argument: if you don't know you're linking to a GPLd implementation, you > can't > >be bound to it. But again, I think you need to consul debian-legal for > answers > >to those questions. > > Would you mind writing up such questions and sending them to > debian-legal. I simple don't have the mind to deal with b**t. sorry, but the legal stuff has always been important to debian. It's your policy proposal, and you need to make sure it holds water, especially in the legal sense. If it 'just works', but due to lack of legal review puts Sun in a position to pull an SCO on debian users because of your bootclasspath update hack, then we all have a massive problem on our hands. It's better to be safe then sorry, even if it takes a little longer to flesh out the policy. > >Yes. But as I don't think that you need bootclasspath, I don't think you > need > >to go there if you drop it ;) > > I think it will be a problem with the XML Parsers. They have bugs and > as 1.4 becomes older, we will see programm depending on newer XML > pasers. Same will happen with otehr versions (think java 1.5 and so on) Hey, even the rest of Sun's java 1.4 (or any other free or non-free java implementation) is full of bugs. ;) So what? If people depend on some specific functionality (like bugfixes) then there is a perfectly sane way to do it in java, without modifying the VM or the class library. It's called user defined class loaders. Each class loader defines its own 'set' of classes, and *can* delegate to its parent if it needs to. So your XML parser problem could be solved by using a special XML-Parser-ClassLoader to load the updated version instead of the original one. That's much better than fiddling with bootclasspath. Nevermind that your XML parser problem mihgt also be solveable using XML parser selection techniques as defined in the API, see XMLReaderFactory for more information. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: newer jikes may never get to testing (and thus stable)
--- "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> wrote: > Package: jikes > Version: 1.18-6 > Severity: wishlist > > Hi all! > > I used to be very busy/without net during last months but I am back. > And attacking ;-) > > The problem is that currently jikes (in the sense of source package, > which is important from testing migration scripts POV) depends of > a whole pile of packages. Just take a look: > http://qa.debian.org/developer.php?excuse=jikes > > The problem is that jikes privides wrappers which depend on every > possible JVM in Debian. So for ex. if *ANY* of them won't make it > into testing - we won't have jikes in testing and thus in stable! [0] > > Probably the proper fix for that would be that creation of wrappers > should be only up to JVM/classpath maintainers and be done by them, > probably in their JVM/classpath packages. Wouldn't it be better to provide the wrappers as separate jikes-on-xyz packages, that would depend on both jikes and the VM/classpath package? jikes could depend on any one of the wrapper packages being installed, if that's possible with debian's dependency system. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >And finally, what's the effect of -classpath a.jar:b.jar supposed to > >be? How does it alter the class lookup? What about the current > >directory? Is that included automatically? And so on ... > > If we want to have policy define things that deep down, we will never > get anything done. This interface for /usr/bin/java and /usr/bin/javac > is not to be used in packaging. This 'interface' is simple something > to give to the user, so that not everything is different from what he > knows. Why do you assume familiarity with some command line synopsis? The effect of -classpath a.jar:b.jar for example can have different effects depending on the VM used, and its version. That's what the documentation is good for ;) > >A lot of these are questions that you get to ask yourself when you > >write system class loaders in a VM. > > But I'm not. I try to write a policy for debian. You don't know what you're missing out on ;) > >Then you need some authority to determine the 'best and latest version' of > >free VMs for those people who don't want to install non-free software (a lot > of > >debain users, I think). I propose the creation of a > >debian-who-s-got-the-best-free-java mailing list for bug reports about VM > >compatibility ratings, flame wars about whose CLASSPATH is longer, and of > >course the never-ending religious wars between kaffe and gcj zealots. No, > >please don't do that. ;) > > Just setting them all to 200 isn't any better. This priority system > should IMO fullfill this goals: > > * get a newer version before the older one uh, that's what the debian packaging system does already, right? when let's say kaffe 1.1.1 is out, it replaces kaffe 1.1.0 in debian, doesn't it? > * get a more spec complient version before any not so spec complient > version. that's the ugly part, where someone gets to be the judge who's how much compliant. It's not clear how you want to judge spec compliance. Could you elaborate on that? > * get a free one before a unfree one. yay! I'm all for that ;) > IMO in this order, as the first two 'make it work'. But other opinions > my differ. Please give me a different way. I'd leave to packagers to explicitely name those VMs that work with their package, i.e. they built their package with the VM, and tested it, and it worked. If the packager says it works with sablevm, then it should work with sablevm. If the packager says it also works with kaffe, then it should also work with kaffe. If the packager doesn't say that it works with sun's vm, then it would be wrong to assume that it does. I think your priority scheme tries to solve the problem what to do when two or more VMs are able to run an application. Instead of trying to write an engine to pick what the debian policy considers to be the best VM for the task, why not let the packagers and the users work it out? I think that a better scheme would honor user preferences as expressed in their $PATH setting. Let's hypothetically say the user tries to run tomcat-xyz, which is according to the packager able to run on both sun's VM, blackdown, IBM, and sablevm. The user prefers to run free VMs over unfree ones if any possible (not so uncommon for debian users), so his $PATH has sableVMs java executable before the unfree ones. Ideally, debian java wrapper will delegate the call to the first suitable VM package it finds on the PATH, which is sableVM in this case. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >If the packages need java, the executable, they should use whatever 'java' > is > >in the PATH. If they need it to load > >sun.only.dedicated.morons.use.this.api.Main, then they are broken and need > to > >be fixed. There is no reason to use JAVA_HOME. > > I think we just agreed that this is simple not possible. Or so at > least I have parsed this discussion. Uh sorry, I wasn't clear then. I thought I had successfully lobbied against using JAVA_HOME for finding executables or Sun's classes. The only remaining reason why that's not possible would be the JNI includes, right? I haven't used JNI much, so it would be nice if someone who packages a JNI library could chip in here and provide some insight about what's necesary, and how they use to find it. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should > be > >in there, or how it should work. It's just a part of the ugly java folklore, > >like trigraphs in C. ;) > > But it has a nice ring to it, as almsot every package uses it. So > making some requirements (like bin/java, bin/javac, includes/.., > javadoc?), which should satisfy almost every package and buildtime > requirement. I think that JAVA_HOUSE_OF_CARDS would be more appropriate, nice ring, and all that. ;) Just because many people use something, doesn't make it useful. Without a specification by Sun what JAVA_HOME supposed to be good for, it would be debian specific cruft, and work by chance with Sun's offering as long as Sun decides to support that undocumented interface. I don't think that's a good foundation to build a policy on ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > I wanted to say, that you have a interface for the 'unfree' ones and > this interface will work, even if you have 'not working' JVM > installed. The current interface (/usr/bin/java) does not garantee, > that your package is working. I don't think that an 'interface' can guarantee that a package is working with a specific VM environment. Only testing by the üackagers and users can guarantee that. > >I'm sorry, but I don't see how that will help free java in debian. It > >may get more bug reports submitted to kaffe & co, and make releases > >take longer because all of that has to be sifted through, bit it won't > >really help. > > What do you expect? This policy is about packaging java apps/libs/jvm in > debian. It can include some items to make porting the app to a free VM > easier (which could be done by simple adding a alternative for the > required 'unfree interface' and then start testing), but this si IMO > not the primary goal. >From debian I'd expect a policy that helps and guides java apps/libs/jvm maintainers to build and package their stuff with a focus on free VMs, gives pointers who to get in topuch with if things don't work, has a section on free java developers working on providing a free java infrastructure and how to contribute to it, and provides the necessary bits of information on how to deal with the legacy, proprietary VMs. Certainly not the other way round ;) > So what interface do you propose? I think that adding something to the > ant-build-compiler interface or even making it > ant-build-compiler-version would solve most of this. I haven't thought about an ant build interface yet. I think it should mostly concern itself with setting a few ant properties, like 'build.compiler' to try to ensure that ant works with a particular VM environment, instead of relying on sun-centric defaults provided by ant. > >I think that codifying a status quo is such a good idea. It makes the policy > >obsolete quite quickly. I'd prefer a policy that tells maintainers to > >explicitely tells maintainers to test their packages with free VMs and mark > >those that work. > > And what's the difference with my proposal? The only thing is, that > policy can't tell mainatiner something, just how you package has to be. Sorry, then I must have misunderstood. I thought your policy proposal defined some 'java-xy compatible interfaces' that java packages should use, where the interfaces are losely defined to match Sun's, in hope that this would make an application work on all three non-free VMs and maybe even on free ones, should they ever achieve some undefined form of java-xy compatibiliy. Instead, my proposal is to drop the notion of compatibility, and have the maintainer put down what VM environments work, and depend on any one of them being installed. > The current 'policy interface' (/usr/bin/java, etc) is just to less to > work. But IMO, we can't simple start a policy, which requires every > small thing or this policy will be longer than the complete debian > policy... Uh, I'm not saying that the current debian java policy is all that great. I applaud your effort so far, to get debian java developers to re-think debian support for java and to revise the policy. It has been a very educational experience for me ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: newer jikes may never get to testing (and thus stable)
Hi Matt,
--- Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
>
> > > I used to be very busy/without net during last months but I am back.
> > > And attacking ;-)
> > >
> > > The problem is that currently jikes (in the sense of source package,
> > > which is important from testing migration scripts POV) depends of
> > > a whole pile of packages. Just take a look:
> > > http://qa.debian.org/developer.php?excuse=jikes
> > >
> > > The problem is that jikes privides wrappers which depend on every
> > > possible JVM in Debian. So for ex. if *ANY* of them won't make it
> > > into testing - we won't have jikes in testing and thus in stable! [0]
> > >
> > > Probably the proper fix for that would be that creation of wrappers
> > > should be only up to JVM/classpath maintainers and be done by them,
> > > probably in their JVM/classpath packages.
> >
> > Wouldn't it be better to provide the wrappers as separate jikes-on-xyz
> > packages, that would depend on both jikes and the VM/classpath package?
>
> Er...this is exactly what jikes does.
>
> mizar:[~] apt-cache show jikes-{kaffe,gij,sablevm,classpath} |grep Depends
> Depends: jikes, kaffe, java-common
> Depends: jikes, libgcj4 | libgcj3 | libgcj2, java-common
> Depends: jikes, sablevm (>=1.0.5-1), java-common
> Depends: jikes, classpath, java-common
>
> > jikes could depend on any one of the wrapper packages being installed, if
> > that's possible with debian's dependency system.
>
> Jikes doesn't need to depend on any of them because it can be used on its
> own.
>
> What you are missing is that Debian binary packages must stay in sync with
> their source package, which means that all of the packages that jikes builds
> are handled as a group for release purposes.
>
> If this is causing a problem, the obvious solution is to move the jikes-*
> packages into separate source packages to allow them to be handled
> separately from jikes itself.
thanks for quickly clearing up my mistakes!
cheers,
dalibor topic
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Ean, > > * Ean Schuessler wrote: > >The problem is that "java2-runtime-" doesn't really > >provide anything more than "j2re1.4". It is just a wordier way to refer > >to Sun and IBM's VM, neither of which can actually be distributed by > >Debian. > > The problem is, that this JVM can be installed and will often be a > better choice (apache with tomcat and full load on kaffe?). This > interface is for such a case. tomcat3 has been known to work on kaffe fine for quite a while. Tomcat4 I haven' tried recently. Jetty should work fine with kaffe 1.1.1. Why shouldn't the user determine the better choice himself? > Currently you forbit this, as you only know where the BD package put > their java and so it will break if you have sun-java packaged > (mpkg-j2sdk) and instaleld with that name. Can't the maintainers of Blackdown Java and mpkg-j2sdk resolve this naming issue among themselves? ;) > >Kaffe is actually mostly compatible with the JAVA_HOME "standard" now > >that I use symlinks for Debian compatibility. It might be worth making > >the JAVA_HOME structure part of Debian policy. GCJ and friends could > >create some simulation of it by symlinking stuff into a fake JAVA_HOME > >structure. > > I much for this, but it will need 'protection', so that this system > prevents to mistake kaffe for a sun compatible JVM-1.4. Could you elaborate on this one, as in give an example where kaffe can be mistaken for Sun's JVM 1.4 why such protection is needed? cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Ben, --- Ben Burton <[EMAIL PROTECTED]> wrote: > > > I haven't used JNI much, so it would be nice if someone who packages a JNI > > library could chip in here and provide some insight about what's necesary, > and > > how they use to find it. > > For libreadline-java: > > It builds explicitly against gcj and gcjh with the /usr/include/jni.h > provided by libgcj4-dev. This is done so the package build is > guaranteed to work out of the box regardless of a user's alternatives, > default $JAVA_HOME (which may be appropriate for their day-to-day work > but not for building libreadline-java), etc. Sounds quite reasonable to me. Pick a free VM environment that works for building the package and use that to build it. > Since it's a library, it doesn't have a startup script and so at runtime > it uses whatever JVM is running its parent app. However, it works with > kaffe (or at least will work with kaffe once the patch for #167936 is > properly applied), gij and blackdown without any additional command-line > options (beyond putting libreadline-java.jar in the classpath). This is > in part assured by the policy requirements that all JVMs search > /usr/lib/jni for JNI modules. I've seen the bug report and the patch for kaffe. Thanks for doing that, I hope Ean will apply the patch in the next release of kaffe 1.1.1 for debian, or for 1.1.2. The only issue I se with JNI is how to handle libraries/programs using JNI 1.2 vs VMs implementing only JNI 1.1. I assume that it could be handled by specifying the VMs an application will run on as explicit dependencies, and preferably doing the same for libraries. Bug reports may be filed to get the maintainers/upstream to consider implementing the missing features. That's how we got partial JNI 1.2 support in kaffe: Mark Wielaard needed it for an application using java-gnome, which needs some functions from JNI 1.2, so he wrote a patch and voila, java-gnome works on kaffe now. As an aside, I see the role of debian java packagers as providing not just the packages, but also a 'communication link' between the debian java users, their package upstream, and the free VMs. So if your package doesn't work with a free VM, get the upstreams in touch with each other, so that they can work out a way to fix it. That's currently happening between freenet, gcj and kaffe developer communities, for example. I hope the result will be a very good java.nio implementation. I think the best thing about free software, is the opportunity to collaborate freely with others to build something exciting. Debian Java packagers should be encouraged to foster the collaboration between their packages and free VMs. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
> > unfree piece of software. Neither by forcing this user to download a > > bunch of package to satisfy dependencies, which are actually satisfied > > by the unfree piece of software, nor by making him to compile software > > 'the hard way', when this software is available by the debian > > packaging system. > > I just hope that you don't punish the Debian packagers that want to just > package some things which happen to be written in the java language by > requiring them to be interoperable with some unpackaged, non-free, > proprietary stuff. But I am not a Debian developer so I cannot judge > whether or not this java-policy is an improvement to the old situation. Who knows, one day I may end up being a Debian developer instead of just being a user, and then I don't want to have to install non-free software to make sure that my packages work with it, because of a policy that mandates using non-free sowtware as the easy way to interoperability. That would be like requiring that C programs build with Borland's C/C++ compiler running on wine just because a lot of people used to use Borland's compilers on MS DOS back in the 90s ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >Why do you assume familiarity with some command line synopsis? The effect of > >-classpath a.jar:b.jar for example can have different effects depending on > the > >VM used, and its version. That's what the documentation is good for ;) > > >From my limited java experience, it will not matter. For example the > jikes delegate of the ant javac task uses only the classpath but the > javac task includes a 'bootclasspath' option. -> jikes will be called > with 'bootclaspath jars' + 'classpath'. There is always a workaround, > which will work 'good enough'. You should avoid turning whatever your 'limited java experience' makes you believe is the normal way to do things into a policy ;) The definition of what's to be expected as normal keeps changing all the time in the java world, as I'm trying to make clear with my questions on your interpretation of java's class loading semantics. > >> Just setting them all to 200 isn't any better. This priority system > >> should IMO fullfill this goals: > >> * get a newer version before the older one > >uh, that's what the debian packaging system does already, right? when > >let's say kaffe 1.1.1 is out, it replaces kaffe 1.1.0 in debian, > >doesn't it? > > Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3? Why should it? If let's say eclipse depends on sablevm or BD java >= 1.3, then an update of kaffe shouldn't have any effect on my ability to still run eclipse afterwards, so it shouldn't mess with sablevm or BD. I'd consider kaffe removing some other unrelated package from my system to be a serious bug. > >> * get a more spec complient version before any not so spec complient > >> version. > >that's the ugly part, where someone gets to be the judge who's how much > >compliant. It's not clear how you want to judge spec compliance. Could you > >elaborate on that? > > Lets say it this way: There is such a thing as a reasonable debian > developer and I think that he should be able to sort that out. Unfortunately, I still don't get it. Do you expect VM maintainers to rate the compliance of their VM packages, some third party (like yourself), or the users after they install a VM? > >> * get a free one before a unfree one. > >yay! I'm all for that ;) > > I'm even more happy seeing you happy :) O.K., you get to be the happier one ;) > >I think your priority scheme tries to solve the problem what to do when two > or > >more VMs are able to run an application. > > >From a packages POV, they wont access the priority system. Only the > unfree interface (and /usr/bin/java, but that shouldn't be accessed by > debian packages) is controled by this priorities and there only the > 'greater release gets greater prority' rule applys. > > >Let's hypothetically say the user tries to run tomcat-xyz, which is > >according to the packager able to run on both sun's VM, blackdown, > >IBM, and sablevm. The user prefers to run free VMs over unfree ones if > >any possible (not so uncommon for debian users), so his $PATH has > >sableVMs java executable before the unfree ones. Ideally, debian java > >wrapper will delegate the call to the first suitable VM package it > >finds > > Hey, thats exactly what I wanted to do with my proposal. > > Only that the three unfree ones are used via the 'unfree interface' > and that the packages may use whatever order it may find suitable. If > we find a way to factor this 'search' out into a differnt programm, it > may be able to set preferences. Great, as that's a system I could live with ;) I wouldn't let the packager decide what VMs should be tried in which order, as I want to be able to set my preferences myself (and I may not want to prefer VMs based on their perceived compliance with JDK 1.4 APIs, for example), just let the packager limit the options to the VMs that are known to work with the package. Since I expect users to have different preferences (spec compliance, performance, implementation quality, freedom of software, and a thousand of other reasons to prefer one implementaiton over the other, including prefering a particular unfree one over another), I don't like the preference rating system based on some unmeasurable compliance factor. In fact, I'd prefer a scheme where the suitable VM search is factored out to a third program which honors my $PATH as a way to express my preferences, for example. > >on the PATH which is sableVM
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > [rant about JAVA_HOME] > >I don't think that's a good foundation to build a policy on ;) > > Is the current proposal better? Much better, actually, although I still have some issues with it. But I think we're understanding each other's goals much better now, so it becomes easier to work together on the remainig issues. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> I wanted to say, that you have a interface for the 'unfree' ones and > >> this interface will work, even if you have 'not working' JVM > >> installed. The current interface (/usr/bin/java) does not garantee, > >> that your package is working. > >I don't think that an 'interface' can guarantee that a package is working > with > >a specific VM environment. Only testing by the ?ackagers and users can > >guarantee that. > > Yes. I agree with that for the 'free' alternatives. IMO the 'unfree' > ones don't need that much testing, as they can changed without a > problem. At least as far as I have experienced it. I don't have much experience using the non-free ones, so I can't really comment on that. But I'd doubt that all of the non-free VMs use exactly the same code, as there would be little benefit in having three times the same thing with a different brand name slapped across it. If they don't have the same code, then I think it contradicts the idea of debian packages working well out of the box, if the packager only assumes that a package should work with some VM, but doesn't test it prior to release, no matter if they have the same interface or not, as their internals are different. It's the difference between 'it should work' and 'it works' and my impression is that you want debian's java package to be in the second category, a goal which I fully support. A packager on some debian-linux platform without a port of non-free VMs would be misleading his users if he claimed that his package works with a non-free VM without having tested the package with the VM in question. I think the policy should encourage maintainers to be honest about the status of their packages. > >>From debian I'd expect a policy that helps and guides java apps/libs/jvm > >maintainers to build and package their stuff with a focus on free VMs, gives > >pointers who to get in topuch with if things don't work, has a section on > free > >java developers working on providing a free java infrastructure and how to > >contribute to it, and provides the necessary bits of information on how to > >deal with the legacy, proprietary VMs. Certainly not the other way round ;) > > This is not the primary goal of the policy IMO. The policy is for > describing *how* a package should look like, a kind of ruleset, which > packages have to comply to. Nothing more, nothing less. Well, the current proposal for a debian java policy contains some issues to discuss, and an advice for packagers section. I think that's a good idea, as it could help new packagers with their task. If you think it would be better to put such things into the debian java faq, fair enough. Thogh I would hope that the policy actively encourages packagers to support free VMs, in accordance with debian's free software goals. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> I much for this, but it will need 'protection', so that this system > >> prevents to mistake kaffe for a sun compatible JVM-1.4. > >Could you elaborate on this one, as in give an example where kaffe can be > >mistaken for Sun's JVM 1.4 why such protection is needed? > > /usr/bin/java -> Currently it is the default way to access java and it > can be provided by sablevm, kaffe, gcj, BD packages or mpkg-j2sdk made > packages: > > [EMAIL PROTECTED]:~/debian/RPM/SOURCES$ update-alternatives --list java > /usr/lib/j2sdk1.4/bin/java > /usr/bin/gij-wrapper-3.0 > /usr/lib/kaffe/bin/java > /usr/lib/j2se/1.4/bin/java > /usr/lib/j2se/1.3/bin/java > /usr/lib/j2sdk1.4-bd/bin/java > > As it is know to be that 'unprotected', every package sonly uses it as > a fallback after consulting JAVA_HOME. I still don't see the harm by kaffe providing a java wrapper script. But what about /usr/bin/java not being provided by the VM packages, and just being a wrapper script that delegates the call to a working, installed VM as I proposed in another mail? cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
as handled by the normal debian policy. > >> This is the debian *Java* policy. > >Then what precisely is the goal of the *Java* policy? > > To deal with java apps/libs, which comes precompiled into java byte > code. What about apps/libs, that are part compiled bytecode, part something else? Think about jython applications, for example. > >They should get the upstreeam sources in that case and > >hack on those. > > I'm not going to punish someone, because he has a requrement for a > unfree piece of software. Neither by forcing this user to download a > bunch of package to satisfy dependencies, which are actually satisfied > by the unfree piece of software, nor by making him to compile software > 'the hard way', when this software is available by the debian > packaging system. How do you want to provide the unfree VMs if you don't force the user to download a bunch of packages? Should they be linked into the kernel? ;) I don't see what is so hard about installing kaffe, or sable VM, or whatever other free VM to build a package if the maintainer says that the build will work with it. there is nothing hard about it, if it's in the requirements to build the thing. The 'hard way' is to make the maintainer also work out a way to build the package with non-free VMs using the 'non-free interface' in addition to a sane way to build the package with free VMs. the same argument could be also waged against all packages using ant to build: they could equally well use make, but they instead chose to make life hard for make users to build the software by not providing makefiles. Let's file bug reports till we all feel better about it, yay ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
Hi Mark, --- Mark Wielaard <[EMAIL PROTECTED]> wrote: > > > [..] ANT_BUILD_COMPILER with the short-name or the full qualified > > classname of the java compiler [..] > > > > Also, for the default environemt, it needs to include the tools.jar. > > Yuck. What does this tools.jar provide? nothing in the API spec. Some badly written packages use it to access internal classes of Sun's implementation, even though Sun tells them not to. And then the cry goes to free VMs to support such braindead code, since everyone (i.e. ant) is doing it. ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JAVA_HOME and ant
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > >> Yes, but to make this policy os do something else is IMO not possible. > >> Especially, if we have to consider, that ant should behave 'normaly', > >> when used to develop java apps in, for example, eclipse. > >How do you define normally? > > Just as it is now. so the status quo, with ant having what we agreed upon to be some very badly designed code, barely working with free tols, is to be considered normal? What will happen when someone on the ant developer team sees the light and refactors their javadoc task to use delegation as well, will you change your definiton of normal accordingly, or will the improved ant somehow violate the 'normality of now'? ;) > >If Ant can only work correctly with non-free programs or VMs then it > >isn't really useful for main is it? > > IMO, it isn't fit for main yet: the javadoc task won't work if kaffe > doesn't link a bin/javadoc into java.home. Thats at least how I read > the code. Stefan, have you tried that? kaffe doesn't come with a real javadoc tool yet. I'll merge in gjdoc for kaffe 1.1.2. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JAVA_HOME and ant
Hi Mark, --- Mark Wielaard <[EMAIL PROTECTED]> wrote: > > > >> * Javah relies on a special sun.com...javah.Main class. Doesn't matter.. > > >gcj comes with gcjh which should be able to do everything javah does > > >(given the -jni flag). > > > > But as it is now, it won't be useable form ant. Or does gij include > > the sunjavah.Main class? > > No. It is a normal program written in C. > In principle gcj doesn't implement undocumented classes. I second that. It's impossible for a free VM to implement the undocumented classes, because, well, they are undocumented and are not part of the API. ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > * unfree interfaces are now 'additional to' the normal (free) debian > packages, which provide a certain functionality good. > * java compilers are now use via ant, via an 'ant environment' or must > be referenced directly (i.e. you need to Build-Depends: on jikes > and not on java2-compiler) better. > * interfaces to unfree VM and ant environments are now named "unfree", > at least in the policy. still problematic to assume that sun-derived VMs are the only unfree VMs around. someone could equally well write their own unfree licensed VM from scratch, and want to package it for debian. despite being unfree, it wouldn't necessarily have the same interface as sun-dervied VMs. > * Packages should use a java.home like dir structure, for ants sake > (see my other posting about how ant handles javadoc and java tasks) let's try to get the upstream to fix ant first, before we make cement their mistakes into a policy. > * droped BOOTCLASSPATH and PROPERTIES great! > * added a chapter on 'building java package', which should make > 'testing' with new VM easier. nice. > * deleted stuff, which seems "out of date" like the 'open questions', > which are handled in the java FAQ. good. > 2.1. Java virtual machines and runtime environments > > Java virtual maschines and java runtimes environments are tightly > linked, so it makes no sense to seperate them. Therefore only the java > runtime environment is used to describe the command java. > > As it is nearly impossible to treat all java virtual maschines the > same, JVMs are seperated into two kinds: sun compatible and not. > Packages should access sun compatible java virtual maschiens via the > described "unfree" interfaces below. I think sun-derived, or JDK-derived is a better term, than sun-compatible. A VM can be derived from Sun's sources without being compatible with the interfaces you propose. > 2.1.2. bin/java "unfree" interface [snip] > Priorities should be set as follows: highest spec/API version > multiplied with 100 (1.4 -> 140), free VM may add 30 points, for > incomplete spec/API compatibility subtract 40. Revisions may add 1 > point, as appropiate. Uh, either the priorities system is poart of the unfree interface, then free VMs don't care about it, and there is no need to mention them in the description, or it's not, but then it's not clear what it's doing in this section. > 2.2.1. Ant Environment > > Packages, which can be used with ant to compile java code must setup > a directory structure in /usr/lib/name (where name is the name of > the corresponding virtual maschine (see above)), which includes > bin/javadoc, which should be of the same API version as the virtual > maschine, includes and includes/linux, with the JNI header files. what is includes/linux good for? what files are expected there and what are they used for? > 2.6. Java programs > > Programs must depend on the needed runtime environments, including > working versions if the bin/java unfree interfaces. bzzt! ;) this 'let's make free software in debian depend on non-free software' proposal is incompatible with debian's goal, afaik. turn that into a 'may depend on the unfree interfaces ' and I'll be happier with it. In other news, I think the ant proposal is not that bad, I only hope we can get rid of the JAVA_HOME stuff and get ant developers to fix their design issues. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >The definition of what's to be expected as normal keeps changing all the > time > >in the java world, as I'm trying to make clear with my questions on your > >interpretation of java's class loading semantics. > > >From your point, but not from the guy starting a java app... You're using a straw man argument here. Things really keep changing all the time *and* it matters, even for the normal guy starting a java app. Look here for example at the apache ant announcement for ant 1.5.4 (latest ant) here http://marc.theaimsgroup.com/?l=apache-announce&m=106077068513961&w=2 . They had to fix the javah task because sun changed something about their internal classes in java 1.4.2. So what's your normal ant-running guy to do in this case? Moan about Sun changing internals of their implementation and demand that the debian maintainer reverts the change so that ant 1.5.3 from testing still works? > >> Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3? > >Why should it? > > You should have a look at the alternative system on debian maschines. > > Currently /usr/bin/java is managed via this alternative system. So the > package, which supplys the highes priority wins and gets > '/usr/bin/java'. If sablevm and kaffe are installed and I depend on > kaffe, but sablevm installs a higher priority, then I'm fd up. I think we both agree that this scheme is not a good solution for java on debian. It doesn't give users the necessary flexibilty to deal with ever changing definition of what should be considered as normal in java. For example I can't really make sure that I run ant 1.5.3 with Sun's JDK 1.4.1 because I need the javah task to work, but nevertheless want to run other apps with JDK 1.4.2 as far as I understand the priority game. > >I'd consider kaffe removing some other unrelated package from my > >system to be a serious bug. > > It has nothing to do with the packaging system, but with alternatives. > man update-alternatives update-alternatives is useless for non-root users. See for example this session: [see if update/alternaitves is installed and its synopsis] bash-2.05a$ update-alternatives update-alternatives: need --display, --config, --install, --remove or --auto Debian update-alternatives 1.9.21. Copyright (C) 1995 Ian Jackson. Copyright (C) 2000,2001,2002 Wichert Akkerman This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. Usage: update-alternatives --install [--slave ] ... update-alternatives --remove update-alternatives --auto update-alternatives --display update-alternatives --config is the name in /etc/alternatives. is the name referred to. is the link pointing to /etc/alternatives/. is an integer; options with higher numbers are chosen. Options: --verbose|--quiet --test --help --version --altdir --admindir [display alternatives for java] bash-2.05a$ update-alternatives --display java java - status is auto. link currently points to /usr/lib/j2se/1.3/bin/java /usr/lib/jdk1.1/bin/java - priority 111 slave java.1.gz: /usr/share/man/man1/java-jdk11.1.gz /usr/lib/kaffe/bin/java - priority 300 slave java.1.gz: /usr/share/man/man1/kaffe.1.gz /usr/bin/gij-wrapper-3.2 - priority 32 slave java.1.gz: /usr/share/man/man1/gij-wrapper-3.2.1.gz /usr/lib/j2se/1.3/bin/java - priority 1311 slave java.1.gz: /usr/share/man/man1/java.j2se13.1.gz Current `best' version is /usr/lib/j2se/1.3/bin/java. [i prefer free software, so let's pick kaffe] bash-2.05a$ update-alternatives --config java There are 4 programs which provide `java'. SelectionCommand --- 1/usr/lib/jdk1.1/bin/java 2/usr/lib/kaffe/bin/java 3/usr/bin/gij-wrapper-3.2 *+4/usr/lib/j2se/1.3/bin/java Enter to keep the default[*], or type selection number: 2 Using `/usr/lib/kaffe/bin/java' to provide `java'. update-alternatives: unable to make /etc/alternatives/java.dpkg-tmp a symlink to /usr/lib/kaffe/bin/java: Permission denied hooray for update-alternatives being helpful ;) > >> Lets say it this way: There is such a thing as a reasonable debian > >> developer and I think that he should be able to sort that out. > >Unfortunately, I still don't get it. Do you expect VM maintainers to > >rate the compliance of their VM packages, some third party (like > >yourself), or the users after they install a VM? > > Actually I don't mind at all, what the free VM package use as a > priority. What I mind are the unfree ones for teh alternative
Re: [PROPOSAL] 3. RfD on new debian java policy
ne of
> the 'unfree interface' versions. If we get that for free, I don't se
> ethe point in denying this fact to the user.
If a maintainer doesn't want to get his hands dirty by installing a prorpietary
VM (for example because he doesn't want to give Sun and their business parties
to snoop his computer as they wish, as in this section of Sun's Java 1.4.2_01
license:
SOFTWARE FROM SOURCES OTHER THAN SUN. You acknowledge that, by your use of
optional features of the Software and/or by requesting services that require
use of the optional features of the Software, the Software may automatically
download, install, and execute software applications from sources other than
Sun ("Other Software"). Sun makes no representations of a relationship of any
kind to licensors of Other Software. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO
EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA,
OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES,
HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED
TO THE USE OF OR INABILITY TO USE OTHER SOFTWARE, EVEN IF SUN HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. Some states do not allow the exclusion of
incidental or consequential damages, so some of the terms above may not be
applicable to you.
) then you propose that he should tell his users that the software will work
with some non-free VM without being able to test it. I think that's dubious
practice, really, and if I was a debian package maintainer, I wouldn't like to
be forced by a policy to make claims that I can't verify.
> I think removing them completely would be the best, but I think that
> too many people will complain if the don't have a 'java/javac' in
> their path.
give them shell scripts that print a message like
Dear User,
you surely expect to find a java(c) executable, that does something meaningful,
for whatever you consider to be meaningful. We've tried to come up with a good
idea about what you may consider to be meaningful, but our mind-reading
abilities are underdeveloped for this task and the definition of meaningful
seems to be different for everybody involved. So in order to get a working java
environment, you have the luxory of choice to pick one of these fine free
environments to do your java work in and install it:
* a
* b
* c
If you chose to use a non-free java VM, consult the debian non-free java faq
available here: some URL.
best regards,
the debian java policy makers
> [ant and javadoc]
> >> Please also note, that I currently don't have this 'some afternoons'.
> >Fair enough. But these are things that should be discussed with upstream
> >to make Ant usable on a Debian system.
>
> I've seen tora in some comments of the javac delegates. Maybe he has
> some contacts to upstream.
How about submitting a bug report?
> >> Run every program as good as the unfree ones?
> >Every program :) Maybe we could start with a subset of that.
>
> For debian package dependencies, it needs to be 'every'... IMO
That's still a silly definition. Run every java program in debian, o.k. that
something we can work with. Run *every possible* java program is pointless as
no free or non-free VM can do it.
> [full load server with kaffe/gcj tomcat]
> >Yes, why not? Maybe Dalibor has an example of kaffe.org which I
> >believe runs Jetty on kaffe.
>
> Lets give this example: I develop webapps. Until now they were able to
> run on kaffe/gij/gcj. Now I want to have some pictures put into the
> pages and I will use Image to get the size (yes, I know that tehre are
> better ways and that this is too slow). I deploy this. Crash. I will
> search the net for 'Image tomcat linux' I will get a lot of results,
> which points to 'headless mode' for awt available in 1.4. I put the
> right things into the tomcat startscript. Crash again.
>
> And this is only tomcat with some small webapp.
I've never seen a bug report from you on the kaffe mailing list, sorry. I'd be
very interested in having someone (and you as the debian packager would be
ideal) help us get eclipse to run better on free VMs, be it kaffe or gij. If
you have problems with eclipse on kaffe, tell us more about it on the kaffe
mailing list, and we'll try to fix the things for 1.1.2.
> >But if they are packaged for Debian cann't you just backport the build
> >tools also?
>
> Yes, but why should I if I have a full sun J2SDK installed already?
Why does that matter? I have a car already, why don't they build a highway to
my house? ;)
> Just for the sake of downloading 10+ MB again?
It will hardly matter compared with the download sizes of the non-free VMs,
will it? ;)
> >I do expect Debian to have a packaging system that won't give me
> >headaches. And I know that is does have that.
>
> Yes, because tomcat and eclipse build-depend on BD java.
which is fine, if they need that to build.
If I want to rebuild tomcat, then I'll better download BD java since that's
what's been used to build the thing, and it actually worked. If I'm feeling
lucky, I'd try to build it on Sun's VM or IBM's or gij, but I don't see the
need to bother the maintainer with caring about the other VMs if he's already
stated his build dependencies.
cheers,
dalibor topic
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
you to collaborate with the maintainers to make sure their packages build on the single particular VM environment you decided to pick for yourself and to aid them in providing support for it. It shouldn't be the other way round, in my opinion. Maintainers shouldn't have to support every random VM someone downloads off the net, just because that's the one the particular user is stuck with. They should support the VMs that work with their packages. I mean, I like kaffe, for example, but I don't demand that debian makes a policy that requires all java package maintainers to support my favorite VM. If I care about running a particular application of kaffe, I don't see a problem in getting in touch with the maintainer, and helping him support kaffe (better). In fact, I've been doing this for more than a year, though I prefer to work with the upstream, where the actual decisions are made ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
--- Ben Burton <[EMAIL PROTECTED]> wrote: > > > >I'm quite happy with this suggestion as well (must -> may for non-free > > >JVM dependencies). If at least one of the dependencies is satisfied > > >- even if this is selected from a list of only free JVMs - then the > > >app will presumably run successfully and so there's no problem if > > >non-free JVMs are omitted from this dependency list. > > > > Sorry, I'm not doing this. If a package can be used with unfree VM, > > then this package 'should' also include this VM in the search path. > > > > If you talk about the 'choice of the user', then there should also be > > a choice to run on a unfree VM. Debian is not about *forcing* the user > > to use free software. > > Nobody's forcing the user to do anything. I'm presuming that the app > startup scripts will allow a user to specify their own JVM with which to > run an app (and I wouldn't mind putting *that* requirement in policy). > > By doing this, users can run an app under whatever JVM they like. It's > just a matter of the dependency system requiring them to install one of > the "officially supported" JVMs, whether or not they choose to use it in > the end. > > I honestly do not think you're going to be able to force package > maintainers to install non-free software on their systems for testing > their DFSG-free apps. Some of these non-free packages have > eyebrow-raising clauses in their licenses, and I won't blame some > maintainers for refusing to test with them. And I don't think a policy should force maintainers to claim their packages will work with some non-free software without being able to test it. It goes against Jan's goal of improving the quality of java experience in debian if the maintainers are forced to claim their packages run on something they can't test. I think it's a matter of who you want to force to do what: Jan's proposal forces maintainers to either install non-free software to test their packages with it or make dishonest claims about the java environments their package can run on in order to support users who want to run the packages on non-free software. We agree that some people may want to do that. He wants to make a requirement that packagers support those people, I don't. My proposal, to explicitely depend on the VMs that the maintainer can honestly say the package runs on, forces the user to download one of the environments that the maintainer says the software will run on, if none such environment is installed. This goes a long way to make sure the user doesn't experience problems running the software. It does not prohibit the maintainer from also depending on non-free VMs if he wants to, but it doesn't force him either. The missing link is some magical 'byte code runtime lookup' script, that allows the user some flexibility in the choice of runtimes supported by the maintainer, but doesn't prevent him/her from trying to run the software with another, not officially supported by the maintainer, runtime if he wishes so. The maintainer should not be required to support all java runtimes in debian, but encouraged by the policy to test his package on as many runtimes as possible, with a priority on the free ones, as the user is more likely to have those installed on his system (they are either part of main, or will enter it after testing, after all). That's where Jan's and my ideas again are not very far apart: he already tried to specify something similar in his ant environment proposal, to provide some flexibility for java runtimes capable of runing ant. Philosophical differences aside, I don't think we are that far apart from each other. I believe the discussion on debian-java has been quite fruitful so far in exposing some weaknesses of the proposals and paving the road to improvements (and Jan has done a great job on improving the policy proposal when the arguments from the other side were convincing enough for him). As I said before, it may take a little bit longer, but I think it's worth it. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JAVA_HOME and ant
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > Ok, I'm also good at philosophical nitpicking :) Great! :) > * Dalibor Topic wrote: > >--- Jan Schulz <[EMAIL PROTECTED]> wrote: > >> > [...working ant...]How do you define normally? > >> Just as it is now. > >so the status quo, with ant having what we agreed upon to be some very badly > >designed code, barely working with free tols, is to be considered normal? > > If you tell me, that this code will change within this year, then I > will happily wait until that has happen. If not, I think that this > proposal could easily be addpated to a 'new reality', which would look > much like the bits about 'build.compiler'. I think the code in question (javadoc task) is going to be rewritten to use a delegation model soon anyway, as there is some demand to be able to run different javadocs with it. See http://marc.theaimsgroup.com/?l=ant-user&m=106276172400587&w=2 . I can try to make a push for a more flexible ant javadoc task, if that would help. > >> IMO, it isn't fit for main yet: the javadoc task won't work if kaffe > >> doesn't link a bin/javadoc into java.home. Thats at least how I read > >> the code. Stefan, have you tried that? > >kaffe doesn't come with a real javadoc tool yet. I'll merge in gjdoc > >for kaffe 1.1.2. > > Thanks for doing that! Not done yet, I hope to be able to tackle it over the weekend. But thanks for the encouragement :) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on > >> kaffe, but sablevm installs a higher priority, then I'm fd up. > >I think we both agree that this scheme is not a good solution for java > >on debian. It doesn't give users the necessary flexibilty to deal with > >ever changing definition of what should be considered as normal in > >java. For example I can't really make sure that I run ant 1.5.3 with > >Sun's JDK 1.4.1 because I need the javah task to work, but > > You can never make this sure beforehand. This are bugs, which show up > and you simple get the fix and be done with it. Don't you see that your interface definition attempt is contradicted by this? It is not flexible enough to deal with such cases, because it assumes there will be no compatibility problems between different point releases of a particual java API release, like java 1.4.1 and 1.4.2. That is simply not true, and calling it bugs, and referring to getting a fix, fails to realize that there is a compatibility problem, not just a bug. If ant relies on internal classes from Sun (and we both know it does) it can break with every small change Sun makes to their internals, and there is no way to guarantee that won't happen, whether you define an interface or not, because it circumvents the interface. > IMO you can't make java save *in all cases*, as long as you don't > depend on one specific version of one JVM. But then we have just > 'removed' the main thing why java was created. But don't you see that that's already the case with any application that messes with internals of Sun's implementation? Such applications are tied to a specific VM implementation and version by design, and will keep breaking with new releases from Sun. Your idea that Sun doesn't break things with minor upgrades of their VM is wrong. Codifying it as a debian policy won't make it true, as Sun doesn't care about Debian. > >> It has nothing to do with the packaging system, but with alternatives. > >> man update-alternatives > >update-alternatives is useless for non-root users. See for example this > >session: > [non root session] > >hooray for update-alternatives being helpful ;) > > Thats why only the unfree interface is maintained with it. For the > rest, you are very welcome to write your implementaion of > 'findworkingjava', which will accept a per user configuration file. If we agree that having such a mechanism is a good thing, then it would be nice to have a common understanding of what we want, what we need and how we get there. I guess we shall start a new thread for this issue, if you think it makes sense to have it in a new policy. > >> If this is such aproblem, then I will change my proposal to only > >> specify the unfree interface priorities (basicly: release x 100). > >Stupid question: what's a release? What priority value should be given > >to J2SE v 1.4.2_01 ? 142? 142.01? 14201? > > major.minor.release.build > (majorx1000)+(minorx100)+(releasex10)+build > > Happier? Yes, thanks, since it's a much clearer specification. The clearer your policy proposal gets, the easier it will be to apply by packagers. > >I think that such an app would help solve the current problems with > >picking the 'right' java executable for the job in a more general > >fashion than what we have now (weird and useless /usr/bin/java > >interface with even weirder alternatives scheme) or your proposal, > >which seems to try to band-aid debian to limp along with the non-free > >VMs by introducing a non-free interface with another weird rating > >system. > > Note that this programm still has to sort out, what 'java' is *able* to > run it. The app may add some classpath jars as well, depending on > which java is used. I don'T think that could be done with a > /usr/bin/java, which uses then one other 'java' to run the app. I'm not talking about an "command line options emulation interface" here (like your original interface proposal), just about a way to delegate the call as it is made to the java executable to another java executable given some knowledge about which java executables work with the program, and a set of user preferences. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > [kdelibs4 problems] > >> all cases to '1', but the latest qt version in unstable is '2'. I don't > >> think that anyone bothers to test their packages, when one of the > >> dependencies changed. > >Whoever changed the dependency should have tested the packages that depend > on > >it, in my opinion. > > Noone changed anything. The only change was, that there is now a new > qt lib in unstable, which wasn't there during the last build of > kdelibs4. > > Should the qt maintainer compile every kde app when he uploaded a new > version? The kde maintainer, when any of his dependencies has changed? In my opinion, the debian build deamon should get a twin quality assurance deamon brother that should try to build the depending packages with the successfully built new version, and run their regression tests (make check). Then the maintainer should be notified about the problems, and he couild decide whether to revoke the package, or to let it pass and fix the problems later. Let the machines do what they are best at: monotonous tasks like this ;) > >> What I say is, that you can assume, that if you compile your java > >> package to java byte code (version ...), then a 'sun derived' VM will > >> run it. I consider that save enough and a lot of better than the > >> current practise. > >There are examples available that clearly show that this assumption is not > >valid. > > May I hear them? The ant javah exaple from the last mail shows that any application that depends on the unpublished, undocumented internals of sun's implementation is bound to fail on another version of a sun derived VM than the one it was developed with. Here's some more documentation on documented binary and source incompatibilities between different releases of Sun derived VMs: http://java.sun.com/j2se/1.4.2/compatibility.html Please note that the incompatibilities between minor releases are actually summed up between differnt point-releases, where they used to exist just like with 1.4. So all the differences between 1.3.0 and 1.3.1 are actually meshed together in the web pages. Sun never documents their changes in their internal classes, so all apps depeding on it are, and will be broken by upgrades. Sun's licensees, like IBM and BD, can also make undocumented changes to those classes. Convinced? > >> So you find it acceptable, if one has 5 java packages, which need 5 > >> different JVM, *althought* one of this JVM will run all 5 packages? > >Of course. > > Then you have missed the point with java... You're blaming me for trying to cure other people's mistakes here. It's the developers who use undocumented features of Sun's implementation (like JAVA_HOME, sun.* classes and so on) that miss the point with java: they tie their code to one particular instance of a non-free JVM. If their code runs at all on another release of a non-free VM, then it does so by pure luck. I propose to explicitely state which VMs are known to run the code, since I don't want to assume anything about untested VMs. You assume that other VMs derived from the same code base will continue to run the code. I don't think that's a valid assumption to make, given a) the amount of non-portable java code out there, and b) binary incompatibilities between point-releases in Sun's own VMs. > >I may want to run one package on one VM, the other one on another, > >because it performs better on it, for example. What's wrong with picking the > >right tool for the job? What's wrong with having a choice? > > Nothing is wrong with that. I'm only wondering, why you want to > prevent that the users has this choice... If I have the knowledge what > JVM works best with my app, then I will also have no problem with > downlaoding this packages, *if* I need them. In all other cases, I > think that 'it is able to run it' will be enough. I think I wasn't clear enough, I'm sorry about that. I don't want to prevent users to have a choice, as I'm a user myself, and I showed in my update-alternatives example that I want to have some flexibililty myself, that current debian java support doesn't offer me. You seem to fail to realize that we are arguing pro very similar things: I say list all the VMs that the maintainer knows will run the package in the dependencies, and give the user some means to pick whatever he needs, but make sure that he has a one of the possible very many supported VM installed to run his program on. So for my cool HelloWorld application debian package, I'd list all VMs in debian after testing they can run my HelloWo
Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> I don't do it. I just see the need, that some people will want to run > >> java apps on a unfree VM. This propsal makes this possible. > >But it is already possible, isn't it? > > Yes, because the curent proposal makes nor difference between free and > unfree ones. If you will drop the unfree interface, it will not > anymore possible without hacking the /usr/bin/name startscripts. My proposal to have the maintainer depend his package on all the VMs that he knows will work with his package makes no difference between free or non-free either. Just between 'works' and 'who knows'. > >further than that, it's about making sure that java apps run on > >non-free VMs, it's about requiring these apps to suuport the legacy, > >non-free VMs. > > Its about supporting a interface to this 'sun derived' JVMs. Without > this interface a user has to hack the apps itself to make this > possible. This will result in "some" users to download the source and > compile themself *outside* of the debian packageing system. So for > this users, we could also stop packaging java apps. I regularly download and build the sources outside debian's packaging system. The horror! Please everyone stop packaging java apps, your work is useless for me ;) > I will not propose any changes, which will not include a possibility > to use unfree VM without hacking startscripts or doing workarounds > like using a package outside of the packaging system or reordering > symlinks. Which is not that different from what I'm saying, really. I just don't feel that non-free VMs should have to receive some special care by the maintainers. If the maintainer wants to support non-free VMs, I don't want to prevent him. But to force him to provide support for them, would be wrong and force maintainers to run non-free software. I don't think anyone wants that. A better way in my opinion is to allow the user to 'override' maintainer's choice of VM environment in some easy way (like putting another java executable in front of his path, or running a selectmyvm script). > >difference between pretending that a package 'just works' because a > >readme says so, and actually testing the package and honestly telling > >the users that the package really works with some VM, since the > >packager has tested it. > > I would like to do that. Unfortunatelly java isn't perl, where tehre > is only *one* interpreter. We have to deal with severyl interpreters > and I'm not going to see, why we have to force our users to use a free > one. But noone is forcing them ... if the package only runs on a non-free VM, the maintainer can not force the user to run it on a free one, can he? If it runs on the free and non-free ones, then a maintainer, who doesn't mind dubious non-free licenses, will mark the package to depend on both the free and non-free VMs that he knows the package will run with. > >> Most java apps are designe for this unfree VMs. If a app 'wants' a > >'Most'? 'Designed for unfree VMs'? A quick google.de search on 'designed for > >JVM' shows no applications claiming that in the first 40 hits. I'd expect > >better results if what you're claiming was true. > > Someone told the story about ant and free tools. Eclipse is tested ant is not portable between java environments, as it uses sun's internal classes. eclipse uses unspecified JAVA_HOME, and is therefore not-portable between java environments, free or non-free. If the maintainer (i.e. you) says it will work with some VM, because he tested it, then if I want to run eclipse and agree with that VMs license, I'll download that VM. > *only* on IBM and sun. AFAIR, in the german java newsgroup noone tests > their software on a free alternative. My experience from the kaffe, gcj and classpath mailing lists is of course different. there everyone tests their code with free VMs, and many people don't touch non-free VMs. > >> [ant and javadoc] > >> I've seen tora in some comments of the javac delegates. Maybe he has > >> some contacts to upstream. > >How about submitting a bug report? > > I can't do everything. Then I'll submit one. You make sure the policy turns out well ;) > >> Just for the sake of downloading 10+ MB again? > >It will hardly matter compared with the download sizes of the non-free VMs, > >will it? ;) > > Yes, but what if I have a VM installed, which will work with every > app, which I will throw it it and then I need kaffe because of > java_ap
Re: Compiling java debian packages with free tools
--- Mark Howard <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2003 at 10:33:39PM +0200, John Leuner wrote: > > I feel that despite whatever decisions we make about free and non-free > > VMs and tools etc, we should firstly pay attention to simply compiling > > our software with free tools and against free libraries or free APIs. > Doesn't this happen already? Please give examples. If it can be compiled > with free software but isn't, what severity bug should we file? Should > poilcy say that free compilers must be used if they can? I'd say yes, but as a free java environment developer, I'm biased ;) Though I don't think it should be a severe bug preventing a package from entering testing. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
Salut Daniel, --- Daniel Bonniot <[EMAIL PROTECTED]> wrote: > Isn't it fine if another person testifies that the package works with > this-or-that JVM? I suppose this already happens with specific > architectures or hardware. > So if a package works with a JVM not in its depends, one can file a > (wishlist?) bug againt it. > > Maybe the policy could say "A package must (should?) depend on the > disjunction of all JVMs with which it has been tested succesfully". That > does not force the packager to use any non-free program, but gives > strength to bug reports to include another VM. I think that's a good compromise. I'd make it a 'must', though, for quality assurance reasons. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JAVA_HOME and ant
Konichiwa Takashi, --- Takashi Okamoto <[EMAIL PROTECTED]> wrote: > From: Dalibor Topic <[EMAIL PROTECTED]> > Subject: Re: JAVA_HOME and ant > Date: Tue, 9 Sep 2003 08:50:57 -0700 (PDT) > > I think the code in question (javadoc task) is going to be rewritten to use > a > > delegation model soon anyway, as there is some demand to be able to run > > different javadocs with it. See > > http://marc.theaimsgroup.com/?l=ant-user&m=106276172400587&w=2 . I can try > to > > make a push for a more flexible ant javadoc task, if that would help. > > Does anybody work for already? > > I had a same problem at rmic task. When I tried to work ant with kaffe > two yeas ago, I refactored rmic task. I may help this. That would be great! I'm not aware of anyone working on it at the moment, but you may want to get in touch with the authors[1] of the javadoc task, and the person who proposed it (David), or just file a bug against it in ant's bug database and announce that you're going to fix it yourself. cheers, dalibor topic [1] * @author Jon S. Stevens mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] * @author Stefano Mazzocchi * mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] * @author Patrick Chanezon * mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] * @author Ernst de Haan mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] * @author Stefan Bodewig __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > First of all, I will apologise for some of my heated 'answer round' > during the last days. I still can't aggre completly with your (and > others) objections, but I see that nothing won't change your opinion > either :) so I try to find a *working* compromise. Thanks a lot for keeping the discussion constructive. With the weather going colder again in Germany, I am not going to complain about a little heat here and there ;) > I'm currently learning for a exam, so don't expect some bigger 'answer > round' or a updated proposal during the next two days. I'll be back on > friday evening or the weekend... Good luck for your exam, I'm looking forward for a new round of discussion next week. > * Dalibor Topic wrote: > >Great, then if you've tested it you can make your package depend on IBM's > java > >and Sun;s java as well and make the lifes of those users who prefer to use > >IBM's or Sun's java easier. Where is the problem? > > The problem is, that IBM Java isn't packaged and so you can't > 'Depends:' or 'Conflicts:' on it. Thats why I wanted the virtual > packages, so that this is specified as the 'name to use' > > As I see, that you (you as in 'you and others' :) won't accept a > virtual package for *all* the 'sun derived' JVM, I try a different > approach: Give IBM, BD and SUN '*-bin' downloads a specific name. This > could be done by asking the mpkg-j2sdk author to make the package > names vendor specific and something more official (a.k.a "somwhere > wriiten down" and "not chnaging ever other build"). Maybe it would > even be possible to include it more tightly with java-common. I think that's a very good idea, as it clarifies what VMs are installed on a system. > This will mean, that 'java*-runtime', 'java-virtual-machine', > java*-compiler will become completly useless, as all package would > 'Depends:' on the tested packages and not on the unspecific 'virtual > package'. Great! > I will also try to implement a prototype of the 'findjava' skript. Yes, please do! > Usage as follows: > > * will 'echo' the full name to a 'java binary' pluss some VM args, so > should be used like > |JAVCMD=`findjava ` > This will give you the posebility to react to this choice (like > adding some jar to the CP or giving VM specific switches). The VM > args will be specified by the user or by the packager and will > include mostly things to tune some internal behaviour (IBM java and > eclipse is better with some JIT specific switches) > * will be include a list of packagenames (much like > 'java-config''), which are tested and found able to run the package. > * findjava will return the 'java binary' and the options based on: > o 'force overwrite' option of the user > o one of the specified java binaries (specified by package name), > based on: > . User specified preferences, if the users preference is include > in the list. > . some other preferneces given by other options > . order of the list. > o exit 1 in case no 'java binary' can be found > * other options as I find some use for them, like --server or --client > VM, which will automagically choose a 'able' VM before a 'unable' > and includes this args for the VM, if 'able'. > Any others? I don't know how much of the VM options can be safely specified in such an interface. I guess the easiest way is to add a switch -J that passes the option to the VM without specifying anything about the options the VM understands. > This all will mean that some parts of the current proposal will be > still almost the same: > > * the 'ant environment' specification is still intact, only the > 'unfree interface' will be split into more packages, one for each > 'unfree VM'. I hope this will be possible to with mpkg-j2sdk. I only > would like to include the bootclasspath here, as it would make the > 'jikes-something' adapter unessesary. I don't think requiring in the ant environment bootclasspath is desirable, as it requires a java 1.3+ VM, and a lot of code that uses ant to build can build on a lower VM and doesn't need to mess with the bootclasspath. I'd prefer to treat eclipse as an exception, not as a rule in this case ;) > So, now my only question is still: what will be the agreed upon > reaction to me filling bugs about 'include ibm-
Re: [PROPOSAL] 3. RfD on new debian java policy
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >I don't think you could force a maintainer to include a VM in his
> >package list, as you can't force packagers to trust people ('so it
> >works, eh? did you run the regression tests? can I have the result
> >files?'), but the policy should encourage the packagers to work with
> >their users and the upstream to provide support for as many VM
> >enviroments as possible, through relying on co-maintainers, and
> >knowledgeable users to handle those VM environments they have no
> >access to.
>
> I will include the wording of one of the other mails, which goes in
> this direction. A maintainer has to include all 'tested and working
> VM', but more or less its the maintainers descision to choose what
> 'tested enough' means.
>
> It will mean that Ic an file bugreports about this, so I'm happy :)
I told you we'd work out a compromise that makes us botrh happy ;)
> >Of course, this depends how strictly defined the
> >co-maintainer status is, i.e. can you be a co-maintainer/test dude
> >without being a debian developer?
>
> Yes, of course. I'm not a DD and I maintaine eclipse through Takshi
> Okamoto, who sponsors me until I'm finished with my NM application.
> Only a DD can upload packages to teh debian archiv, so this must be
> either done via one of the maintainer or by a sponsor.
Good luck for that.
> Jan, fed up with learning and having a break :)
And for the exam, too.
cheers,
dalibor topic
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 4. RfD for a new debian java policy
Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > I would like to include somewhere teh naming and way to include > 'unfree' JVM, but I haven't found a proper place. I would like to make > that a little more specific, so that we only use one way to access > them (otehrwise there will be some people, who alien a rpm). Any > suggestions welcome. I do not quite understand: do you simply want to list the VMs available in debian at the time of writing, and include references to non-free VMs not in debian? You can put it in the 'Advice to packagers' section, as in 'these are the java environments in debian, please test your packages with the free ones, and work with the upstream to get them to run on as many as possible. some users will want to use the non-free ones nevertheless, you can work with them on getting your package to run on the non-free VMs. Note that you don't have to touch non-free VMs yourself, you can delegate that task to users who don't mind being bound by freedom-restricting licenses' > The proposal: > --8<-:- snip -:-8<-:- snip -:-8<-- > > Debian policy for Java > > Ola Lundqvist > > Stephane Bortzmeyer Your name is missing here. You rewrote the whole thing, you should take the responsibility ;) > 2.1. Java virtual machines and runtime environments > >As we can't make sure, that a java programm or library will >run with all available java virtual machines all java virtual >machine are treated seperatly. There should be a sentence explaining why this is the case, as the common java marketing 'wisdom' is 'write once, debug everywhere', so if you don't want to get frivolous bug reports of the 'but it's java, it runs everywhere!' you should explain why debian developers prefer to be honest instead of relying on third party claims about compatibility. ;) > 2.2.1. Ant Environment > >Packages, which can be used with ant to compile java code must >setup a directory structure in /usr/lib/name (where name is >the name of the corresponding java virtual machine (see >above)), which includes bin/javadoc, which should be of the >same API version as the virtual maschine, includes and >includes/linux, with the JNI header files. What is in includes/linux? Is there anything that's part of the JNI spec? If not, then it shouldn't be required. >They also must include a java-config file (see below) which >includes the variable declaration for JAVA_HOME, which points >to /usr/lib/name, ANT_BUILD_COMPILER with the short name or >full qualified classname of the java compiler, >ANT_BOOTCLASSPATH, which is a JARS-like list of the >bootclasspath jars and the JARS entry, with the jars needed to >run this java compiler. You could give an example here for jikes, as in how do I specify jikes as my ANT _BUILD_COMPILER and set up the ANT_BOOTCLASSPATH for some VM, as that's the tricky case because of jikes' class library wrappers. > Chapter 3. Advices to Java packagers > >Warning: These are just advices, they are not part of the >policy. > > * Be sure to manage all build and runtime dependencies by >hand in debian/control. dh_java makes this task a little >easier. It can also setup the java-config file. The CDBS >includes helper classes to handle ant based sources. > * You can suppress many calls in debian/rules which are >meaningless for Java, like dh_strip and dh_shlibdeps. > * Source package handling is painful, since most Java >upstream programs come with .class files. I suggest to >make a new .orig tarball after cleaning them, otherwise, >dpkg-source will complain. > * Java properties files are probably better under /etc and >flagged as configuration files (this will be integrated in >the policy, one day). I'd also add someting like 'Debian supports the free software community. You should make an effort to get your package to run with free java environments in debian, as it makes it accessible to more users. If you have problems getting your package to run with a VM, please work with the 'upstream' to resolve the issues, or find a workaround.' And maybe something about the commitment to quality of java packages: 'When you release an updated version of your package, please test if it still works with the packages it depends on, and if the packages that depend on it still work with the updated package. If anything breaks, please work with the maintainers and the upstream to fix it. Debian should be the best platform to use java on, and you can help this effort by making sure your package doesn't
Re: findjava requirement (was: 4. RfD for a new debian java policy)
--- Jan Schulz <[EMAIL PROTECTED]> wrote: > >> The 'findjava' algo was described in one of my mail. > >Hmm, I remember seeing it but I don't remember anyone suggesting that it > >be made compulsory. > > Dalibor argued quire havily for it :) Yes, I did. I think if debian had a java runtime selection system that considered the interestst of administrators, users, developers and packagers and worked in a way that would be acceptable to all here, then it might as well be made compulsory, so you'd be able to pick your java runtime the same for all debian java packages. This relies on packages using findjava to find their VMs, of course. If a package uses its own scheme, then I can set environment veriables till I'm blue in the face and nothing will happen ;) > BTW, the last open topic I still have is 'include' and > 'include/something'. How should that dealted with? Put everything into > one dir, as IBM does and patch around? Use a java-config setting? Hm, this is another 'stupid by design' issue. Sun has specified jni.h but hasn't specified the contents of jni_md.h. So it shouldn't be needed to build JNI apps. But Sun's jni.h apparently includes jni_md.h without specifying its search path. Unfortunately, jni_md.h seems to be stuck in a OS-specific directory, so Sun wants you to stuck the OS-specific directory to your compiler's header file seach path. So I wouldn't mandate that a VM has a include/something dir. Instead the policy shoudl advise programs building with JNI to include both $JAVA_HOME/include/ and $JAVA_HOME/include/linux if the build process is supported with sun's JDK. cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava requirement
--- Ean Schuessler <[EMAIL PROTECTED]> wrote: > I'm still not clear on why we cannot require every VM to provide a more > specifically detailed version of the JAVA_HOME ad hoc standard. We > should have a document that lists all of the $JAVA_HOME/bin/..foo.. > $JAVA_HOME/lib/..bar.. locations that Debian Java packages expect to be > provided. Then, JAVA_HOME itself can be handled using alternatives and > live at /usr/lib/jvm[jre,gnuvm,etc.]. I think that JAVA_HOME is quite pointless, as the only good use for it seems to be to locate JNI headers. It's an ill-defined ad-hoc 'standard' that isn't even supported by Sun. Programs that rely on JAVA_HOME to be able to access internals of the VM are inherently broken, they just start to notice it on free VMs ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing a Java VM on Debian
Jan Schulz wrote: Hello Dj, Sunday, October 5, 2003, 1:13:52 PM, you wrote: You probably want to search the net for some firsthand experiences with tomcat and the above free java virtual machines. Here's how I got it to run with kaffe's CVS: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03287.html . Make sure you read the whole thread. It should also run with the upcoming kaffe 1.1.2. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hi Jan, hello Ricky, Jan Schulz wrote: Hello Ricky, Wednesday, October 8, 2003, 5:56:22 PM, you wrote: Well, if the Debian Java policy were modified so that the command line were rigorously defined (basically take the output of java -help from the Sun JVM or elsewhere) I'm waiting for the screams... /me screams: not the same discussion again! ;) it's been a few weeks of hard work (and fun) to convince Jan to drop too simplifying approaches (like 'why don't we make a debian policy what java command line options should be') from the java policy proposals, and work out something more flexible, which is his findjava scheme. the bottom line is: sun doesn't care about debian. No matter what debian decides, even if it's based on java 1.4.2, it won't prevent Sun from breaking that 'interface' in, say, 1.5. They have a history of inconsistency both with the synopsis and the semantics of their java command's options between the releases. And even if one agrees on a policy that would necessarily have to specify some command line options that are not in some release of JDK, debian wouldn't be allowed to distribute the modified source of the java script, AFAIK, so we would be back to square one in 6 months. And that's just the problems with Sun's implementation, I could go on ranting about others for a while, too. But just read the thread ;) The alternatives system works fine for sensible-editor, where you just specify a file on the /usr/bin/java has to garantee even much more: that the commandlien interface is the same all over, that the JVM is able to run *all* code, which is thrown at it. OYu can't do that with the variety of JVMs, which are available on debian. For example all free JVMs lack the ability to run swing code or (AFAIR) the java-1.4 NIO code. Exactly. There is huge difference between managing application that 'do one specific thing' and managing a java runtime. You can't guerantee that a piece of code you supply to /usr/bin/java will also run on it. In part because of the incomplete state the free VMs are in, but in part also because of the miserable quality of code in some applications, that depend on a particular undocumented mis-feature of some specific version of Sun's offer to run, despite Sun telling people to program to the API. Currently, for example, the Xerces-J team has got a bug filed in their apache bugtracking system, with a ton of duplicate bug entries, because someone checked in some code that depends on an undocumented feature of some sun.* class to look up something about Character Encodings. Unfortunately, the Xerces J developers don't want to lose that 'feature' so the miserable code will stay in, preventing the next release of Xerces-J from being buildable on any free VM. Of course they could also use ICU4J, or ICU4JNI, or java.nio from java 1.4, but the responsible developers seem to want to have the feature on all platforms, which for them means using undocumented classes from Sun, that even Sun tells them to avoid. And of course it's far from running on all platforms. ;) Read the threads for more examples of 'unportable java code' in other projects. ;) I don't see why sensible-java, or just 'java' couldn't have a standard interface, with things like java -classpath BLAH -bootclasspath BLAH etc. Isn't that Becuas ethe altwernative system could garantee the 'backend', like core classes and so on. Things like -bootclasspath are only used by broken by design applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and it's there for a single reason: debugging. Applications have no buisiness replacing classes from the core libraries. This seems to negate some of the reasons you gave, other than 'a future VM might not do this'. All of them try, but there is no 'official' interface and there isn't any way to be *sure*, that this stays the 'standard interface of sun JVMs'. I would also be happy, if I could say: here, java has to take this arguments and it must resultin this-and-that. But this will be *really* confusing, when future sun java versions changes this interface. And they have a long record of doing so in the past. Beside, that doesn't buy you much, except knowing how to pass a few arguments around. Most of time, when an application doesn't run, it's not because someone forgot to set -Xmx128M, but because some amateur programmer checked in some code that uses sun.* classes, and sun changed their internals in the meantime. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
;t care about java home at all. It is just a mechanism for users and application packagers to come together on a VM-application combination that is supposed to work. If the app uses JAVA_HOME and a VM provides enough of it for an app to run, then fine, the applicatin packager can add the VM to the list of VMs his application should work on. But assuming that just because a VM provides a debian specific JAVA_HOME directory structure some JAVA_HOME using app will run, is wrong, in my experience ;) 2) Independence of the JVM packages That's Ean's point. Each JVM has its own command line arguments, so code is needed to translate a standardized set of command line arguments to the JVM own format. We should not put this translation code in a common package, because then each maintainer will need to update it from time to time, and it will be a mess. Yes. That is where I'm at. Could the findjava script then be split apart into VM specific 'plugins' to do the work? then the VM package maintainers could independently update 'findjava-kaffe' from 'findjava-sablevm', while keeping the calling interface for the main 'findjava' script. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hi Ean, thanks for your quick reply! Ean Schuessler wrote: On Thu, 2003-10-09 at 12:17, Dalibor Topic wrote: For example, it seems to be impossible for a non-root user, to overwrite the java alternative, whereas the proposed scheme allows the user to specify a different (maybe even working ;) jvm that he one that comes up on top of the alternative system. Given that currently some applications may run with some VMs, but not with others, and not on all platforms, findjava seems like a good compromise to me, which takes the idea of alternatives system, and extends it to be more flexible to be able to cope with current VM situation, i.e. debug everywhere ;) export JAVA_HOME=/usr/lib/kaffe (not so hard) Which only works for those apps that use JAVA_HOME to find the java executable to run themselves. Not for the others. The trouble with JAVA_HOME is that even if debian specifies it, hardly any java application developer would be bothered to follow debian's specification, instead of whatever ad-hoc pseudo-standard de-jour JAVA_HOME seems to ben in whatever the current JVM release on the developer's target/developement platform is. From my experience with dealing with open source java developers, to most of them JAVA_HOME is like crack: once they get hooked on accessing sun's internals directly, it's very hard to get them off the quick fix. While kaffe now follows a more jre like file layout, some things will fail nevertheless (like code trying to access tools.jar in order to use Sun's javac, a classical ant, or tomcat fallacy). Code that relies on JAVA_HOME is VM dependant by design, and runs on free VMs by pure chance. That it often runs nevertheless is mostly the fruit of hard work trying to find ways to work around, ahem, sloppy programming ;) These issues are orthogonal. The directory structure of a VM that launches an app has no impact on whether it can call Sun internal code or not. It comes down to what the ClassLoaders will find. I've gone over this with Jan, and it seems that most apps use JAVA_HOME for two things: a) access Sun internal code, where having a JAVA_HOME layout doesn't help the free VMs run that code anyway. b) running with a VM that's not in $PATH. Which is what findjava is made for ;) c) avoiding free VMs like kaffe: See http://lists.codehaus.org/pipermail/jcontainer-commits/2003-July/000399.html for example: # Checking for JAVA_HOME is required on *nix due # to some distributions stupidly including kaffe in /usr/bin there providing a JAVA_HOME doesn't help either. d) to work around Cygwin's unix paths vs. Windows paths issues: http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03231.html there providing JAVA_HOME doesn't make sense for debian either. Is there any other use of JAVA_HOME you've seen? Where there is something gained by using JAVA_HOME that a) can not be provided by findjava and at the same time b) is portable through java runtimes? So I'm quite opposed to debian trying to standardise/faciliate something that is bad practice. Instead, it would be, in my opinion, better to teach the open source java developers to avoid using Sun's internals in their code. A noble ambition but I don't see us having much influence on the general community of Java authors out there. The JAVA_HOME convention is a reality, crappy as it may be, and many Java applications attempt to use it. Requiring Debian Java VMs to present some semblance of the JAVA_HOME "standard" is going to make more apps run on more VMs for Debian. I believe that's wishful thinking. The JAVA_HOME variable could be set by findjava script as well, if it would matter that much. But from my experience of wrestling with poorly programmed java applications, most of the stuff uses JAVA_HOME for trivial things, like finding the java binary, or utterly non-portable mess ;) Dealing with the use of Sun internals is a border case that needs to be addressed seperately for those apps that do so. Yep. A pox on their house and all that! ;) Both debian-java-home and findjava are attempts to deal with the same problem. But debian-java-home doesn't do much good: it adds some more burden on package maintainers, giving developers some hope that their apps may run on the VMs, if they use JAVA_HOME at all. But it's not giving users the security that a particular java application they installed will actually run on their system. From that perspective I'm not against the notion of packages being able to specify their own preference for a VM to run against and I'm not against centralizing the logic that finds that VM. Could the findjava script then be split apart into VM specific 'plugins' to do the work? then the VM package maintainers could independently update 'findjava-kaffe' from 'findjava-sablevm', while keeping the calling interface
Re: findjava is the question, is fixjava the answer?
T. Alexander Popiel wrote:
In message: <[EMAIL PROTECTED]>
Dalibor Topic <[EMAIL PROTECTED]> writes:
Things like -bootclasspath are only used by broken by design
applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and
it's there for a single reason: debugging. Applications have no
buisiness replacing classes from the core libraries.
In general, I agree... but I'll also say that Sun has no business
putting Xerces (of a decidedly old version) into the core libraries.
But they do anyway, and if you want to use a recent version of
Xerces, you have to go dorking with the bootclasspath.
Well, yes. But no matter which version they put in, it's always going to
have bugs, and be a decidedly old version in a year from now. I thought
there was a documented way to replace the parser implementation using
system properties? How about using your own class loader to load the
parser classes in their own namespace and using those instead?
cheers,
dalibor topic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Jan Schulz wrote: Unfortunately, the Xerces J developers don't want to lose that 'feature' so the miserable code will stay in, preventing the next release of Xerces-J from being buildable on any free VM. Than I'm particulary happy, that eclipse will lose the internal xerces in the next version :) What's good for eclipse, seems to be good for other projects, too. eXist is looking for ways to replace Xerces for XML serialization at least (which is where I saw the bug in xerces for the first time). Just shows how, as free java implementations gain momentum, the projects containing broken and unportable java code will suffer, and lose mind share. I see gcj as a major driving factor there. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hi Alexander, T. Alexander Popiel wrote: I have not found any documented way of replacing the parser version. Mangling bootclasspath to do it isn't documented, either... but follows from first principles. See docs for org.xml.sax.helpers.XMLReaderFactory. citing the docs: "This method uses the value of the system property "org.xml.sax.driver" as the full name of a Java class and tries to instantiate that class as a SAX2 XMLReader." Given that the code which is having trouble is being run inside both jboss and weblogic, we don't have particularly good control of the classloader (unless we do a whole bunch of platform-specific dinking for each one). I'm not quite sure I get that. Can't you use your own class loader to load the main class, and have it delegate to the proper jar for the classes whose names start with 'org.xml' or 'org.apache' or whatever the xerces prefix is? Lookup docs for Thread.setContextClassLoader , it could help there. The core libraries have no business depending on or including separately distributable packages like xerces... but that's a rant for another day. Agreed. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
hose bit sequences is contradictory in itself. Beside, you have no means to differentiate between a bit-pattern potentially violating the GPL in this way and the same bit-pattern not violating the GPL. Is the (let's say ASL 1.1 licensed for the sake of argument) Hello.class that I have attached to my mail volating the GPL or not, i.e. has it been compiled against kaffe or not? Possible actions (no special order): * Review what java packages (especially the ones that are in "main" and contain GPL incompatible software) have been compiled with * Filling RC bugs for packages that seem to be indistributable * Finding a good way to check/assure what's the license of libs a package has been compiled with * Finding a good way to avoid such problems in the future (ex. by putting some tests into packages' build scripts or by using an improved version of findjava-like tool that understands licenses...) * figure out how you want to interpret the GPL in this case. The rest follows from that. Problems not touched: *execution* of GPL-incompatible code using GPLed libs and/or GPLed JVMs is beyond the scope of this message. Here some more food for licensing flamewars bezound the scope of GPL: There is an interesting symmetrical case to be tried: provide a 'dummy' GPLd libc, that does nothing. It would go to main, and you could compile applications against it, though not run them. Then debian would have to kick Apache's web server out of main, since it'd be a) incompatible with the new alternative pure-gpl libc, but b) could be linked to it/would be implicitely liked to it through a Depends: libc line. As another remark, if you think Kaffe's licensing implications are complicated, take a look at mono: GPL interpreter and LGPLd runtime, X licensed class library[3]. If the X licensed class library is linked during runtime to the GPLd interpreter via LGPLd libraries, how come Ximian is allowed to ship it under the weaker-thank-GPL X license, thereby apprently violating FSFs position on GPLd interpreters? cheers, dalibor topic [1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL [2] http://www.kaffe.org/pipermail/kaffe/2003-June/042838.html [3] http://www.go-mono.com/faq.html#licensing Hello.class Description: application/java-vm
Re: Undistributable java in main
Jan Schulz wrote: Hallo Dalibor, * Dalibor Topic wrote: * figure out how you want to interpret the GPL in this case. The rest follows from that. Problems not touched: *execution* of GPL-incompatible code using GPLed libs and/or GPLed JVMs is beyond the scope of this message. Could you please take this two thing to debian-legal and get a opinion there. Agreed. Anyway: if thats true, that it will kill kaffe in debian, as we could not use it with almost any programm, because in one way or another, they all include apache licensed libs (-> jakarta project). Don't agree. ;) Even if this was true, it would be good enough for *compiling* all the GPLd java apps. I guess there must be some, judging by freshmeat: http://freshmeat.net/browse/198/?topic_id=198&orderby=&filter=15 1051 GPLd Java apps. By far the most popular license for Java apps. As Grzegorz said, he isn't even touching *execution*, that's another field where we are bound to disagree ;) Anyway, we're switching kaffe's class library over to GNU Classpath, which is GPL + linking exception, and that should make the people who support FSFs interpretation happy, too, as GNU Classpath explicitely allows linking to it. The plan is to have that finished before next summer. People are always welcome to jump in and help out: merging classes is usually simpler than writing them from scratch ;) I hate licenses... Don't agree. GPL is quite nice for me, the trouble is that the rest of the world sometimes uses something incompatible and then we have to play lawyers to decide what's allowed and what not ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eclipse packages for !i386 platforms for sarge release
Jan Schulz wrote: Hallo! Hallo Jan, Theoretically (actually: practically) SWT is runable with kaffe, so swt could be build on other platforms. Eclipse on the other hand will not run on a current kaffe. Not yet, but Mark Wielaard (I bet you remember him from our policy discussion) has been playing with it, and has something to show: http://www.kaffe.org/pipermail/kaffe/2003-October/044313.html so ... it's not fully there yet, but it can be done ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
Hi Etienne, Etienne Gagnon wrote: Hi Arnaud, Arnaud Vandyck wrote: Anyway, we're switching kaffe's class library over to GNU Classpath, which is GPL + linking exception, and that should make the people who support FSFs interpretation happy, too, as GNU Classpath explicitely allows linking to it. This won't necessarily change anything for Kaffe, as long as Kaffe itself is licensed under the GPL without any exception, as classpath classes do link with the underlying JVM [this is required to implement things like reflection]. So, I restate my argumnet clearly: Kaffe (GPL) + Classpath (GPL+linking exception) + Ant (apache license) => cannot be run, as running causes linking. Linking (statically or dynamically) is a form of modification in the FSF's opinion. GPL says: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. As running is clearly not covered under GPL, your argument doesn't work. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
Salut Etienne, Etienne Gagnon wrote: Dalibor Topic wrote: GPL says: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. ... ... As running is clearly not covered under GPL, your argument doesn't work. Modification *IS* covered by the GPL. (FYI, it's not my argument, it's Richard Stallman's). Agreed. Now, linking *is* a form of modification. Were it not, you could simply link your proprietary program with the GNU readline library. See http://www.gnu.org/licenses/why-not-lgpl.html if you have doubts about useability of a GPL library within proprietary code. Agreed. The fact that linking is done statically *or* dynamically is irrelevant; the result is that you have a combined work; all parts of the work must be licensed under terms that allow for the part to be combined with the other parts. Agreed, in part. Static linking quite clearly forms a derived work, the contents of one work end up in another. But nobody does static linking in Java anyway, AFAIK. Dynamic linking in Java, merely means inserting calls to some API into the bytecode, AFAIK. Now, if the API in question only has a GPLd implementation, I agree that the combined work in this case can be only created in connection of all parts it was derived from, and thus must follow the GPL. But, there is no way, if the code in question uses an API with a GPLd and a non-GPLd implementation, for you to determine which implementation it is supposed to be linked to in order to create a combined work, as the generated linking bytecode is implementation independant. So Gadek's point about 'linking to GPLd runtime libraries during compilation' is moot, in my opinion. See my 'possibly GPL violating Hello.class' example. It's an interesting philosophical, and probably legislative discussion, without much practical relevance, in my opinion. In any case, that's not really relevant for debian, in my opinion, as debian is in the business of copying, modifying, and distributing works. So debian needs to figure out an interpretation of the GPL for java that they can live with between the two extremes (FSFs vs. mine), and make sure that they stick to it. That's the business of debian-legal, I guess, who has not been very responsive about it so far :( As long as debian-legal doesn't get involved and makes a decisive argument in favor of one interpretation or the other, it's a bit of a philosophical discussion. In any case, I'd like to express my full support for SableVM in Debian: it's a cool VM, and I want to merge it parts of it into kaffe one day. It doesn't suffer from being 'more copyleft than it's good for it' by being LGPLd, so that this kind of discussion is be pointless for it. Beside, we all know each other from various free java mailing lists, IRC chats, and conferences [1], and have respect for each other's work. So sorry, no flamewars to be seen here ;) My recommendation is to let debian-legal figure it out, and then either change nothing or make sure non-GPL compatible apps/libs don't have a 'Depends:' on kaffe, if debian-legal decides to adopt FSFs interpretation. Whatever happens, findjava shouldn't limit the user's capability to run a VM with some code, in my opinion. cheers, dalibor topic [1] Etienne was the first free Java runtime hacker I met in person, during CC2000 in Berlin. He reignited my interest in creating a free java runtime back then with their cool work on Soot and Ashes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
E.L. Willighagen (Egon) wrote: On Saturday 01 November 2003 20:08, Etienne Gagnon wrote: E.L. Willighagen (Egon) wrote: The big question seems to come done to: "What part of Java is library and what part is language?" It seems to me that at least the syntax *and* java.lang *is* the language... Thus as long as you don't use anything else then java.lang classes, you can use kaffe to run *any* Java byte code, independent which license... The FSF seems to disagree with you there. See the GPL FAQ: If only the part below makes you believe that the GPL FAQ disagrees, then I tend not to agree... Contrarily, I think this FAQ items supports my point: I think the text clearly distinguishes from language and library part of interpreters... just like my argument. The java.lang package *is* the Java language, not a library part... everything else under java.* is library... So the FAQ items actually supports my view that if you only use Kaffe to interpret java.lang classes and nothing else, then Kaffe just interprets the language, and the FAQ states that it then does not require the program run by Kaffe needs to be GPL too... Egon http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL [Please note the 3rd paragraph of the answer.] Q)If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? A)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. The language is the syntax + java.lang classes. (IMHO) The .lang must come from somewhere... The language is defined by the Java Language Specification. 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. This would be packages like java.util and java.io No, not really. Those packages are explicitely specified in the Java Language Specification, first edition. In fact, for some classes, like java.io.StreamTokenizer, the JLS 1st Ed. is the only place where the semantics of some of the methods is specified at all. See http://java.sun.com/docs/books/jls/first_edition/html/javalang.doc.html#41908 http://java.sun.com/docs/books/jls/first_edition/html/javautil.doc.html#32170 http://java.sun.com/docs/books/jls/first_edition/html/javaio.doc.html#46187 Conclusion: The argument as presented by FSF is wrong. ;) In my opinion, if the interpretation of GPL2 is so obviously ambiguous [1] as in this case, the FSF would be better off drafting a GPL3 that is unambiguous instead relying on 'dogmas' from above to regulate the interpretation. cheers, dalibor topic [1] Given that most replys I've seen here didn't fully support FSFs view. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Hi Etienne, let's have some non-lawyerish philosophical licensing discussion fun again ;) My first issue is with the subject line: Kaffe uses plain GPL, not some special 'Kaffe's GPL'. It should be FSF's GPL, if you'd want to attribute it someone special. Etienne Gagnon wrote: Hi Debian-legal, Egon and Dalibor, The opinion of debian-legal would be highly appreciated by all involved in this long running thread of discussion about the implications of: 1- Kaffe being licensed under the GNU GPL. 2- Kaffe's class library being licensed under the GNU GPL. 3- Differeing interpretations about what constitutes "linking" (more precisely: combining of works to form a derivative) between: a) class libraries and applications, b) class libraries and core VM (in the case of Java VM). See below. It would have been nice if you had made the arguments of each side clear, before attacking my position. The discussion has not taken place on debian-legal, but on debian-java. I appreciate the way Gadek presented both sides of the previuos argument. The trouble is that in the rest of your mail you shed very little light on the differing interpretations of what constitutes a derivative work, but instead go on about a hypothetical case to prove your point. That is a very bad way to present your case, in my opinion. Dalibor Topic wrote: The language is defined by the Java Language Specification. But the virtual machine is defined by the Java Virtual Machine specification [JVMS]. This specification is *different* from the JLS, as it is possible to write valid bytecode sequences (according to the JVMS) that cannot be genereted using a JLS compliant compiler. So, what is Kaffe? A Java interpreter, or a Java virtual machine? ;-) http://www.kaffe.org says: What is Kaffe? * Kaffe is a clean room implementation of the Java virtual machine, plus the associated class libraries needed to provide a Java runtime environment. The Kaffe virtual machine is free software, licensed under the terms of the GNU Public License. [snip] What is Kaffe not? * Kaffe is not an officially licensed version of the Java virtual machine. In fact, it contains no Sun source code at all, and was developed without even looking at the Sun source code. It is legal -- but Sun controls the Java trademark, and has never endorsed Kaffe, so technically, Kaffe is not Java. No, not really. Those packages are explicitely specified in the Java Language Specification, first edition. In fact, for some classes, like java.io.StreamTokenizer, the JLS 1st Ed. is the only place where the semantics of some of the methods is specified at all. Assume we went along with your interpretation that all the "specified" class libraries are part of the VM, and that running a Java program does not "combine" the application classes with the standard class library class ancestors (like java.lang.Object)[1]. The current JDK 1.4 class libraries, for which you cannot buy a written specification (in a book), contains all kind of things like XML parsers & so on. Sun Microsystems can unilaterally decide what can be added to the standard libraries. Sun unilaterally decided and will decide what can be added to their libraries. Why does that matter? Why does being able to buy a book matter in order to interpret the GPL in this case? So, here is a hypothetical situation, where Sun could abuse its powers under your interpretation of the FSF's opinion: This is debian, it's not Sun. ;) If you have a concern that Sun could abuse kaffe, take it to Sun or kaffe, *when it happens*. There is not much point in discussing hypothetical cases on debian-legal in my opinion, if they are not related to debian at all. So, in my opinion, your interpretation that class libraries are part of the VM would create an important loophole in the GPL. If Kaffe wants to allow classes to be combined with its libraries and wants to allow the class libraries to be combined with the core VM (to implement System.gc(), etc.), it should provide an *explicit* exception to the GPL, as does Classpath, Guile, and other similar GNU projects. You're committing a classical fallacy: Appeal to Consequences of a Belief [1]. The consequences of my interpretation do not matter when we discuss whether it is correct or wrong. The case is not much different that with binary modules in the kernel. One copyright holder (Linus Torvalds) has expressed his interpretation of the GPL, the FSF has expressed another, and everyone lives on happily, and nobody is getting sued. I'm just one copyright holder of many on kaffe. That's my interpretation, others may agree or not. They don't have to, I don't run a copyright-assignment business like the FSF does. My interpretation does not create loopholes in GPL, that aren't there to begin with. GPL, as any legal docum
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Etienne Gagnon wrote: Dalibor Topic wrote: It would have been nice if you had made the arguments of each side clear, before attacking my position. The discussion has not taken place on debian-legal, but on debian-java. I appreciate the way Gadek presented both sides of the previuos argument. You have a good point, there. I am pretty busy right now. Give me a few days and I will try to write a summary of the various arguments presented by various people (on debian-java and IRC). Nah, leave IRC out, as it leaves no archive trail, and debian-java was not involved in that. Then we'd have to discuss irc logs, and not everyone was particiaping in that, and so on. I will also try to clarify my arguments, in regards to your comments. ;-) Yes please ;) If anybody else is willing to write the summary sooner than me, you are welcome to do so, but please let me know about it (so that I do not start working on it). Definitely not me, as I'm busy enough with kaffe without discussing interpretations of the GPL, but I'll take a look at the summary, and comment on it. So the case shall rest till then ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: statcvs java error
Wim Bertels wrote: Houdi, i use statcvs 20030713-2 (unstable apparently), i get the following error while trying to run statcvs damian:/tmp# statcvs logfile r2g2/ StatCvs - CVS statistics generation java.awt.AWTError: native layer initialization failed at java.awt.Font. (Font.java:48) at net.sf.statcvs.renderer.Chart. (Chart.java:53) at net.sf.statcvs.renderer.LOCChart. (LOCChart.java:66) at net.sf.statcvs.output.HTMLOutput.createLOCChart (HTMLOutput.java:300) at net.sf.statcvs.output.HTMLOutput.createHTMLSuite (HTMLOutput.java:177) at net.sf.statcvs.Main.generateDefaultHTMLSuite (Main.java:178) at net.sf.statcvs.Main.main (Main.java:75) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at kaffe.jar.ExecJarName.main (ExecJarName.java:67) at kaffe.jar.ExecJar.main (ExecJar.java:75) damian:/tmp# ls file-deleted.png file.png folder-deleted.png folder.png logfile r2g2 statcvs.css system setup: debian kernel stable, cvs testing (1,12), statcvs unstable, no apache, no webserver, no java (but kaffe). Hi Wim, unfortunately, kaffe 1.1.1 (in debian) isn't able to run statcvs yet. kaffe 1.1.2 gets a little bit further, AFAIK, but fails due to a missing java2d implemenation. I plan to merge in Agile2D into kaffe, which provides a Java2D over OpenGL implementation, and that should allow it to run StatCVS, among other programs using Java2D. So hopefully, the upcoming kaffe 1.1.3 will be able to run it. Helpers for hacking on kaffe are always welcome ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe in testing
Salut Arnaud, hi all, Arnaud Vandyck wrote: On Tue, 11 Nov 2003 14:20:39 +0100 Daniel Bonniot <[EMAIL PROTECTED]> wrote: [...] Given that a release it coming, it would be really nice if these issues could be solved. There are at the moment 17 packages prevented to enter testing because of kaffe. Or looking at it more positively, making kaffe enter testing would allow (or at least help?) 17 other package to enter too. :-) Two more important bugs (but I did not file it on the bts): - problem with xml entities (bug introduced by gnujaxp): resolved with 1.1.2 - java.util.TimeZone.SHORT does not exists: resolved with 1.1.2 Dalibor, when do you plan a new release of kaffe? I am not personally involved in the debian packaging of kaffe [1], so I can't say what Ean's plans are. Kaffe 1.1.3 should come out by the beginning of december according to our 'every two months a release' [2] schedule. Marko Jung, one of our local debianistas in Saarbruecken, expressed some interest in helping out with the packaging of kaffe to take some of the load off Ean due to our frequent release schedule, and to help with getting up to date kaffe releases into testing, and the next debian release. I've CC:ed him on this mail, too. If Ean approves, he could help out with kaffe packaging. I think Marko already applied to become a debian maintainer, and is, AFAIK, currently packaging the ATI binary drivers. cheers, dalibor topic [1] Beside going over the debian bug database ocassionally, and pointing out what's been fixed in the CVS. [2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03400.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe in testing
Daniel Bonniot wrote: The other bug is a build problem on m68k, so it is probably going to go away when the builds on (alpha, arm, m68k, s390, sparc) are fixed. Are these architecture supported upstream? If yes, then maybe Dalibor could look at the logs and help with diagnosing the problem. If not, then maybe they should be removed from kaffe architecture list, so it can move in testing for the working ones. Those build failures should have been fixed in 1.1.2. They were mostly introduced by the new gcc version being more strict about bad code than versions before ;) In general, you can regard any platform in the CVS as supported with kaffe. How far the support goes, though, depends on how many people there are developing on it. As usual, the more popular platforms (intel) have more developers working on them, so bugs get spotted faster and fixed quicker. ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[mark's edition] [RFC] Upcoming Apache Software Foundation License changes
Hi Mark, this mail would go out to kaffe, gcj, classpath, classpathx-discuss, classpathx-xml, gnu crypto, wonka, aegis, sablevm. I could seed it a little further, but yeah, no time to search for links. Hi all, excuse me for cross-posting the following e-mail to so many diverse projects. As I'm subscribed to all those projects mailing lists, I was surprised to notice a lack of discussion on the effect of the upcoming Apache Software Foundation (ASF) license changes [1] on them. Most of you know ASF for their great work on free java software. ASF is increasingly becoming the testbed, and reference implementation provider for Java APIs, which end up in the implementations provided by Sun. The ASF is trying to modify its licenses to ensure GPL compatibility on one hand, and satisfy JSPA (Java Specification Participation Agreement) [2] requirements on the other hand, among other goals. A new set of licenses replaces the single Apache license by 3 separate licenses, that inted to cover general Apache projects [3], reference implementation of a JSR (Java Specification Request) [4], and testing compatibility kits (TCKs) of a JSR [5]. As many of you are involved in projects that provide free implementations of parts of the runtime environment for Java programs, it would be nice if you could take some time to comment on the proposed licenses to the Apache license discussion mailing list. Instructions how to join that mailing list are povided on [1], the archives are on [6]. The effect of the upcoming ASF license change *could* be beneficial to the free software java world and the ASF wants to achieve that. The availability of RIs and TCKs under a liberal license seems particularly attractive to free software Java projects. You can help fixing problems with the next apache licenses if you take some time to comment on them. If you intend to so so, make sure to submit your comment today. Yes, today is the last day, therefore you get this cross-posted e-mail, and so on. Anyway, comment on what you percieve as problematic, and your grandgrandchildren may thank you ;) thanks, dalibor topic [1] http://www.apache.org/licenses/proposed/ [2] http://www.jcp.org/aboutJava/communityprocess/JSPA.pdf [3] http://www.apache.org/licenses/proposed/LICENSE-2.0.txt [4] http://www.apache.org/licenses/proposed/ri-license.txt [5] http://www.apache.org/licenses/proposed/tck-license.txt [6] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mark's edition] [RFC] Upcoming Apache Software Foundation License changes
This bird got out too quickly. ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[RFC] Upcoming Apache Software Foundation License changes
Hi all, excuse me for cross-posting the following e-mail to so many diverse projects. As I'm subscribed to all those projects mailing lists, I was surprised to notice a lack of discussion on the effect of the upcoming Apache Software Foundation (ASF) license changes [1] on them. Most of you know ASF for their great work on free java software. ASF is increasingly becoming the testbed, and reference implementation provider for Java APIs, which end up in the implementations provided by Sun. The ASF is trying to modify its licenses to ensure GPL compatibility on one hand, and satisfy JSPA (Java Specification Participation Agreement) [2] requirements on the other hand, among other goals. A new set of licenses replaces the single Apache license by 3 separate licenses, that inted to cover general Apache projects [3], reference implementation of a JSR (Java Specification Request) [4], and testing compatibility kits (TCKs) of a JSR [5]. As many of you are involved in projects that provide free implementations of parts of the runtime environment for Java programs, it would be nice if you could take some time to comment on the proposed licenses to the Apache license discussion mailing list. Instructions how to join that mailing list are povided on [1], the archives are on [6]. The effect of the upcoming ASF license change *could* be beneficial to the free software java world and the ASF wants to achieve that. The availability of RIs and TCKs under a liberal license seems particularly attractive to free software Java projects. You can help fixing problems with the next apache licenses if you take some time to comment on them. If you intend to so so, make sure to submit your comment today. Yes, today is the last day, therefore you get this cross-posted e-mail, and so on. Anyway, comment on what you percieve as problematic, and your grandgrandchildren may thank you ;) For another take on this issue, please take a look at Mark Wielaard's (GNU Classpath maintainer) reply [7] to an earlier version of this RFC sent to the debian-java mailing list, who asks developers to take a look at the RI and TCK licenses, as the ASF hasn't received many comments on those. thanks, dalibor topic [1] http://www.apache.org/licenses/proposed/ [2] http://www.jcp.org/aboutJava/communityprocess/JSPA.pdf [3] http://www.apache.org/licenses/proposed/LICENSE-2.0.txt [4] http://www.apache.org/licenses/proposed/ri-license.txt [5] http://www.apache.org/licenses/proposed/tck-license.txt [6] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread [7] http://lists.debian.org/debian-java/2003/debian-java-200311/msg00102.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe in testing
Hi Ean, Ean Schuessler wrote: The problem for me at this point isn't so much a lack of time as it is a lack of understanding about the release cycle underway. I've heard varying stories about whether we can or can't upgrade to new upstream versions. If we can then I've already got 1.1.2 packaged. You can download an i386 version at http://www.brainfood.com/~ean/kaffe_1.1.2-1_i386.deb. could you do an update of 1.0.5 first, please? That RC bug[1] is one of the two[2] holding back kaffe from entering testing from what I see on [3]. An upload of 1.1.2 will not fix that bug, as it's a bug in stable, and 1.1.2 is has no chance going into stable until the next release, sarge, afaik. You said in late august[3], you'd like to fix that one by adding debhelper as a build depend to 1.0.5. Did that work out? Therefore: - Download and have a look at that 1.1.2 package if you are on 386. looks nice to me, all the files seem to be there. I don't have a self-administered debian box on i386, so I can't really test. - Tell me whether you think upgrading to 1.1.2, 1.1.3, etc. etc. while we are in freeze is legitimate or whether we need to be backporting patches from CVS. 1.1.3 is due in 2 weeks. It will be released on time, working as far as we get it to. i386-linux works fine with current CVS. If you want to backport patches, you'll have to seriously sink some time into developing kaffe, or you'll end up frustrated by the pace. It develops quite quickly at times. My plans include putting in inetlib, a java orb, and rxtx, among other niceties, and there will be a few new AWT implementations on the way, too. NIO is very much under development, as are other parts of the class library while we are switching over to GNU Classpath, and fixing its newfound bugs. - If you really want to see results stop complaining about problems and ship me a DBS formatted patch file for whatever is bothering you. Oh, and make sure it actually works first too. Yep, that's the way it's done in the free software world. And please forward the patches you get upstream, if they still apply to the CVS. It's quite annoying to have to do the stupid wrapped string compiler error patch for gcc 3.3, only to discover that someone half-did it already for debian. We need more contributors anyway ;) cheers, dalibor topic [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197617 [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=kaffe&sev-inc=critical&sev-inc=grave&sev-inc=serious [3] http://packages.qa.debian.org/k/kaffe.html [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197617&msg=23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe in testing
Pierre Machard wrote: Hi, On Thu, Nov 20, 2003 at 03:23:44PM +0100, Dalibor Topic wrote: [...] - Tell me whether you think upgrading to 1.1.2, 1.1.3, etc. etc. while we are in freeze is legitimate or whether we need to be backporting patches from CVS. 1.1.3 is due in 2 weeks. It will be released on time, working as far as we get it to. i386-linux works fine with current CVS. What about other arch? try it and report a bug/submit a patch to the mailing list ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse
Mark Wielaard wrote: Hi, On Sun, 2003-11-30 at 19:23, Victor Niebla wrote: Hi all, has someone succeded on building and using Eclipse with Free Vm (like sablevm or kaffe) + Classpath ??? Sure. It works with most of the free runtimes now. You have your choice of: - mono + ikvm.net http://weblog.ikvm.net/PermaLink.aspx/894943be-451e-4d6c-a692-77119eb02d06 (2.1 only as far as I know, but IKVM.NET follows GNU Classpath quite closely so getting 3.0M4 working should not be that difficult.) - kaffe Kaffe from CVS (will become 1.1.3 in one/two weeks) can run Eclipse 2.1 out of the box. 3.0M4 needs some patches (that might or might not make it for 1.1.3): http://www.kaffe.org/pipermail/kaffe/2003-October/044313.html Of course kaffe is as interested in new hackers as any other VM to help us push the treshold for free java runtimes a little higher [1]. ;) The earnest work takes place on the kaffe mailing list, the chit-chat is happening on #kaffe on irc.freenode.org. In any case, if someone would like to contribute to any of the free VMs, be it kaffe, wonka, sablevm, etc. please make sure that you meet some clean-room conditions as outlined here: http://www.kaffe.org/pipermail/kaffe/2003-November/044406.html cheers, dalibor topic [1] The wishlist for the next versions can be found here: http://www.kaffe.org/pipermail/kaffe/2003-November/044431.html Progress is happening gradually, and could happen faster if we had more volunteers [2] ;) [2] Especially DocBook, Ant, Maven & Tomcat savvy volunteers, as we plan to start using kaffe releases soon for documentation generation and the website: http://www.kaffe.org/pipermail/kaffe/2003-November/044525.html http://www.kaffe.org/pipermail/kaffe/2003-November/044528.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse
Hola Victor, Victor Niebla wrote: Kaffe works with Classpath classes or his own implementation of the Java API ??? It now uses GNU Classpath for a major part of the class library, while some parts still need to be switched over. We decided to do a gradual transition to GNU Classpath, instead of switching over completely at once. The reason was that we know all code is buggy, and doing the transition gradually helps us discover & fix previously unknown bugs in GNU Classpath for the benefit of both the kaffe & GNU Classpath communities. It's much easier to spot a bug when you know that just a few classes changed last week. Switching over to GNU Classpath is a massive undertaking, and I'd welcome volunteers helping us do the switch faster. The next stable release of kaffe is scheduled for february, so there is still a lot of work to do, if we want to be 'mostly pure GNU Classpath' by then. And...What are the main diferences between Kaffe, Wonka and SableVM? Kaffe: Has a fast jitter on many platforms. Ported to just about anything that has a 32 or 64 bit CPU. Has a working AWT. Has JAXP. Has sound. Has working regular expression support. Has a partial JVMPI implementation. Works for non-trivial applications, like running tomcat4[1] or eXist[2]. Is under heavy development[3]. But as I'm biased, I'll give the others more space ;) Wonka: Very cool VM for embedded systems. From the web-page[4]: "Wonka is ACUNIA's cleanroom Virtual Machine for the Java™ language. It is extremely portable and self-contained, and can optionally be used with its own real-time executive (OSwald™) to provide a complete solution for embedded devices. The Wonka Virtual Machine is fully Java2™ compatible and the Wonka class libraries include all the classes needed to support the OSGi framework, as well as other popular mechanisms for distributed computing such as Jetty and Castor. Wonka comes with a high-performance lightweight AWT (Rudolph™) suitable for any memory-mapped or framebuffer display. Or you can plug in your own implementation, or run with no AWT at all (e.g. in a "headless'' system). The choice is yours." SableVM: Very cool research project. From the web-page[5]: " SableVM implements many innovative techniques including: * 3 flavors of threaded interpretation (switched, threaded and inlined), * bidirectional object layout, * spinlock-free thin locks, * sparse interface vtables, * low-cost maps for precise garbage collection. SableVM is able to run many applications and benchmarks, including multi-threaded programs, but it is limited by the current state of the class libraries, and lacks VM support for some class library features. SableVM is known to reliably run non-trivial applications like SableCC 2.17.3 and Soot 1.2.3, among many others. SableVM has been ported to the following 8 architectures under Debian GNU/Linux: alpha, arm, i386, ia64, m68k, powerpc, s390, sparc. It is also known to work on FreeBSD/i386, Mac OS X and a few others. Because of the ease of doing a new port - a number of new ports is planned." hope this helps. If you want to help fill in the gaps in missing free java functionality, consider helping out with the GNU Classpath project. One of the best ways to do that is to help with the kaffe transition to GNU Classpath, of course ;) cheers, dalibor topic [1] http://www.kaffe.org/~robilad/tomcat-4.1.27-screenshot.png [2] http://www.kaffe.org/~robilad/eXist-0.9.2-screenshot.png [3] http://www.kaffe.org/~robilad/loc.png [4] http://www.acunia.com/wonka/001_about.php [5] http://www.sablevm.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trouble with VM?
Hi Jose, José Fonseca wrote: PS: It's so sad that Java can't be included in standard Debian... :-( You can help improve the quality of the free java runtimes included in debian by lending a hand to the various free java runtime efforts out there (kaffe, sablevm, gcj, ...) , if you meet certain clean-room conditions. They are getter better every day thanks to many people who decided to stop waiting for Sun to make java free and take the necessary steps themselves. You could be one of us. ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
