RE: Free Java @ JavaOne 1999
If any one can help me please unsubscribe me now. Help. -Original Message- From: Anthony Green [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 21, 1998 12:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Free Java @ JavaOne 1999 Tim wrote: > Don't know if anyone else is looking into this but we'd like to put > together a free Java BOF at the coming JavaOne and obviously it'd make > sense to get all the free Java people together for this. > Any interest? Yes, absolutely. AG -- Anthony Green Cygnus Solutions Sunnyvale, California
Re: Kaffe as main target ?
Paul, > > For example, if I were to add a new GC to the GPL'd Kaffe, would I > have to sign the copyright over to TVT in order to have my changes > distributed with the official free version of Kaffe? And if I did > assign my copyright to Transvirtual, could they then turn around and > relicense my GC under non-free terms? > I believe the following is true: (again, I can't speak for TVT here) If you added a new GC to the GPL'd Kaffe AND wanted to have your changes distributed with the official, that is, TVT-released free version of Kaffe, you would have to assign your copyright to TVT, and they could then turn around and relicense your GC under non-free terms if they so desired. This may or may not be acceptable to you. If it is not, then you could a) not make it part of the official free version of Kaffe, but distribute your own, enhanced version of Kaffe. Alternatively, you can only distribute the parts you added. b) ask Transvirtual whether you can retain your copyright. While I can't speak for them, I would imagine that they'd be interested in this possibility under certain conditions: for instance, if the overall benefit to them would be bigger than the benefit of selling your specific piece of code in the proprietary version. In general, however, it is against their company policy. c) sell your work to TVT and ask for royalties (if they're interested.) Finally, I would like to point out that all of this has no impact whatsoever on the GPLed version of kaffe, which still fully qualifies as free software under the "Debian Free Software Guidelines" (http://www.debian.org/social_contract#guidelines) - Godmar
recent checkin of lib
The recent checkin of the 'lib' directory is probably only useful to me at this point. I'm having problems getting consistent results from attempted builds so your mileage may vary if you're willing to grab JavaDeps-2.0.1 and patch it and remake the jar file and twiddle with the Makefile.am you can try using this to get your classes compiled. It is also using javac the funky way Aaron spoke about on the list which seems to work well. You may want to modify the deps.sh script as well. I got tired of messing with Makefile shell escapes, can you tell? If you add classes you must run the deps.sh script again manually. I can't figure out how to get automake to not put in a default all: rule, but it doesn't seem to have an effect on the results. Guile is back into developmental state, so use the most recent stable version which I _think_ is 1.91 (but I'm just pulling that out of my...) if you're wanting to do the testsuite stuff. Brian -- |---|Software Engineer |Brian Jones|[EMAIL PROTECTED] |[EMAIL PROTECTED]|http://www.nortel.net |http://www.classpath.org/ |--
Re: recent checkin of lib
Brian Jones <[EMAIL PROTECTED]> writes: > Guile is back into developmental state, so use the most recent stable > version which I _think_ is 1.91 (but I'm just pulling that out of > my...) if you're wanting to do the testsuite stuff. You don't mean 1.91. You mean 1.2.91. :) The latest stable release is 1.3. Go grab it from prep. (it was released yesterday) -- Paul Fisher * [EMAIL PROTECTED]
RE: Correction of Misunderstandings
Ah, OK, makes sense. Thanks for the correction of my correction :) --John Keiser > -Original Message- > From: Godmar Back [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 21, 1998 2:04 PM > To: John Keiser > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Correction of Misunderstandings > > > > > > 3. Apparently it will be impossible for them to use Classpath. Pity. > > Apparently any code I write integrating the two will have to be > copyrighted > > by them. Bigger pity. I'll still do it, though, unless we > find a second > > person (and I hope we will). I want to see Classpath running > on two VMs. > > I'll probably ask on the Kaffe list once Japhar integration is done and > > stable. > > Again, I don't believe this is true. > > It is true that it will be impossible for Transvirtual to sell their > proprietary version with classpath or classpath integration code > in it. If > they did that, they would be in violation of classpath's copyright. > > It is false that any code you write would have to be copyrighted by > them. This only applies to code that you want to be part of the kaffe > CVS repository stored on TVT's server. It would be perfectly fine to > store code in the classpath CVS repository or somewhere else. > > (In fact, I believe that if such integration code existed, TVT might even > allow you to store it on their server under the FSF copyright, given that > they a) cannot sell it anyway and b) it might help make the kaffe codebase > stronger.) > > It is possible, technically and legally, to use classpath with kaffe. > In fact, once classpath is more usable, I was thinking of trying that: > at least those parts of classpath that do not require specific VM support > (i.e., that are purely written in JNI --- java.util.zip or java.math.*, > for instance) should already be usable in Kaffe. > > Individual users and projects will be able to mix and match kaffe and > classpath code as they wish and redistribute the result under the GPL: > the only thing that won't be possible is for TVT --- or anybody > else --- to > sell that mix under a non-GPL license. > > - Godmar > >
Re: Correction of Misunderstandings
> > 3. Apparently it will be impossible for them to use Classpath. Pity. > Apparently any code I write integrating the two will have to be copyrighted > by them. Bigger pity. I'll still do it, though, unless we find a second > person (and I hope we will). I want to see Classpath running on two VMs. > I'll probably ask on the Kaffe list once Japhar integration is done and > stable. Again, I don't believe this is true. It is true that it will be impossible for Transvirtual to sell their proprietary version with classpath or classpath integration code in it. If they did that, they would be in violation of classpath's copyright. It is false that any code you write would have to be copyrighted by them. This only applies to code that you want to be part of the kaffe CVS repository stored on TVT's server. It would be perfectly fine to store code in the classpath CVS repository or somewhere else. (In fact, I believe that if such integration code existed, TVT might even allow you to store it on their server under the FSF copyright, given that they a) cannot sell it anyway and b) it might help make the kaffe codebase stronger.) It is possible, technically and legally, to use classpath with kaffe. In fact, once classpath is more usable, I was thinking of trying that: at least those parts of classpath that do not require specific VM support (i.e., that are purely written in JNI --- java.util.zip or java.math.*, for instance) should already be usable in Kaffe. Individual users and projects will be able to mix and match kaffe and classpath code as they wish and redistribute the result under the GPL: the only thing that won't be possible is for TVT --- or anybody else --- to sell that mix under a non-GPL license. - Godmar
Re: Kaffe as main target ?
Godmar Back <[EMAIL PROTECTED]> writes: > As mentioned in my other mail, contributors to classpath are also > not allowed to retain their copyright if they want their > contributions to go into the classpath source. The FSF's assignment policy's main purpose is to ensure that all versions of a GNU program remain free -- that is, being the copyright holder, the FSF can easily prevent others from hoarding modified versions. However, even though the copyright is being assigned, the FSF is _never_ allowed to distribute your code under non-free terms. I assume that once you assign copyright to TVT for a modification to the GPL'd Kaffe, that they can then incorporate that code into their non-free tree? -- Paul Fisher * [EMAIL PROTECTED]
Re: Free Java @ JavaOne 1999
Sounds reasonable. One format is 5-10 presentation from each group, followed by 5-10 minutes questions to a specific group, followed by open floor. However, 60 minutes in length may not be enough for all the groups. Two back-to-back sessions would be better, if we could get it. Alternatively, just having separate sessions may make more sense. I suspect we could fill a 60-minute session on our own! --Per Bothner Cygnus Solutions [EMAIL PROTECTED] http://www.cygnus.com/~bothner
RE: Free Java @ JavaOne 1999
I'm definitely interested. My suggestion would be to make sure that this BOF is as near the beginning of the conference as possible. This will help us to have the maximum amount of time available during the conference with which to collaborate with each other, since we will have already met each other earlier. Also, make sure that it doesn't conflict with a possible JavaLobby BOF. - Avery J. Regier > Original Message- > From: Tim Wilkinson [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, October 21, 1998 12:06 PM > To: Kaffe mailing list; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Free Java @ JavaOne 1999 > > All, > > Don't know if anyone else is looking into this but we'd like to put > together a free Java BOF at the coming JavaOne and obviously it'd make > sense to get all the free Java people together for this. We've tried to > do this informally the last two years (they confiscated the megaphone > last year) but though we might try to get it into the official program > this year. > > Any interest? > > Regards > Tim > > -- > Tim Wilkinson Tel: +1 510 704 1660 > Transvirtual Technologies, Inc., Fax: +1 510 704 1893 > Berkeley, CA, USA.Email: [EMAIL PROTECTED] > >
Correction of Misunderstandings
OK, here are my misunderstandings and a consolidation of their corrections: 1. I was unaware that *any* of the ports of Kaffe were non-GPL'd, but it's good to know that all of Kaffe for Unix/X is GPL, anyway. 2. With "free software hackers," I just was referring to free software hackers that were not doing it for money (not that what Transvirtual does is bad or tainted!!!). They can be called free software hackers, too. No need to argue about it, as you said. I'll go one step further: *please*, no one start arguing about semantics here. Not the appropriate place or the time, and it's a useless argument besides. 3. Apparently it will be impossible for them to use Classpath. Pity. Apparently any code I write integrating the two will have to be copyrighted by them. Bigger pity. I'll still do it, though, unless we find a second person (and I hope we will). I want to see Classpath running on two VMs. I'll probably ask on the Kaffe list once Japhar integration is done and stable. --John Keiser
Re: Free Java @ JavaOne 1999
Tim wrote: > Don't know if anyone else is looking into this but we'd like to put > together a free Java BOF at the coming JavaOne and obviously it'd make > sense to get all the free Java people together for this. > Any interest? Yes, absolutely. AG -- Anthony Green Cygnus Solutions Sunnyvale, California
Re: Kaffe as main target ?
Godmar Back <[EMAIL PROTECTED]> writes: > It is true that Transvirtual holds the copyright on the Kaffe > source. Transvirtual requires contributors to sign their copyright > over to them. Does the copyright assignment prevent Transvirtual from using a person's contribution in their proprietary products? For example, if I were to add a new GC to the GPL'd Kaffe, would I have to sign the copyright over to TVT in order to have my changes distributed with the official free version of Kaffe? And if I did assign my copyright to Transvirtual, could they then turn around and relicense my GC under non-free terms? -- Paul Fisher * [EMAIL PROTECTED]
Re: Kaffe as main target ?
> > Transvirtual is motivated by the > fact that they can relicense their code base for proprietary use and > modification -- they of course can't do that if they start accepting > outside code. It is true that Transvirtual requires outside contributors to give up their copyright (and give it to Transvirtual) if their code shall be kept as part of the public kaffe base on TVT's servers. It seems incorrect to say that they don't accept outside code. In fact, I myself have contributed code to kaffe, and I count myself as outside of TVT. As mentioned in my other mail, contributors to classpath are also not allowed to retain their copyright if they want their contributions to go into the classpath source. Somebody correct me if I am wrong on this. To be accurate, I shall repeat that the FSF is a non-profit organization, while TVT is a for-profit company, so different motives are involved. > > > I was going to respond originally, but here Paul has finally said it, > so I'll add my own comments. While sharing Java source seems > plausible, it doesn't appear to me to benefit them to share native > source, since they want to relicense that for whatever embedded > systems folks are interested in buying the Kaffe solution. Since > they might want to reorganize their Java source differently than we > do, from the point of view of what is native and what is not, then > working from the same Java source probably wouldn't work. The only > possible thing I see happening is they might open up the Java source > as LGPL instead of GPL. This makes sharing possible, though we can't > work from the same base. > I don't understand all the statements in this paragraph. In particular, I do not know what you mean by "share native source". However, it seems that it might cause misunderstandings for people that are less involved in the matter. It is not true that the open edition of kaffe requires any code or object files or class files that have not been released under the GPL. The complete kaffe system (including class libraries, the code for the native methods for these libraries, the VM and its subsystems) have been released under the GPL. This includes an X11-based AWT. TVT does not release the source to the so-called custom edition. This edition requires licensing. It shares code with the GPLed, open edition, but provides more functionality that the open edition does not have, such as an AWT implementation for DOS. It is true that the library source is GPLed, as opposed to LGPLed. This means that anything using it would have to be GPLed as well. I don't see how that would affect the use of a mixture of classpath and kaffe libraries. As for the possibility of mixing the trees or using classpath Java source with kaffe's native functions, I agree that that is unlikely to work. >From what I know of classpath's structure, this shouldn't be a problem if one wants to use classpath's libraries with the Kaffe VM, once the layer connecting the two is implemented. - Godmar
Re: Free Java @ JavaOne 1999
Tim Wilkinson <[EMAIL PROTECTED]> writes: > > Don't know if anyone else is looking into this but we'd like to put > together a free Java BOF at the coming JavaOne and obviously it'd make > sense to get all the free Java people together for this. We've tried to > do this informally the last two years (they confiscated the megaphone > last year) but though we might try to get it into the official program > this year. > > Any interest? Sure. I think that'd be very cool. Chris
Re: Kaffe as main target ?
> > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher > > > > "John Keiser" <[EMAIL PROTECTED]> writes: > > > > > un-splintering the community's resources. > > > > I really don't see the community's resources as being splintered. > > Transvirtual is working on their libs, and free software hackers are > > working on the GNU Classpath libs. :) Transvirtual is motivated by the > > fact that they can relicense their code base for proprietary use and > > modification -- they of course can't do that if they start accepting > > outside code. > > > > Oh wait, really? I just read that a second time and understood it for the > first time ... so the free software community is *not* working on Kaffe's > libs? I was under the impression that free software hackers *were* working > on it. I haven't been lurking on their list for a while, though, so perhaps > things have changed. > It is true that Transvirtual holds the copyright on the Kaffe source. Transvirtual requires contributors to sign their copyright over to them. In exchange, people are allowed to access the sources of the open edition (only X11-based awt, no DOS support) and they can use them under a restricted copyright (GPL). A lot of people have found this arrangement acceptable and use Kaffe and have contributed to it. Similarly, contributors to classpath are required to sign the copyright over to the FSF. Unlike the FSF, Transvirtual is a for-profit company. Some people did not find that arrangement acceptable: for instance, Cygnus chose to abandon the GPLed versions of Kaffe for their egcs/gcj project. Instead, they used the last BSD-copyright version of Kaffe to base their Java run-time on, and are in the process of replacing all Kaffe code with code to which Cygnus holds the copyright. Their motives are similar to Transvirtual's. The fact that TVT holds the copyright allows them the rerelease the custom edition under a different, proprietary copyright to paying customers. I don't think anybody cares (and I don't want to start a discussion about this) whether all that means "free software hackers are working on it." > > I am willing to undertake the Kaffe integration project once I am done with > Japhar integration and I am in better contact with the Kaffe development > team (I want to make sure I include any bugfixes they make into my modified > version so that when Classpath goes in, it is perfectly in synch with the > current version of Kaffe). If someone else here knows more about it, it'd Like classpath and japhar, Kaffe provides access to its CVS repository via anonymous CVS. See www.transvirtual.com for details. The sources there are always up-to-date; TVT's improvements usually take 2-4 weeks to get in, contributions by the other developers go in immediately, and bugfixes that people sent to the list are always picked up pretty quickly. > be good for someone *besides* me to do it, so that our knowledge base for VM > integration expands. Two cooks in this case are better than one, as long as > we work together. > > I hope we work with Kaffe rather than shun them. It would be *perfect* if > they decided, once we were stable, to use Classpath as their primary class > libraries. Then they and we would both benefit immensely. > I don't think a decision as to what class libraries Kaffe uses needs to be made. If anybody wrote the VM-layer classpath requires for Kaffe, individual users would be allowed to use the classpath libraries and the Kaffe VM together. They could even redistribute it, although only under the GPL. In fact, I believe that doing that would show how strong the definition of the VM layer actually is. - Godmar
Re: Kaffe as main target ?
"John Keiser" <[EMAIL PROTECTED]> writes: > I just read that a second time and understood it for the > first time ... so the free software community is *not* working on Kaffe's > libs? *sigh* It would have been better for me to have said that free software developers (not counting the ones at Transvirtual) have been focusing more effort towards the Classpath project (as opposed to the Kaffe libs). Unless I've missed something, all major enhancements to the Kaffe libs have been coming from Transvirtual. Random free software hackers have been mainly providing small patches to fix bugs. -- Paul Fisher * [EMAIL PROTECTED]
AWT information?
I am excited, having heard that more people than just Chris are working on the AWT. I know nothing is even ready for beta yet, but could you tell us how you are attacking it and who's working on what, and if anything is ready, how far along you are? I am very hungry for information on AWT. It will be a great boon for the project. I am excited about the whole thing. It looks like things are really coming together. Japhar integration and build procedures are almost done, and now even AWT is on its way! --John Keiser
Re: Kaffe as main target ?
Godmar Back <[EMAIL PROTECTED]> writes: > I would not call the fact that they don't spend their own time and > money doing that "uncooperative". Let me explain what I meant by "uncooperative". Tim is aware of the duplication of resources, but due to Transvirtual's requirements (that is, the ability to relicense) there's going to continue to be a duplication of resources. I see this as unfortunate. I've suggested different proposals for merging our efforts, but none of them were accepted. While I'm sure Transvirutal and the Kaffe community would like to see Classpath work with Kaffe (and I would too), the fact remains that in the end, we're going to have two different free class library implementations. -- Paul Fisher * [EMAIL PROTECTED]
Re: Kaffe as main target ?
Paul Fisher <[EMAIL PROTECTED]> writes: > I really don't see the community's resources as being splintered. > Transvirtual is working on their libs, and free software hackers are > working on the GNU Classpath libs. :) Transvirtual is motivated by the > fact that they can relicense their code base for proprietary use and > modification -- they of course can't do that if they start accepting > outside code. > I was going to respond originally, but here Paul has finally said it, so I'll add my own comments. While sharing Java source seems plausible, it doesn't appear to me to benefit them to share native source, since they want to relicense that for whatever embedded systems folks are interested in buying the Kaffe solution. Since they might want to reorganize their Java source differently than we do, from the point of view of what is native and what is not, then working from the same Java source probably wouldn't work. The only possible thing I see happening is they might open up the Java source as LGPL instead of GPL. This makes sharing possible, though we can't work from the same base. Was looking at the class tree for Swing and the list of things needed. I was hoping it would be slight, instead I realize now it is pretty much everything (except things like Button). Here's a list I just made. Going to be fun to get into this and later into Swing! :) java.awt.AWTEvent java.awt.Component java.awt.Container java.awt.Color java.awt.Panel java.awt.Window java.awt.Dialog java.awt.Frame java.awt.event.ComponentAdapter java.awt.Dimension java.awt.event.ComponentEvent java.awt.event.InputEvent java.awt.event.KeyEvent java.awt.event.MouseEvent java.awt.event.FocusAdapter java.awt.Font java.awt.Graphics java.awt.image.ImageFilter java.awt.image.RGBImageFilter java.awt.Insets java.awt.event.KeyAdapter java.awt.event.MouseAdapter java.awt.event.MouseMotionAdapter java.awt.Rectangle java.awt.event.WindowAdapter java.applet.Applet All the interfaces. Brian -- |---|Software Engineer |Brian Jones|[EMAIL PROTECTED] |[EMAIL PROTECTED]|http://www.nortel.net |http://www.classpath.org/ |--
RE: Kaffe as main target ?
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher > > "John Keiser" <[EMAIL PROTECTED]> writes: > > > un-splintering the community's resources. > > I really don't see the community's resources as being splintered. > Transvirtual is working on their libs, and free software hackers are > working on the GNU Classpath libs. :) Transvirtual is motivated by the > fact that they can relicense their code base for proprietary use and > modification -- they of course can't do that if they start accepting > outside code. > Oh wait, really? I just read that a second time and understood it for the first time ... so the free software community is *not* working on Kaffe's libs? I was under the impression that free software hackers *were* working on it. I haven't been lurking on their list for a while, though, so perhaps things have changed. I'm not too worried ... I think that once Classpath is integrated with Kaffe, Kaffe and Classpath developers alike will be clamoring for a single set of class libraries. We're developers, motivated by what makes sense, not politics. I am willing to undertake the Kaffe integration project once I am done with Japhar integration and I am in better contact with the Kaffe development team (I want to make sure I include any bugfixes they make into my modified version so that when Classpath goes in, it is perfectly in synch with the current version of Kaffe). If someone else here knows more about it, it'd be good for someone *besides* me to do it, so that our knowledge base for VM integration expands. Two cooks in this case are better than one, as long as we work together. I hope we work with Kaffe rather than shun them. It would be *perfect* if they decided, once we were stable, to use Classpath as their primary class libraries. Then they and we would both benefit immensely. --John Keiser
Free Java @ JavaOne 1999
All, Don't know if anyone else is looking into this but we'd like to put together a free Java BOF at the coming JavaOne and obviously it'd make sense to get all the free Java people together for this. We've tried to do this informally the last two years (they confiscated the megaphone last year) but though we might try to get it into the official program this year. Any interest? Regards Tim -- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA.Email: [EMAIL PROTECTED]
RE: Kaffe as main target ?
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher > > > "John Keiser" <[EMAIL PROTECTED]> writes: > > > I like the idea of borrowing Kaffe's AWT (you didn't say it > > specifically, but it makes the most sense), simply because no one > > has worked on it here > > There are three GNU Classpath people actively working on an AWT > implementation in GTK+ -- Jim Blair, Chris Toshok, and myself. GNU > Classpath's AWT will be compatible with Gnome. We've been making > progress on a daily basis. > Oh, I was unaware anyone other than Chris was working on it. Cool, no need to deal with Kaffe. > > and theirs is very portable > > I was under the impression that their free AWT is based on low-level > X11 calls. (that is, their proprietary DOS version is custom) > Really? Parts of that thing are non-GPL? > > *including* Windows and DOS. > > GTK+ has been ported to Windows. Of course, porting to any > proprietary operating system (especially ones that are extremely > different from GNU systems) will never be a primary focus of the > Classpath project. > Never is a strong word for a free software project. It depends *entirely* on the priorities of the developers. If I am still working on Classpath, Windows *will* be a primary OS once we get Unix fairly stable--that is, the porting team will be actively releasing source into the main tree. That's probably 4-5 months off, though, at the least. Please, though, let's not get back into this argument yet, as it is divisive and absolutely unnecessary until Classpath is stable and complete on Unix/X, and really the definition of "primary focus" won't apply until Windows is *also* complete and stable. So let's wait until I put my money where my mouth is before we argue about this :) > > un-splintering the community's resources. > > I really don't see the community's resources as being splintered. > Transvirtual is working on their libs, and free software hackers are > working on the GNU Classpath libs. :) Transvirtual is motivated by the > fact that they can relicense their code base for proprietary use and > modification -- they of course can't do that if they start accepting > outside code. > So has Tim been blowing you off when you talk about this, or are you not interested in working with them? I personally don't care yet, we have too much work to do to deal with any of this political crap. I figure it will all hit the fan when we port to Kaffe; *then* we find out what the fallout is. I think many Kaffe developers will move over to Classpath at that point if the two class libraries have not yet combined. Is Tim still lurking on this list? Maybe he can shed some light on what is and isn't GPL in Kaffe, and why we aren't working together. Final question: does anyone here know just how active the Kaffe classlib development team is? Are they still doing work? > -- > Paul Fisher * [EMAIL PROTECTED] > >
Re: Kaffe as main target ?
> > Artur Biesiadowski <[EMAIL PROTECTED]> writes: > > > Maybe kaffe could be used instead ? It is a lot more stable, faster, > > has free java library that can be used to fill gaps (in other case > > we need to fill gaps with JDK classlib). > > One of the great benefits of using Japhar is that we're making it more > stable. Unlike using Sun's classes.zip, when we find a bug, we can > easily track down the part of Japhar that's broken and implement a fix > (or just bug toshok to fix it). The fact that Japhar is slower than > Kaffe is a non-issue. Japhar does work. > > We plan to eventually support Kaffe, but I don't see a need to make > that our primary testing/release platform. Transvirtual has been > generally uncooperative regarding overlap of work between their class > libraries and ours. Except for the AWT, we have much more > functionality that their class libraries. > I can't speak for Transvirtual, but I can tell you what they told me and what my impression is. First of all, you will have to acknowledge the fact that Transvirtual is a company that allows others to use their work under a restricted copyright (GPL). They have been supportive to their (non-paying) users, they also have gotten a substantial amount back. Contributions and bug fixes from users generally make their way into the public tree quickly, usually within a matter of days. The have obligations to their customers, and one of them is to support their class libraries (that they wrote and understand). From that point of view, it makes sense for them to keep using them. The other question is whether they devote resources to the classpath integration. They do not, and the only reason they do not is because they don't have the resources. If somebody implemented the VM layer classpath requires for Kaffe, I'm sure this undertaking would find their approval and the support of the Kaffe community. I would not call the fact that they don't spend their own time and money doing that "uncooperative". In fact, I believe that such undertaking would benefit both classpath and kaffe. - Godmar
Re: Kaffe as main target ?
"John Keiser" <[EMAIL PROTECTED]> writes: > I like the idea of borrowing Kaffe's AWT (you didn't say it > specifically, but it makes the most sense), simply because no one > has worked on it here There are three GNU Classpath people actively working on an AWT implementation in GTK+ -- Jim Blair, Chris Toshok, and myself. GNU Classpath's AWT will be compatible with Gnome. We've been making progress on a daily basis. > and theirs is very portable I was under the impression that their free AWT is based on low-level X11 calls. (that is, their proprietary DOS version is custom) > *including* Windows and DOS. GTK+ has been ported to Windows. Of course, porting to any proprietary operating system (especially ones that are extremely different from GNU systems) will never be a primary focus of the Classpath project. > un-splintering the community's resources. I really don't see the community's resources as being splintered. Transvirtual is working on their libs, and free software hackers are working on the GNU Classpath libs. :) Transvirtual is motivated by the fact that they can relicense their code base for proprietary use and modification -- they of course can't do that if they start accepting outside code. -- Paul Fisher * [EMAIL PROTECTED]
RE: Kaffe as main target ?
I believe that once we port to Kaffe we will see cooperation on the class libraries. I am curious, though, what specifically have we done better? The only thing I can think of is that our stuff has more doc comments ... and we have 1.2 java.util. I do suggest that whoever works on AWT look at their implementation at least; it would be really nice to have Classpath work on multiple platforms by default. This is Java, after all, even if we can't use the name. --John Keiser > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher > Sent: Wednesday, October 21, 1998 9:57 AM > To: [EMAIL PROTECTED] > Subject: Re: Kaffe as main target ? > > > Artur Biesiadowski <[EMAIL PROTECTED]> writes: > > > Maybe kaffe could be used instead ? It is a lot more stable, faster, > > has free java library that can be used to fill gaps (in other case > > we need to fill gaps with JDK classlib). > > One of the great benefits of using Japhar is that we're making it more > stable. Unlike using Sun's classes.zip, when we find a bug, we can > easily track down the part of Japhar that's broken and implement a fix > (or just bug toshok to fix it). The fact that Japhar is slower than > Kaffe is a non-issue. Japhar does work. > > We plan to eventually support Kaffe, but I don't see a need to make > that our primary testing/release platform. Transvirtual has been > generally uncooperative regarding overlap of work between their class > libraries and ours. Except for the AWT, we have much more > functionality that their class libraries. > > -- > Paul Fisher * [EMAIL PROTECTED] > >
Re: Kaffe as main target ?
Artur Biesiadowski <[EMAIL PROTECTED]> writes: > Maybe kaffe could be used instead ? It is a lot more stable, faster, > has free java library that can be used to fill gaps (in other case > we need to fill gaps with JDK classlib). One of the great benefits of using Japhar is that we're making it more stable. Unlike using Sun's classes.zip, when we find a bug, we can easily track down the part of Japhar that's broken and implement a fix (or just bug toshok to fix it). The fact that Japhar is slower than Kaffe is a non-issue. Japhar does work. We plan to eventually support Kaffe, but I don't see a need to make that our primary testing/release platform. Transvirtual has been generally uncooperative regarding overlap of work between their class libraries and ours. Except for the AWT, we have much more functionality that their class libraries. -- Paul Fisher * [EMAIL PROTECTED]
Re: javadeps diff
I'll take a look at getting those exception classes done. They are usually pretty easy. And yes, I'll even document them. Brian -- |---|Software Engineer |Brian Jones|[EMAIL PROTECTED] |[EMAIL PROTECTED]|http://www.nortel.net |http://www.classpath.org/ |--
RE: Kaffe as main target ?
Kaffe is #2 priority on the list, mainly because of the Japhar+Classpath's relationship to one another (started out as one project and split into two for modularity reasons). The point you make is good and valid, though. This port is nearly done, and with the knowledge we gain from doing it, Kaffe will take very little time. Japhar is definitely stable enough now to support our classes, so I don't see a big problem here. I like the idea of borrowing Kaffe's AWT (you didn't say it specifically, but it makes the most sense), simply because no one has worked on it here and theirs is very portable (my goal is to get this thing fully working on all Japhar's platforms *and* all Kaffe's platforms, *including* Windows and DOS. Modifications would need to be made so that it doesn't use Sun's private/protected field names anymore (I have a real problem with that, and Sun might be able to make a fuss too). Ideally, when we achieve portability with Kaffe, they would fold Classpath in completely and take the best parts of both, and then both Kaffe's class library developers and Classpath's would work on the class library together, un-splintering the community's resources. Then again, it might simply not happen that way if either of us get too attached to our code. I sincerely hope that does not happen. I have no desire to see a fight. --John Keiser > -Original Message- > From: Artur Biesiadowski [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 21, 1998 3:15 AM > To: [EMAIL PROTECTED] > Subject: Kaffe as main target ? > > > Classpath seems to focus on japhar as main release/testing platform. I > understand that japhar needs core library, but I don't think that it is > best place to test it. Maybe kaffe could be used instead ? It is a lot > more stable, faster, has free java library that can be used to fill gaps > (in other case we need to fill gaps with JDK classlib). Did anybody make > a move in that direction ? > > Artur > > >
RE: javadeps diff
classes.zip will not be completely independent until we can get Math,
Float, Double, PutField, GetField, and most of the exceptions done. I
picked up a lot of the classes I compiled against from the 1.1.5 classes.zip
and the 1.2beta4 classes.zip, at different times. Some I compiled with
javac, some with guavac, and some Jon Zeppieri compiled for me (java.util).
The current classes.zip is a hodgepodge. I just needed something to work
with.
We need at least these to be complete if we don't try to compile
java.security (these are the only ones I know of):
- Complete Math, Float and Double. Paul is working on these.
- ObjectInputStream.GetField, ObjectOutputStream.PutField. Geoff Berry
is working on these.
- The Exceptions. *No one is working on these. We need a volunteer!*
The root of the hierarchy is dealt with, so there should be no intense work
with stack traces or anything like that. Now it's just a matter of fleshing
out the classes.
Nicely done, Brian, the work with java.lang makes sense.
--John Keiser
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Brian Jones
> Sent: Wednesday, October 21, 1998 6:15 AM
> To: [EMAIL PROTECTED]
> Subject: javadeps diff
>
>
> Okay, for anyone wanting the two small fixes I've hacked into JavaDeps
> I'm letting this diff loose. The unicode \r thing fix was to trick
> the parser to not bail. I was probing around the areas where classes
> are added to a directed graph and noticed the java.lang stuff seemed
> missing. Don't flame what I did too much, I didn't get to take the
> parser class in school. ;)
>
> John, could you email me a list of the classes you have in your zip?
> This should be a set of classes which do not have any reliance on any
> other classes not inside the zip.
>
> Brian
>
> diff -uNr smr.orig/JavaDeps/ASCII_UCodeESC_CharStream.java
> smr/JavaDeps/ASCII_UCodeESC_CharStream.java
> --- smr.orig/JavaDeps/ASCII_UCodeESC_CharStream.java Mon May 18
> 22:30:21 1998
> +++ smr/JavaDeps/ASCII_UCodeESC_CharStream.java Mon Oct 19
> 23:19:17 1998
> @@ -242,6 +242,7 @@
>
>static public final char readChar() throws java.io.IOException
>{
> +int saw_r = 0;
> if (inBuf > 0)
> {
> --inBuf;
> @@ -286,7 +287,6 @@
> {
>if (backSlashCnt > 1)
> backup(backSlashCnt);
> -
>return '\\';
> }
>
> @@ -294,6 +294,7 @@
> backSlashCnt++;
> }
>
> +saw_r = 0;
> // Here, we have seen an odd number of backslash's
> followed by a 'u'
> try
> {
> @@ -306,7 +307,11 @@
> hexval((char)((char)0xff
> & ReadByte(;
>
> column += 4;
> -}
> + if (c == '\r')
> + {
> +saw_r = 1;
> + }
> + }
> catch(java.io.IOException e)
> {
> throw new Error("Invalid escape character at line " + line +
> @@ -314,11 +319,18 @@
> }
>
> if (backSlashCnt == 1)
> - return c;
> + {
> +if ((saw_r == 1) && (c == '\r'))
> + {
> + return 'r';
> + }
> + return c;
> +
> + }
> else
> {
> - backup( - 1);
> - return '\\';
> + backup(backSlashCnt - 1);
> + return '\\';
> }
> }
> else
> -uNr smr.orig/JavaDeps/DepTable.java smr/JavaDeps/DepTable.java
> --- smr.orig/JavaDeps/DepTable.java Mon May 18 18:37:10 1998
> +++ smr/JavaDeps/DepTable.javaWed Oct 21 08:53:49 1998
> @@ -143,6 +143,7 @@
>
> /**
> * As above, but also checks that the TargetNode is of the
> required type.
> + * brian - need to determine if/when/how lookups work for
> EmptyStackTraceException -> RunTimeException, I bet they don't.
> **/
> private TargetNode lookupSymbol( String s, int type )
> {
> @@ -197,6 +198,7 @@
>
> imports = new Hashtable();
> wildImports = new Vector();
> + wildImports.addElement("java.lang");
> }
>
> /**
> @@ -222,6 +224,7 @@
> String suffix = .substring( i+1 );
>
> if ( suffix.equals( "*" ) ) {
> + if (prefix.compareTo("java.lang") != 0)
> wildImports.addElement( prefix );
> } else {
> imports.put( suffix, iname );
> diff -uNr smr.orig/JavaDeps/JavaDeps.java smr/JavaDeps/JavaDeps.java
> --- smr.orig/JavaDeps/JavaDeps.java Mon May 18 22:49:55 1998
> +++ smr/JavaDeps/JavaDeps.javaTue Oct 20 00:14:30 1998
> @@ -130,6 +130,8 @@
> if ( po.seenOption( "native" ) ) {
> if
ubs".equalsIgnoreCase( po.getOptionArgument(
> "native" )))
> buildStubs = true;
> + else
> + buildStubs = false;
> } else {
> headerBuildCommand = null;
> }
>
>
> (and in case the mhonarc web thingy screws up the above)
>
> begin-base64 64
javadeps diff
Okay, for anyone wanting the two small fixes I've hacked into JavaDeps
I'm letting this diff loose. The unicode \r thing fix was to trick
the parser to not bail. I was probing around the areas where classes
are added to a directed graph and noticed the java.lang stuff seemed
missing. Don't flame what I did too much, I didn't get to take the
parser class in school. ;)
John, could you email me a list of the classes you have in your zip?
This should be a set of classes which do not have any reliance on any
other classes not inside the zip.
Brian
diff -uNr smr.orig/JavaDeps/ASCII_UCodeESC_CharStream.java
smr/JavaDeps/ASCII_UCodeESC_CharStream.java
--- smr.orig/JavaDeps/ASCII_UCodeESC_CharStream.javaMon May 18 22:30:21 1998
+++ smr/JavaDeps/ASCII_UCodeESC_CharStream.java Mon Oct 19 23:19:17 1998
@@ -242,6 +242,7 @@
static public final char readChar() throws java.io.IOException
{
+int saw_r = 0;
if (inBuf > 0)
{
--inBuf;
@@ -286,7 +287,6 @@
{
if (backSlashCnt > 1)
backup(backSlashCnt);
-
return '\\';
}
@@ -294,6 +294,7 @@
backSlashCnt++;
}
+saw_r = 0;
// Here, we have seen an odd number of backslash's followed by a 'u'
try
{
@@ -306,7 +307,11 @@
hexval((char)((char)0xff & ReadByte(;
column += 4;
-}
+ if (c == '\r')
+{
+ saw_r = 1;
+}
+ }
catch(java.io.IOException e)
{
throw new Error("Invalid escape character at line " + line +
@@ -314,11 +319,18 @@
}
if (backSlashCnt == 1)
- return c;
+ {
+if ((saw_r == 1) && (c == '\r'))
+ {
+ return 'r';
+ }
+ return c;
+
+ }
else
{
- backup( - 1);
- return '\\';
+ backup(backSlashCnt - 1);
+ return '\\';
}
}
else
-uNr smr.orig/JavaDeps/DepTable.java smr/JavaDeps/DepTable.java
--- smr.orig/JavaDeps/DepTable.java Mon May 18 18:37:10 1998
+++ smr/JavaDeps/DepTable.java Wed Oct 21 08:53:49 1998
@@ -143,6 +143,7 @@
/**
* As above, but also checks that the TargetNode is of the required type.
+ * brian - need to determine if/when/how lookups work for
+EmptyStackTraceException -> RunTimeException, I bet they don't.
**/
private TargetNode lookupSymbol( String s, int type )
{
@@ -197,6 +198,7 @@
imports = new Hashtable();
wildImports = new Vector();
+ wildImports.addElement("java.lang");
}
/**
@@ -222,6 +224,7 @@
String suffix = .substring( i+1 );
if ( suffix.equals( "*" ) ) {
+ if (prefix.compareTo("java.lang") != 0)
wildImports.addElement( prefix );
} else {
imports.put( suffix, iname );
diff -uNr smr.orig/JavaDeps/JavaDeps.java smr/JavaDeps/JavaDeps.java
--- smr.orig/JavaDeps/JavaDeps.java Mon May 18 22:49:55 1998
+++ smr/JavaDeps/JavaDeps.java Tue Oct 20 00:14:30 1998
@@ -130,6 +130,8 @@
if ( po.seenOption( "native" ) ) {
if ( "stubs".equalsIgnoreCase( po.getOptionArgument( "native" )))
buildStubs = true;
+ else
+ buildStubs = false;
} else {
headerBuildCommand = null;
}
(and in case the mhonarc web thingy screws up the above)
begin-base64 644 javadeps.diff
ZGlmZiAtdU5yIHNtci5vcmlnL0phdmFEZXBzL0FTQ0lJX1VDb2RlRVNDX0No
YXJTdHJlYW0uamF2YSBzbXIvSmF2YURlcHMvQVNDSUlfVUNvZGVFU0NfQ2hh
clN0cmVhbS5qYXZhCi0tLSBzbXIub3JpZy9KYXZhRGVwcy9BU0NJSV9VQ29k
ZUVTQ19DaGFyU3RyZWFtLmphdmEJTW9uIE1heSAxOCAyMjozMDoyMSAxOTk4
CisrKyBzbXIvSmF2YURlcHMvQVNDSUlfVUNvZGVFU0NfQ2hhclN0cmVhbS5q
YXZhCU1vbiBPY3QgMTkgMjM6MTk6MTcgMTk5OApAQCAtMjQyLDYgKzI0Miw3
IEBACiAKICAgc3RhdGljIHB1YmxpYyBmaW5hbCBjaGFyIHJlYWRDaGFyKCkg
dGhyb3dzIGphdmEuaW8uSU9FeGNlcHRpb24KICAgeworICAgIGludCBzYXdf
ciA9IDA7CiAgICAgIGlmIChpbkJ1ZiA+IDApCiAgICAgIHsKICAgICAgICAg
LS1pbkJ1ZjsKQEAgLTI4Niw3ICsyODcsNiBAQAogICAgICAgICAgICB7CiAg
ICAgICAgICAgICAgIGlmIChiYWNrU2xhc2hDbnQgPiAxKQogICAgICAgICAg
ICAgICAgICBiYWNrdXAoYmFja1NsYXNoQ250KTsKLQogICAgICAgICAgICAg
ICByZXR1cm4gJ1xcJzsKICAgICAgICAgICAgfQogCkBAIC0yOTQsNiArMjk0
LDcgQEAKICAgICAgICAgICAgYmFja1NsYXNoQ250Kys7CiAgICAgICAgIH0K
IAorICAgICAgICBzYXdfciA9IDA7CiAgICAgICAgIC8vIEhlcmUsIHdlIGhh
dmUgc2VlbiBhbiBvZGQgbnVtYmVyIG9mIGJhY2tzbGFzaCdzIGZvbGxvd2Vk
IGJ5IGEgJ3UnCiAgICAgICAgIHRyeQogICAgICAgICB7CkBAIC0zMDYsNyAr
MzA3LDExIEBACiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBoZXh2YWwoKGNoYXIpKChjaGFyKTB4ZmYgJiBSZWFkQnl0ZSgpKSkp
OwogCiAgICAgICAgICAgIGNvbHVtbiArPSA0OwotICAgICAgICB9CisgICAg
ICAgICAgIGlmIChjID09ICdccicpCisJICAgICB7CisJICAgICAgIHNhd19y
ID0gMTsKKwkgICAgIH0KKwl9CiAgICAgICAgIGNhdGNoKGphdmEuaW8uSU9F
eGNlcHRpb24gZSkKICAgICAgICAgewogICAgICAgICAgICB0aHJvdyBuZXcg
RXJyb3Io
Kaffe as main target ?
Classpath seems to focus on japhar as main release/testing platform. I understand that japhar needs core library, but I don't think that it is best place to test it. Maybe kaffe could be used instead ? It is a lot more stable, faster, has free java library that can be used to fill gaps (in other case we need to fill gaps with JDK classlib). Did anybody make a move in that direction ? Artur
java.net
On the off chance anyone is using java.net, I just updated the files in CVS so that they no longer use stubs. This means that you will need to have a recent version of Japhar configured with "--enable-libffi=true". For now stubs are a major pain, but we will probably have to conditionally add them back in order to support platforms that libffi doesn't support. (Which ones are those?). -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
