Re: org.omg link on Classpath homepage
Stuart Ballard <[EMAIL PROTECTED]> writes: > There is a link to http://www.omg.org/ on Classpath's homepage, > referencing it as a "provider for free core packages" for the org.omg > packages. I have a few questions about this: > > 1) I can't actually find any downloadable implementation of the > org.omg packages in the omg site. It might be helpful to provide a > more direct link to exactly where the code can be found. They are on the ftp site, probably not obvious. >b) If they are free but aren't GPL-compatible, shouldn't there be a > prominent warning because (if I understand the issues correctly) that > would make anything that's simultaneously a derived work of Classpath > and the org.omg packages completely unredistributable? Basically they will never be free to modify because the entire point of the OMG standard is these interfaces DO NOT CHANGE or change only as the standard evolves at the whim of the standards body. The GPL doesn't allow compatibility with licenses that do not permit modification. All of that said, I pursued getting the OMG responsible people to change the license and I think they saw why we needed this and at least in some sense were sympathetic but the overriding concern is that of interoperability and hence there was no change. It doesn't mean that going back to them now couldn't change the appropriate minds just that I didn't get very far except that it was on the agenda for one of the quarterly meetings as far as I know and I never got another response. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Per Bothner wrote: I don't think so. Classpath uses GPL+exception and can be linked with proprietary applications. So someone could almost certainly distribute Classpath + org.omg. You're right. I should have said "Free but aren't GPL+exception-compatible". I'm not sure whether such a thing is possible - if not, obviously the point is moot and we're just left with "free or not". Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath initialization
Hi! Initializing a JVM is quite a complicated thing. Many problems depend on which class you first initialize, because this could cause unexpected dependecies to pop up. Jaos doesn't suffer from the problem you descrive, because it doesn't use the external libraries or JNI: Oberon is rather close to Java, and the objects can be directly accessed from both languages without fear of breaking the type system or confusing the garbage collector. I also had my share of problems with the system properties, because they are hard-coded in the libraries and I didn't realize it at once. Furthermore, the properties and java.io assume an unix-like filesystem, which Oberon doesn't have: we don't have directories, only mounts. In Jaos, I explicitely initialize a few classes during bootstrap (this are only the explicit calls, other classes may be automatically initialized as side effect, and in fact about 80 are!). This code relies on classpath 0.5 (I'm not through updating yet). 1. String 2. Throwable 3. StackTraceElement 4. VMThrowable 5. Thread 6. ThreadGroup 7. System This may look strange, but 1. String is implicitely used everywhere, because the string constants are instances of this class; according to the spec, allocating an instance of a class causes the class to be initialized. (I could avoid this, but then I would have to protect every access to the string methods with a check to launch initialization; Strings are already slow enough in Jaos). 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when the VM is launched: loading them on-demand (at the first exception) is already too late, because the VM is already processing an exception (in Oberon this is done with a software interrupt) and loading reads from the disc (causing more interrupts), but the kernel doesn't allow to interrupt handler to cause other interrupts. 3. Thread / ThreadGroup must be initialized, because every java program is executed in a java thread; Jaos creates such a thread for the execution of a java program. This remarks (in particular 2 and 3) are quite Jaos specific. This won't probably solve your problem, but may give you some insight about the various problems encountered during the initialization phase. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos - Original Message - From: "Joseph Wenninger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 14, 2003 9:33 PM Subject: classpath initialization > Hi > > I'm trying to use an unmodified classpath (0.06). I already have > something working with a modified one. > > My problem is that the call stack during initialization of the System > class I looks something like > > LOG: called: java/lang/System.()V() > LOG: called: > java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) > LOG: called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;() > LOG: finished: > java/lang/Runtime.getRuntime()Ljava/lang/Runtime;->0x8420fd8 > LOG: called: > java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488) > LOG: called: > java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;() > LOG: called: java/lang/ClassLoader.()V() > LOG: compiler_addinitclass: java/lang/VMClassLoader > LOG: called: > java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;() > LOG: called: > java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang /String;(405cb500, 405cb578) > ()V > The last line causes an exception, since the static member properties > isn't initialized yet. Did anybody else encounter such a problem ? I'm > not sure if that it is a vm bug or a compiler problem or something that > I miss > > Kind regards > Joseph Wenninger > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard wrote: b) If they are free but aren't GPL-compatible, shouldn't there be a prominent warning because (if I understand the issues correctly) that would make anything that's simultaneously a derived work of Classpath and the org.omg packages completely unredistributable? I don't think so. Classpath uses GPL+exception and can be linked with proprietary applications. So someone could almost certainly distribute Classpath + org.omg. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
org.omg link on Classpath homepage
There is a link to http://www.omg.org/ on Classpath's homepage, referencing it as a "provider for free core packages" for the org.omg packages. I have a few questions about this: 1) I can't actually find any downloadable implementation of the org.omg packages in the omg site. It might be helpful to provide a more direct link to exactly where the code can be found. 2) Last I heard, there were some questions about the freeness and/or GPL compatibility of the OMG's license. If that has changed and their classes are clearly unambiguously free and GPL compatible, wouldn't it be a good idea to include them directly in Classpath's CVS? And if not... a) If they're not free, isn't it a violation of GNU project policy to link to them at all - ESPECIALLY without prominently stating that they're not free? b) If they are free but aren't GPL-compatible, shouldn't there be a prominent warning because (if I understand the issues correctly) that would make anything that's simultaneously a derived work of Classpath and the org.omg packages completely unredistributable? If they *are* free and GPL-compatible but simply not included in Classpath's CVS, it would be nice if whoever's producing japi files these days would include them in Classpath's japi: That would probably increase the number of green packages substantially[1]! :) Stuart. [1] Classpath vs JDK1.2 is currently red in only two places: javax.swing and org.omg. You could cut that in half :) -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu inetlib initial submission
Joe Phillips wrote: > > i've checked the first set of contributions to the inetlib project into > > cvs. this includes: > > > > - an ftp client and URLConnection > > Chris, > > How full-blown is this client? I have a full-blown FTP client I > contacted Nick about contributing quite some time ago. I'd be willing > to contribute what I can. > > I developed it as a base class for a HylaFAX client. Since I was > planning to contribute it to Classpath, I took extra care to implement > most/all of RFC959 and some extensions. from the api documentation: This implements RFC 959, with the following exceptions: * STAT, HELP, SITE, SMNT, and ACCT commands are not supported. * the TYPE command does not allow alternatives to the default bytesize (Non-print), and local bytesize is not supported. it's been tested using active/passive mode and MODE STREAM. i have been unable thus far to locate a free ftp server that supports modes BLOCK and COMPRESSED to test these. it doesn't support any extensions; contributions would be most welcome, subject to all the legal whatnot. btw, by “client” i mean a client connection object, not a user-agent. -- chris burdess pgp0.pgp Description: PGP signature ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu inetlib
On Mon, 2003-10-20 at 12:28, chris burdess wrote: > from the api documentation: > > This implements RFC 959, with the following exceptions: >* STAT, HELP, SITE, SMNT, and ACCT commands are not supported. >* the TYPE command does not allow alternatives to the default bytesize > (Non-print), and local bytesize is not supported. > > it's been tested using active/passive mode and MODE STREAM. i have been > unable thus far to locate a free ftp server that supports modes BLOCK and > COMPRESSED to test these. I'm pretty sure HylaFAX does COMPRESSED. I recall adding compression at one point. > it doesn't support any extensions; contributions would be most welcome, > subject to all the legal whatnot. ok. I'll check out your CVS. > btw, by “client” i mean a client connection object, not a user-agent. same here. I mean I have an FTP protocol implementation in Java object form. I do not have a GUI or command-line program "user-agent". I have very simple test-case type command line programs to test my HylaFAX functionality. My classes have been pretty extensively tested against HylaFAX server but I'm not aware of many FTP-only users. Just today I was contacted by someone claiming he uses my classes to send over 3000 FAXes per day without problems. At a past contract, an intern was paid to make the FTP portion 'speak' with an IBM mainframe FTP server. I don't recall if we've used BLOCK yet. We should compare notes and I'll contribute what I can. A month or so ago I checked out CVS and started to look at patching Classpath. What timing. The hold-up for me patching Classpath was that I didn't quite know how to test it. I currently use non-free JDKs from Sun & IBM and am not in the position to sink a lot of time into getting a free JDK working. Is there an easy way to test a custom build of Classpath? "easy" for me would be defined as either using Sun or IBMs JDK *or* a GCJ from Debian. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com Custom Internet and Computer Solutions Linux, UNIX, Java Training signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu inetlib initial submission
On Sun, 2003-10-19 at 05:05, chris burdess wrote: > i've checked the first set of contributions to the inetlib project into > cvs. this includes: > > - an ftp client and URLConnection Chris, How full-blown is this client? I have a full-blown FTP client I contacted Nick about contributing quite some time ago. I'd be willing to contribute what I can. I developed it as a base class for a HylaFAX client. Since I was planning to contribute it to Classpath, I took extra care to implement most/all of RFC959 and some extensions. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com Custom Internet and Computer Solutions Linux, UNIX, Java Training signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 18. Oktober 2003 22:24 schrieb Brian Jones: > Guilhem Lavaux <[EMAIL PROTECTED]> writes: > > If there is anything I can personally do to make sure the > > contributions from kaffe developers make their way back into > > Classpath, I'd appreciate hearing about it. I guess we should > > just talk to each other more often ;) > > Other than more people with more time to spend on reviewing and > commiting patches, I don't know. I find it a tad difficult to > evaluate some patches without test cases. My testcases are in Mauve. Michael. - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/k4wQWSOgCCdjSDsRAraAAKChbd0UKj6LRvuUquKftkXmlXJW6gCdHMrM 8Jj64HMtYEp0XJr+ktOyRVU= =wcHi -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
