Classpath and org.omg.*
Folks, If >>all<< we have to do to keep GNU / FSF happy for now is to remove the link to the OMG from the website, lets just do it. I hardly think this is a major issue. In the long term though, there is a bigger problem looming. At some point, Classpath needs to support the org.omg.* classes. Without them, you cannot run CORBA ORBs and CORBA-based applications over Classpath. This includes free Java ORBs and free J2EE platforms. Before proceeding, we need some background on the OMG and their way of thinking. [My employer (DSTC) is a current member of the OMG. In the past, I've done a lot of work for DSTC on OMG standard submissions and revisions. (MOF & XMI if anyone is interested.) As a consequence, I've learned a fair bit about the processes and politics of the OMG. I've also done a lot of CORBA-based product development in Java.] The critical org.omg.* classes are the Java interfaces for the OMG's CORBA-to-Java and Java-to-CORBA mappings. These interfaces are an integral part of the respective standards. They NOT implementations of the standard. There are other org.omg.* classes as well, but they are not published by the OMG. Instead, the OMG publishes the IDL from which they can be generated using an IDL->Java compiler. The reason the critical Java interfaces are part of the standard mappings is to enable binary compatibility between different CORBA for Java platforms. This allows someone to write CORBA based applications for one Java ORB platform and have them run on other platforms without recompilation. To achieve this aim, it is necessary for the interfaces be the same on all ORB platforms. The main reason for the OMG's copyright notice forbidding changes is to prevent ORB vendors from slipping in extensions and the like that would destroy cross-vendor binary compatibility. This kind of thing has happened in the past, and it causes major problems for people who write multi-platform software. (Like when the 'org.omg.*' interfaces in a Sun JDK didn't comply with the OMG standard, and the "Visibroker for Java" ORB had its own clean copy of the 'org.omg.*' classes that you had to put on the bootclasspath ...) IMO, it is a GOOD THING that the OMG defends the integrity of these interfaces as best they can. It so happens that they have decided that a restrictive copyright notice is their most effective tool for doing this. They are probably right. [You may disagree, but then you need to understand the nature of the organisation and its relationship with the ORB vendors.] While OMG staffers are generally supportive of Open Source (AFAIK), they are >>not<< going to be persuaded to do things that openly undermine the integrity of the CORBA standards. It would be against the interest of the OMG's 700+ member organisations, and the OMG Board would stomp on them with big boots. So where does this leave the Classpath project in the long term? * In the long run, we cannot leave out the org.omg.* interfaces. They are an important part of the J2SE & J2EE platform APIs. * We should not try provide a clean-room version of the OMG's org.omg.* interfaces. AFAIK, there is insufficient public information (apart from the OMG's copyrighted interfaces) to allow this. Besides we'd risk being incompatible with other Java implementations and/or Java ORBs and Java/CORBA applications. In other words we'd be potentially subverting the CORBA standard. This would be a BAD THING. * We could try to persuade the FSF to allow a specific exception for non-FREE code provided by standards organisations like the OMG. I cannot see that FSF intends to undermine open standards by removing their ability to protect integrity via copyrights. If this and other possible alternatives fail, we may eventually need to take steps to disassociate Classpath from GNU. That would be a shame. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath initialization
In Jaos, the ClassLoader is loaded but not really used (I'm still stuck with classpath 0.5) because I have my own native implementation which overrides the calls to Java's classloader in Class.fromName(). I'm currently upgrading my implementation to work with 0.6 by moving all the native stuff into the VM classes, but haven't got that far yet (it's a lot of work!) -Patrik > For comparison, Wonka's explicit class initialisation looks something like > this: > ** 1) load class java/lang/Object. > ** 2) load java/lang/Cloneable, java/lang/Serializable, > java/lang/Throwable. > ** 3) create clazz_Array. clazz_Array acts like clazzObject but has > ** a modified method table and a modified interfaces table. > ** It overrides the clone method of java/lang/Object and adds two > ** new interfaces: Cloneable and Serializable. > ** (We need to do this before any subclasses of Throwable are loaded, > ** in order to ensure that they are marked CLAZZ_IS_THROWABLE). > ** 4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread, > ** java/lang/ThreadGroup, and java/lang/ref/Reference. > ** 5) load all the classes mentioned in core-classes.in. > ** 6) For each primitive class xxx, create: > ** -An instance Class_xxx of class java/lang/Class, linked to > **a w_Clazz structure (clazz_xxx). > **The name associated with the Class instance is "xxx.class". > ** -Entries in the array atype2clazz[], which is indexed by P_xxx. > > Step 5) is needed because we need to create explicit relationships between C > and Java constructs for quite a large number of classes, which Patrik doesn't > need to do because he's using Oberon. I guess that's also why he doesn't need > to explicitly load ClassLoader; we need to do that because of all the > behind-the-scenes stuff needed to implement class loading according to the > JVM spec. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes: Dalibor> It makes my back-merging work harder, as kaffe already uses the Dalibor> patches submitted by Guilhem to the Classpath bug tracker. See Dalibor> http://savannah.gnu.org/bugs/?group=classpath for an overview. I'd Dalibor> like to suggest reviewing those patches, and then deciding on merging Dalibor> them in or whether another implementation of those aspects of Dalibor> java.text is necessary. That sounds sensible to me. Whenever I review patches, it really helps if they follow certain rules. It's easiest if each logical change is a separate patch, if the patches are uni- or context-diff (not a problem in this case, but sometimes people post plain diffs, which are unreadable), if there is a ChangeLog entry. In the best case there's also a Mauve test. If any of these things are missing, I tend to put off review, as it means more work for me... (e.g., sometimes I've rewritten tests into Mauve format. This gets old). (I know this is nothing you don't already know, since we've discussed it several times on irc, so I'm writing for the non-irc-using audience... :) Dalibor> If there is anything I can personally do to make sure the Dalibor> contributions from kaffe developers make their way back into Dalibor> Classpath, I'd appreciate hearing about it. I think the best case scenario is that the kaffe developers end up with write access to Classpath, just like developers who work on other VMs. I do think that at some point we should tighten Classpath commit rules a bit. I'm afraid this will be an unpopular move, but it does seem important. For instance, we could require an approval for every patch (but still leave committing up to the author). Or we could require a test case for every patch (with the ability to ask for an exception, since sometimes this isn't possible). Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Bug Report: unexpected IllegalArgumentException from java.text.DecimalFormat
> "Ito" == Ito Kazumitsu <[EMAIL PROTECTED]> writes: Ito> Which is not the case with Sun's JDK. Ito> In the kaffe world, I applied the following patch: Could you make your test case suitable for Mauve? How about we give you mauve write access and then you can just check it in? And then you can check in future tests too :-). If this sounds good, fill out this form and give my email address in the appropriate field: http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi I'm ok with the patch, though it needs a ChangeLog entry. I've noticed more patches coming from the kaffe world, which is really great. I'd like to get you (and the other kaffe developers) direct cvs write access, so that we can lower the barriers to getting these fixes checked in. Assuming this is ok with Mark and everybody else, of course. Otherwise, send me a ChangeLog entry and I'll check this in. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Bug Report: unexpected IllegalArgumentException from java.text.DecimalFormat
The attached program gives the following result:
bash-2.05b$ java TestDecimalFormat
0.00% java.lang.IllegalArgumentException: unexpected special character - index: 4
Which is not the case with Sun's JDK.
In the kaffe world, I applied the following patch:
--- java/text/DecimalFormat.java.orig Thu Aug 28 00:44:12 2003
+++ java/text/DecimalFormat.javaWed Oct 22 17:57:28 2003
@@ -205,6 +205,8 @@
}
else if (c != syms.getExponential()
&& c != syms.getPatternSeparator()
+&& c != syms.getPercent()
+&& c != syms.getPerMill()
&& patChars.indexOf(c) != -1)
throw new IllegalArgumentException ("unexpected special " +
"character - index: " + index);
And the program for this case follows:
import java.text.DecimalFormat;
public class TestDecimalFormat {
public static void main(String[] args) {
String[] formats = new String[] {
"0",
"0.00",
"#,##0",
"#,##0.00",
"$#,##0;($#,##0)",
"$#,##0;($#,##0)",
"$#,##0.00;($#,##0.00)",
"$#,##0.00;($#,##0.00)",
"0%",
"0.00%",
"0.00E00",
"#,##0;(#,##0)",
"#,##0;(#,##0)",
"#,##0.00;(#,##0.00)",
"#,##0.00;(#,##0.00)",
"#,##0;(#,##0)",
"$#,##0;($#,##0)",
"#,##0.00;(#,##0.00)",
"$#,##0.00;($#,##0.00)",
"##0.0E0" };
for(int i=0; i < formats.length; i++) {
try {
DecimalFormat d = new DecimalFormat(formats[i]);
}
catch (Exception e) {
System.err.println(formats[i] + " " + e);
}
}
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Brian Jones wrote: This sort of religious zealotry is not helpful. People wishing to implement free versions should know where to go for the standard, the RFC, etc. If it is not possible to link in this context then the FSF web server is useless and I'll have to consider moving http://www.classpath.org/ elsewhere. First off, I have nothing to do with the GNU project so these opinions are only my own attempt to understand the GNU project's position and apply common sense to the result. Having said that, I don't think there's any objection to linking to the RFC per se or pointing to the OMG as the place where the standard is developed. The objection is to linking to either those places or any others and saying "you can get an implementation from here", if the implementation in question is not free. The distinction is based on context - does the link seem to someone reading the website to be a link to get software, or a link to find out more about something? In the case of the OMG and jgss links on www.classpath.org, the links appeared to me to be clearly "get software" links, hence the (double) problem with the omg and jgss links: neither of them actually were any help in figuring out where to obtain software, and even if they had been, the software in question is not free. It would be fine (if my interpretation is correct) to simply alter the website so that it's clear that these links go to information related to standardization of these packages, and not an implementation. But it seems to me that information about standardization of packages we haven't yet implemented isn't something that belongs on the Classpath homepage anyway, so it makes more sense to simply remove the links or replace them with links to implementations that really are free. (Incidentally, my understanding is that this restriction is not limited to projects using the GNU webserver - it's limited to any project which is "part of the GNU project", which in practical terms includes at least any program with "GNU " at the start of its name. On the other hand, non-gnu projects are allowed to use the FSF webserver (see http://savannah.nongnu.org) and those projects ARE allowed to link to non-free software, although they aren't allowed to depend on it). 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: org.omg link on Classpath homepage
Stuart Ballard <[EMAIL PROTECTED]> writes: > Mark Wielaard wrote: > > I think you are right. It is not a good idea to provide links to software > > of which we cannot (currently) guarantee that it is Free Software. > > Could you provide a patch (source is in CVS module classpath under > > docs/www.gnu.org). > > Sure, I'll try to do this in the next couple of days. > > Incidentally, the link for the jgss package is also misleading, as the > RFC doesn't appear to contain any implementation of the package in > question (I scanned all the way to the end, the only source code was > examples of usage) and even if it did, the license on the RFC is not > free (it does not allow modification of the RFC itself, although > certain kinds of derived works are permitted). > > (Note that I'm not suggesting that that would prohibit linking to the > RFC in general, as the RFC is not software - just that if software > source code *were* included in the RFC, that software would not be > free). > > Should my patch remove that link as well? This sort of religious zealotry is not helpful. People wishing to implement free versions should know where to go for the standard, the RFC, etc. If it is not possible to link in this context then the FSF web server is useless and I'll have to consider moving http://www.classpath.org/ elsewhere. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Eric Blake wrote: Sun seems to be blessing the use of hasNext() here, by not documenting that this should optimize to calling size(). Good point. Since this patch still hasn't been applied, this message is another attempt to try to figure out if there's any consensus about it. There have been lots of suggestions as to ways I could or should improve my code to not rely on this behavior (and in fact I have taken this approach: my code now works around the problem by not calling putAll() but manually looping over the elements and calling put() instead), but I'm not sure whether there have been any objections to applying the patch regardless, in order to match Sun's behavior and provide acceptable performance when size() is slow. I'm aware that several people are of the "I'm not too keen on it and it shouldn't be necessary for properly written code" point of view, but I'm not aware of any that go so far as "This patch should not be applied". If you are such a person, please speak up. If nobody speaks up, may I suggest that the consensus is "reluctantly apply it" - and in that case, could someone do so? Thanks, 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: org.omg link on Classpath homepage
Mark Wielaard wrote: I think you are right. It is not a good idea to provide links to software of which we cannot (currently) guarantee that it is Free Software. Could you provide a patch (source is in CVS module classpath under docs/www.gnu.org). Sure, I'll try to do this in the next couple of days. Incidentally, the link for the jgss package is also misleading, as the RFC doesn't appear to contain any implementation of the package in question (I scanned all the way to the end, the only source code was examples of usage) and even if it did, the license on the RFC is not free (it does not allow modification of the RFC itself, although certain kinds of derived works are permitted). (Note that I'm not suggesting that that would prohibit linking to the RFC in general, as the RFC is not software - just that if software source code *were* included in the RFC, that software would not be free). Should my patch remove that link as well? 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: org.omg link on Classpath homepage
Andrew Haley wrote: Where is this software? I haven't found it yet, but see postings from Brian Jones on this list where he indicates it's in OMG's FTP area (which I still can't find linked from their site). I guess that you could argue that since the problematic software is almost impossible to find from the link, it isn't a link to non-free software, but it *claims* to be such a link, and it's certainly a *reference* to non-free software - after reading that part of Classpath's homepage, it's quite possible that someone would independently search for OMG's implementation of these packages under the impression that they were Free. Where is this link? http://www.classpath.org/ - search for "OMG". Then look at the heading of the section, which refers to "providers for free core packages". The org.omg packages provided by the OMG are non-free - again, see other postings in this thread, Brian's in particular. If there is a pointer to unfree software it must, per GNU rules, be removed. That's what I thought. 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: org.omg link on Classpath homepage
Hi, > To fix 3, the link must be removed entirely. If for some reason 3 > doesn't need to be fixed (eg I'm misinterpreting GNU project policy), at > least 1 and 2 should be. I think you are right. It is not a good idea to provide links to software of which we cannot (currently) guarantee that it is Free Software. Could you provide a patch (source is in CVS module classpath under docs/www.gnu.org). Brian, are you still in contact with the OMG people about this? Or do you have contact information which I could use to discuss this issue with them. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard writes: > Andrew Haley wrote: > > FSF pages don't link to unfree software projects. It seems that OMG > > is not be an unfree software project, because "Implementations of the > > OMG specifications - such as Object Request Brokers, IDL compilers, > > and UML-based modeling tools - are not produced by OMG. They are, > > instead, produced by software vendors or suppliers..." > > But the link is provided specifically to get some software that *is* > produced by the OMG, and is non-free. Where is this software? > I see three distinct issues here: > > 1) The link doesn't actually take you to a place where you can get the > software in question, so it's pretty useless as a link anyway. > > 2) The link is in a section labelled "providers for free core packages", > but the software in question is not free. You could argue that "free" in > this context means zero-cost, but on a GNU project such usage is at best > VERY ambiguous and at worst outright misleading. Where is this link? > 3) GNU projects aren't supposed to link to non-free software, so the > link shouldn't exist in the first place. A link to OMG *could* be > legitimate, if it was in the context of "the people who define the CORBA > specification, including the org.omg packages". But even though the OMG > is not in itself a non-free software project, I can't see how "go to the > OMG to get this software", when the software in question is non-free, is > not a link to non-free software. > > To fix 3, the link must be removed entirely. If for some reason 3 > doesn't need to be fixed (eg I'm misinterpreting GNU project policy), at > least 1 and 2 should be. If there is a pointer to unfree software it must, per GNU rules, be removed. But I've failed to find it, and I did try. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Andrew Haley wrote: FSF pages don't link to unfree software projects. It seems that OMG is not be an unfree software project, because "Implementations of the OMG specifications - such as Object Request Brokers, IDL compilers, and UML-based modeling tools - are not produced by OMG. They are, instead, produced by software vendors or suppliers..." But the link is provided specifically to get some software that *is* produced by the OMG, and is non-free. I see three distinct issues here: 1) The link doesn't actually take you to a place where you can get the software in question, so it's pretty useless as a link anyway. 2) The link is in a section labelled "providers for free core packages", but the software in question is not free. You could argue that "free" in this context means zero-cost, but on a GNU project such usage is at best VERY ambiguous and at worst outright misleading. 3) GNU projects aren't supposed to link to non-free software, so the link shouldn't exist in the first place. A link to OMG *could* be legitimate, if it was in the context of "the people who define the CORBA specification, including the org.omg packages". But even though the OMG is not in itself a non-free software project, I can't see how "go to the OMG to get this software", when the software in question is non-free, is not a link to non-free software. To fix 3, the link must be removed entirely. If for some reason 3 doesn't need to be fixed (eg I'm misinterpreting GNU project policy), at least 1 and 2 should be. 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: org.omg link on Classpath homepage
Ricky Clarkson writes: > If software that is non-free is software that is not part of the GNU > project, False premise. > then Linux is non-free, and someone has somewhere defined free > as being GNU. Incorrect conclusion. Please see "The Free Software Definition", http://www.gnu.org/philosophy/free-sw.html. > If you disallow links to software that itself provides links to > non-free software, you are effectively trying to create your own > separate internet where http://www.microsoft.com is illegal (as well it > should be, you may say :). FSF pages don't link to unfree software projects. It seems that OMG is not be an unfree software project, because "Implementations of the OMG specifications - such as Object Request Brokers, IDL compilers, and UML-based modeling tools - are not produced by OMG. They are, instead, produced by software vendors or suppliers..." Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Hi, If software that is non-free is software that is not part of the GNU project, then Linux is non-free, and someone has somewhere defined free as being GNU. If you disallow links to software that itself provides links to non-free software, you are effectively trying to create your own separate internet where http://www.microsoft.com is illegal (as well it should be, you may say :). Ricky. > And there was a somewhat-public dispute between the GNU Ghostscript team > and the GNU Project leadership (specifically RMS) over the fact that GNU > Ghostscript pointed people to Aladdin Ghostscript which is non-free - > last I heard, GNU Ghostscript was no longer part of the GNU project > (although the split was amicable) because they were unwilling to remove > all references to the non-free project. So I'm fairly sure that the rule > against pointing people to non-free code is enforced strictly on > software that is part of the GNU project. -- Sin has many tools, but a lie is the handle which fits them all. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Brian Jones wrote: I don't know if the FSF has characterized the OMG license as non-free yet. We can't include it but we're certainly free to point people at it. It's called 'javartf' and I still have a copy of it if someone wants it. I couldn't get into the ftp site just now myself. Surely if it doesn't allow modification there's not much doubt that it's non-free? And there was a somewhat-public dispute between the GNU Ghostscript team and the GNU Project leadership (specifically RMS) over the fact that GNU Ghostscript pointed people to Aladdin Ghostscript which is non-free - last I heard, GNU Ghostscript was no longer part of the GNU project (although the split was amicable) because they were unwilling to remove all references to the non-free project. So I'm fairly sure that the rule against pointing people to non-free code is enforced strictly on software that is part of the GNU project. 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
