Discussions

News: Ask TSS: Are the FSF's concerns with Java valid?

  1. In "The Java Trap," Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." This statement is being used to justify the FSF's request that OpenOffice 2.0 be delayed or supporters for a "free Java" be found. (See "OpenOffice.org 2.0 Being Met With Opposition Over Java Dependency.")

    TSS asks: is this statement valid?

    While some com.sun.* classes are very useful (the JPEG codec comes to mind), use of the com.sun.* classes is hard to accidentally code, and is certainly not encouraged by Sun. Java is a term applied to any JVM that can pass the certification kit, not a specific JVM, and the "trap" RMS suggests is possible is equally possible in any given JVM, even completely open source ones.

    In fact, it's more likely to occur in unlicensed or uncertified versions of the JVM, since they don't have the testing kit or the constraints it requires available to them.

    Another aspect to RMS' statement is that "redoing the work" caused by accidental use of a Sun-specific API could "take more months." Is this an accurate statement? It's easy to imagine that changing a persistence framework would take some time, or rewriting an application's front end. However, the Sun specific APIs are very low-level, consisting of rarely-used worker classes and GUI peers, which are definitely not deliberately exposed to the end-user.

    The FSF's stance on open software is certainly respectable; most programmers have benefited from it in some form or fashion. However, do you think the concerns it has with Java - that using Java locks you in somehow to Sun - are valid?

    With the formation of the Harmony project, an Apache-led implementation of a full JVM, an open-source Java might not be far off, depending on how quickly Apache can implement a JVM and class library. However, Harmony is still likely to be encumbered with Sun's definition of Java, which would seem to violate the FSF's ideals. What do you think?

    Threaded Messages (103)

  2. OS Java[ Go to top ]

    I'm trying to see where Richards comments and Java actually meet and so far, I just don't get it.

    There is no legal or technical reason that I can see would justify the delay and delaying on idological grounds just seems silly.
  3. Is anybody surprised that GNU zealots are up in arms about this, without understanding how the technology was implemented? Much like a political organization, their aim is to create FUD, not useful products, unless you adhere to their ideology. The insistence to precede Linux with GNU/, anyone?

    I figure that, if Java is good enough for a large portion of the Apache Foundation's projects, it's good enough for any other open-source project. As a long-time OOo advocate, and one who understands how the Java wizard dependencies work in OOo, it's hard for me to see how this is a problem. Those portions of the code can be implemented using gcj tools... assuming that they will ever fix their compatibility issues with the Java spec. Not with the com.sun.* packages but with the PUBLIC spec. The OOo folks already published instructions on how to do this.

    OpenOffice.org is a choice, one more tool that competes with Microsoft Office, KOffice, and a myriad of products. As a user, all I care about is that the tool does its job. As a developer, I respect the decisions made by the OOo implementation team. As an architect, I'd say to use the right tool for the right job. And as member of the community, I'd say to the GNU Free Software zealots to spend more time coding and less time bitching about non-issue licensing minutiae.

    Cheers,

    E
  4. Eugene,
    I have to disagree.

    Regarding the GNU/ precedence see my first post on the topic.

    Regarding how much code the GNU/FSF has, you obviously have no idea what you're talking about. Take the GCC suite alone.

    Regarding the Java bits in OOo, my personal oppinion is that it's just laziness. There's _no reason_ whatsoever that you would use Java to write a dumb select/click/next/select/click/done document wizard in Java when the core of OOo is C++. There's no reason to use Java's XML APIs to perform XSLT transformations when every Linux distro on the face of the planet - except the embedded ones, maybe - comes with libxml2 and libxslt, that both are but a fraction of the size of say Xerces alone and have no other dependencies, not to mention a 15-20 MB JRE.

    And as an architect you should know better than to pick the /first/ right tool for the job.
  5. OOo 2.0 is going to be very portable (Win, Linux, OS-X....), so OOo developers are surely appreciating the availability of an os-independent implementation of xml-things.
     Nowadays diskspace is not expensive, surely I'd trade some more 40-50Mb in order to get OOo 2.0 final, avabilable a couple of months in advance!
     And this is just a matter of speed+portability: writers of the JVM _already_ did the work, so it's already done!
  6. get your facts right.
    libxml and libxstl are portable, and I will bet you all the money in the world they're more portable (i.e. would run on more hardware/software platforms) than java (where a JVM is available).
    you'd also trade some 50MB+ of RAM by having an office program load up a JRE just so that it can put some buttons on the screen or perform some XML work.
    whatever.
  7. libxml + libxslt + ..... cygwin?
    I had been using 'ported' things for lots of time, when needed I even took time to do portings from sources, but you are always 'lagging behind', and this becomes frustrating...
    so currently I take very differently the words 'portable' and 'ported':
    - portable: someone might port it, but....
    - ported: available, but maybe not updated

    consider that the 'ported but not updated' problem is why most people stille depends on JVM 1.4

    as to memory you are right, but this strongly depends on the number of apps you run at once, 50Mb RAM are OK when I'm doing document-ware, thaty are not when I'm verifing customer bug reports with Eclipse (2 instances) + Resin (2 instances) + SQLServer + Firefox + Thunderbird + OOo. But here the problem is not 50Mb more or less, here I'm out of more then 200Mb.
    But now the JVM 5.0 is doing sharing and memory usage is being greetly reduces (it load blazingly fast!)

    All in all: porting requires time and causes quality assurance and lagging problems, since JVM removes these problems I really can accept it's price
  8. OS Java[ Go to top ]

    I think RMS is not talking about com.sun.* stuff.

    He warned Java programmers about using features and additional API-s (eg. under javax) which has no free variants (yet). Using a compiler/lib with narrower featureset can stop you having these deps.

    Eg. GNU Classpath does not have JSpinner. If sun should go mad and begin requesting a royalty fee or - insert any doomsday theory here - . (Free, Small biz.) software depending on these APIs/Classes cannot legally run for a time. (I think in that case ClassPath would be patched very quickly).

    If it is a concern for someone, take this advice, for me it is not that bad.

    RMS blamed Sun for requesting a specification to be fully implemented or not released as such.
    I think he misunderstood the intent of this requirement.
    This requrement (IMO) is for ensureing interoperability between implementations of a given spec, but it does not mean you can't make an implementation colaborally.
    You can still have minestone releases and CVS snapshots released but till you don't have anything you can't say it is an (full) implementation.

    Tamas
  9. I respect Stallman but it's statement seems to me quite empty and incorrect.
    I can hardly imagine a developer using a Sun-only features, assuming he speaks about the com.sun.* packages, by accident.

    Regarding OpenOffice, putting Java aside, I have some difficulty in believing that in it's code base there aren't
    a number of OS-specifics and compiler-specifics hacks, all of them using proprietary API. Not using them would undermine its cross-platform availability.

    The same is true for Java at JVM e class library level.
    At the end of the day Stalman thinks that the ONLY os is Gnu/Linux and that Windows/OSX et al. shouldn't exists.

    I think that no leverage or recognition should be given by the INDUSTRY (and i mean industry as in people and companies working for money) to statements born from such a antefact.
  10. GNU/Linux?[ Go to top ]

    Don't you mean GNU's UNIX implementation, and not Linux? Or are you suggesting that GNU is trying to hijack Linux because they couldn't figure out how to actually do a UNIX implementation on their own, despite being really smart and intelligent and knowledgeable and stuff?
  11. GNU/Linux?[ Go to top ]

    Don't you mean GNU's UNIX implementation, and not Linux? Or are you suggesting that GNU is trying to hijack Linux because they couldn't figure out how to actually do a UNIX implementation on their own, despite being really smart and intelligent and knowledgeable and stuff?

    I meant exactly GNU/Linux as in
    "GNU Unix implementation is called Hurd the combination of the Linux kernel and the GNU system is called GNU/Linux".
  12. GNU/Linux?[ Go to top ]

    Don't you mean GNU's UNIX implementation, and not Linux? Or are you suggesting that GNU is trying to hijack Linux because they couldn't figure out how to actually do a UNIX implementation on their own, despite being really smart and intelligent and knowledgeable and stuff?

    I meant exactly GNU/Linux as in"GNU Unix implementation is called Hurd the combination of the Linux kernel and the GNU system is called GNU/Linux".

    The nice thing about open source is you can call your assemblage of it whatever you want to.

    If RMS wants to build Linux he can call it GNU/Linux.

    Of course everyone else rightfully calls it Linux. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  13. GNU/Linux?[ Go to top ]

    .If RMS wants to build Linux he can call it GNU/Linux.
    Of course everyone else rightfully calls it Linux. ;-)Peace,Cameron Purdy

    I've known Linux as Linux for a many years before first hearing of the GNU/Linux denomination.
    The FSF is entitled to claim it should be called GNU/Linux, I believe, since pretty much everything that constitutes the bare OS, apart from the kernel - i.e. the c library, the posix, System V and BSD APIs are GNU software, not to mention the layer of compilers, linkers, assemblers and basic code editors. There's a huge amount of GNU code in there, and a lot of it is system code, so I think the FSF is basically right in calling it GNU/Linux instead of just Linux.
  14. GNU/Linux?[ Go to top ]

    The FSF is entitled to claim it should be called GNU/Linux, I believe, since pretty much everything that constitutes the bare OS, apart from the kernel - i.e. the c library, the posix, System V and BSD APIs are GNU software, not to mention the layer of compilers, linkers, assemblers and basic code editors. There's a huge amount of GNU code in there, and a lot of it is system code, so I think the FSF is basically right in calling it GNU/Linux instead of just Linux.

    Sure, they can call it whatever they want to!

    However, for those of us that knew it as "Linux", it's still "Linux". Remember, of all that "GNU" stuff that is in "Linux", only a handful of it actually comes from RMS & company, the rest comes from people just like Linux who don't choose to call their stuff "GNU/*" just because they happen to license it under the GPL.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  15. GNU/Linux?[ Go to top ]

    Cameron,

    GPL code does not a GNU project make.
  16. Valid concerns?[ Go to top ]

    Well, if you replace "features" with "bugs", there is some truth in FSF's statement. You could have been depending on ondocumented and/or buggy behavior in class libraries without noticing, or you might have had to go to a lot of trouble to work around existing bugs. All the NIO-related issues in Sun's JDK that people had to work around comes to mind here.

    Of course, JDK source has been available for a long time. The terms of accessing and using those sources were (are?) not exactly pleasant but it is at least possible to find in detail what behavior and bugs your code is depending on, if you are determined enough. Obviously, you can't really fix the Java runtime and distribute your version along, and I get uneasy at the thought of various "fixed" runtimes out there, waiting like mines to sink your unsuspecting application, even though Linux seems to make this work well enough.

    I think there's a fear that Sun will at some point take its toys and go home, do something that will be unacceptable to the Java community, caused either by profound stupidity, desperation or both. This is unfounded in my opinion, but having no "Plan B" makes people uneasy. Do you really want to depend on a platform that can not be evolved independent of one single company? As the McVoy debacle on Linuxland demonstrated, not really.
  17. Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." is this statement valid?

    Simply, no. This really does sound like plain FUD. It is hard to imagine using com.sun.* classes 'without noticing', and the idea that you only find this out later is absurd.
  18. Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." is this statement valid?
    Simply, no. This really does sound like plain FUD. It is hard to imagine using com.sun.* classes 'without noticing', and the idea that you only find this out later is absurd.
    It seems Richard knows little about how Java works. Or worse. :(
  19. Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." is this statement valid?
    Simply, no. This really does sound like plain FUD. It is hard to imagine using com.sun.* classes 'without noticing', and the idea that you only find this out later is absurd.
    It seems Richard knows little about how Java works. Or worse. :(

    I have a lot of respect for Richard and the FSF - they have achieved great things and changed major aspects of the IT industry, so I would have expected better from them than this sort of nonsense. I have been looking into this, and while it looks like Open Office 2.0 has used a very few Sun-Java specific features (sun.*), most of the com.sun.* packages seem to be part of the Star Office libraries (com.sun.star.*) which have been (I assume) supplied to the Open Office project, and nothing at all to do with the Sun JDK or JRE. Although I am disappointed that the developers have used even the a few sun.* packages (this is definitely bad practise), this seems to have been hugely over-hyped by anti-Java fanatics.
  20. Well, in essence it boils down to bad programming: if a developer is using runtime-specific features, they should use reflection for that.

    Unfortunately, ocassionally there is code that just whacks in some random import that breaks the build on everything else. There is no way to prevent that, I fear.

    cheers,
    dalibor topic
  21. Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." is this statement valid?
    Simply, no. This really does sound like plain FUD. It is hard to imagine using com.sun.* classes 'without noticing', and the idea that you only find this out later is absurd.
    It seems Richard knows little about how Java works. Or worse. :(

    Have you guys actually carefully read Stallman's article ?
    Quoth the RMS:
    [the problem]
    Sun's implementation of Java is non-free. Blackdown is also non-free; it is an adaptation of Sun's proprietary code. The standard Java libraries are non-free also. We do have free implementations of Java, such as the GNU Compiler for Java (GCJ) and GNU Classpath, but they don't support all the features yet. We are still catching up.

    [the "trap"]
    If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing.
    [...]

    [the solution]
    The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately.

    I fail to see how this proves RMS doesn't understand Java or how this goes to usage of the com.sun internal packages.
    I believe the point is quite clear: to make sure your Java code does not depend on Sun's JRE, you should invest time and effort to at least run/test it with a open source VM/classpath, if not develop it solely on that.
    As someone who's been bitten by lack of functionality in the GNU Classpath (yes, anti-FSF zealots, the most complete open source Java alternative is GNU software, yes, GNU, those who can only bitch about irrelevant licensing issues and are all politics) I have to say that this is a sensible advice, if you need to have your code running on Classpath - quite obvious, really.
  22. If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing.[...][the solution]The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately.
    I fail to see how this proves RMS doesn't understand Java or how this goes to usage of the com.sun internal packages.I believe the point is quite clear: to make sure your Java code does not depend on Sun's JRE, you should invest time and effort to at least run/test it with a open source VM/classpath, if not develop it solely on that.

    What is happening in RMS's article is a confusion of two completely separate issues.

    1. The matter of 'free' vs 'non-free' Java.
    2. There is some kind of 'trap' that is easy to fall into which means you end up being tied in to using only Sun's Java implementation, and can't use the implementation from another company.

    For me, (1) is not important, but it is a reasonable matter for discussion. However, (2) is just nonsense. There is simply no trap. You have to actively seek out unpublished APIs if you want to end up relying on one vendor's implementation of the java runtime. With Sun's implementation, these APIs usually start with 'com.sun.*' or 'sun.*'.

    This certainly seems like classic FUD. You set up a false problem to scare developers - the idea that you can be easily trapped into vendor-specific JREs, and then you provide a solution to this false problem: Use only 'free' Java. Of course, this would not solve problem! A 'free' Java will have its own specific class libraries to provide the standard Java APIs. If you can fall into the trap of Sun's Java, you could just as easily fall into the trap of Gnu Java, or Apache Java.

    Fortunately, there is no trap. There are very few applications which use Sun-specific code, and my impression is that almost all the rest seem to be able to move between JREs with few problems.

    So why the comment about this 'trap'? The charitable interpretation is that comment is from someone who is not experienced with modern Java implementations. (There may have been such issues a long time ago in early Java). The alternative interpretations are less charitable - that this is deliberate anti-Sun FUD.

    I hope this clears up why some of us have expressed the opinions we have.
  23. There is simply no trap

    To illustrate that this is true, even a Sun product such as NetBeans 4.0 will run fine on a non-Sun JDK - it is quite impressive to see this in action - it is a good demonstration of Java implementation compatibility. If even a product of this complexity need not use Sun-specific classes, there is probably little reason for any other product to do so.
  24. There is simply no trap
    To illustrate that this is true, even a Sun product such as NetBeans 4.0 will run fine on a non-Sun JDK - it is quite impressive to see this in action - it is a good demonstration of Java implementation compatibility. If even a product of this complexity need not use Sun-specific classes, there is probably little reason for any other product to do so.

    Again, this is completely off-topic, I mean off RMS's point.
    But since you've mentioned it, I cannot refrain not to mention that Tomcat amidst his 4.0.x version was failing to start up with SSL on any JRE that did not include com.sun classes for SSL - incidentaly IBM's didn't. OK, I'll just stop here instead of twisting your phrases the other way around :)
  25. There is simply no trap
    To illustrate that this is true, even a Sun product such as NetBeans 4.0 will run fine on a non-Sun JDK - it is quite impressive to see this in action - it is a good demonstration of Java implementation compatibility. If even a product of this complexity need not use Sun-specific classes, there is probably little reason for any other product to do so.
    Again, this is completely off-topic, I mean off RMS's point.

    On the contrary, it is exactly on topic. RMS said "You are liable to use Sun-only features without even noticing". That a product as large and complex as NetBeans does not use Sun-only features implies that this liability is a myth.
    But since you've mentioned it, I cannot refrain not to mention that Tomcat amidst his 4.0.x version was failing to start up with SSL on any JRE that did not include com.sun classes for SSL - incidentaly IBM's didn't. OK, I'll just stop here instead of twisting your phrases the other way around :)

    That is not a 'liability to use features without noticing'. The com.sun classes for SSL were available as an optional standard package for any 1.2 or 1.3 Java.
  26. NB 4?[ Go to top ]

    To illustrate that this is true, even a Sun product such as NetBeans 4.0 will run fine on a non-Sun JDK.

    Are you _still_ running NB4? NetBeans 4.1 is out for an hour already!
  27. There is simply no trap. You have to actively seek out unpublished APIs if you want to end up relying on one vendor's implementation of the java runtime. With Sun's implementation, these APIs usually start with 'com.sun.*' or 'sun.*'.

    No Steve. That's not what it says. Read it again.
    RMS says there is no complete free-as-in-freedom JVM+Classpath. Therefore if you develop Java programs and use Sun's JVM+Classpath (or any other JRE provider for that matter, even though not specifically mentioned in the article) you risk being tied to that particular, even if compliant Java implementation.

    I think this is quite clearly what it says. This article is almost a year old and has caused quite a stir at that point; but again, it is _not_ a lame advice about not using non-public APIs and not just about Sun's JRE.
  28. There is simply no trap. You have to actively seek out unpublished APIs if you want to end up relying on one vendor's implementation of the java runtime. With Sun's implementation, these APIs usually start with 'com.sun.*' or 'sun.*'.
    No Steve. That's not what it says. Read it again.RMS says there is no complete free-as-in-freedom JVM+Classpath. Therefore if you develop Java programs and use Sun's JVM+Classpath (or any other JRE provider for that matter, even though not specifically mentioned in the article) you risk being tied to that particular, even if compliant Java implementation. I think this is quite clearly what it says.

    Indeed it is. The phrase that seems to cause the problem is:

    "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing."

    There are two matters raised by this key statement.
    (1) You are liable to use Sun-only features.
    (2) You won't notice this.

    The first problem is that at no time is any list of these "Sun-only features" provuded. This is why myself (and others) can only assume that these features are the undocumented 'sun.*' and some 'com.sun.*' packages, which Sun uses to provide the standard Java APIs. It is hard to think of any other vendor-specific features.

    The second problems is how can you not notice this? These apis are undocumented! You have to actively hunt them out.

    The claim that you are 'liable to use [vendor]-only features' is a strong one, and requires strong evidence. There simply is little evidence to back it up. We are talking here about a few calls Open Office 2.0, which is one example. However, other than that...
    but again, it is _not_ a lame advice about not using non-public APIs and not just about Sun's JRE.

    The thing is.. if it is not about non-public APIs, then what on Earth IS it about? What are these supposed vendor-specific features?
  29. The thing is.. if it is not about non-public APIs, then what on Earth IS it about? What are these supposed vendor-specific features?

    Forgive me... after having re-read the article a fifth time, I think I begin to see what the issue is!

    The so-called 'Trap' only exists because the GNU implementation is incomplete. If you use a modern Java JDK You might, without realising it, use some java library that GNU has not finished writing in their implementation.

    [I think this is a bit rich - complaining that developers should not use a full Java version because GNU have not completed their work!]

    But, I was confused about this because part of the problem with Open Office 2.0 is that it has Sun-specific code, which could prevent it being moved to a non-Sun JRE, which is an entirely different matter from it being 'Free' or not.

    I apologise for having been so stridently off-topic.
  30. Forgive me... after having re-read the article a fifth time, I think I begin to see what the issue is!The so-called 'Trap' only exists because the GNU implementation is incomplete. If you use a modern Java JDK You might, without realising it, use some java library that GNU has not finished writing in their implementation.[I think this is a bit rich - complaining that developers should not use a full Java version because GNU have not completed their work!]But, I was confused about this because part of the problem with Open Office 2.0 is that it has Sun-specific code, which could prevent it being moved to a non-Sun JRE, which is an entirely different matter from it being 'Free' or not.I apologise for having been so stridently off-topic.

    No probs Steve. It's in a different mindset, really, and it is indeed a bit rich, as you say.
    Sad to see all these comments crapping all over GNU and the FSF just because people think they're a bunch of anti-corp commies that do nothing that bitch and moan.

    Anyways, on the OpenOffice issue, I was not even aware that it apparently had Sun-specific code. My only problem with the Java thing in OOo2 is that you should definitely not require a Java runtime, whatever that would be (Sun's or IBM's or GCJ) for dead-simple things such as document template wizards and the XSLT transforms used to export documents into other formats such as DocBook.
    For me personally this is not that big of a problem since most (98% ?) development I do is in Java and I have about 3 IBM JREs, 2 Suns, 1 blackdown and 2 GCJs on my machine. But when the vast majority of the code in a product is C++ and you can achieve the same task in roughly the same amount of code, with less dependencies and in about the same time, choosing to introduce a dependency on a JRE is stupid or lazy. I mean, come on, how hard can XSLT transforms be ?! Actually I think libxslt is even simpler to use than most of the Java APIs if you take at a look at the tutorial.

    Anyway, this is all just water under the bridge. Both stories are ancient history already; the RMS article is over a year old. Congratulations to Joseph for his ability to dig up old news and put them in a new context; there's your journalist right there :)
  31. Anyway, this is all just water under the bridge. Both stories are ancient history already; the RMS article is over a year old. Congratulations to Joseph for his ability to dig up old news and put them in a new context; there's your journalist right there :)

    Haha! Well, I'd known about the article a while back, of course. However, the OOo2 flap brought it back up, and I thought it was worthy of consideration.
  32. Sad to see all these comments crapping all over GNU and the FSF just because people think they're a bunch of anti-corp commies that do nothing that bitch and moan.

    +1

    Cheers

    Remi
  33. Sad to see all these comments crapping all over GNU and the FSF just because people think they're a bunch of anti-corp commies that do nothing that bitch and moan.
    +1CheersRemi

    I don't see it as all that sad. GPL is an obnoxious, inflexible license. While I respect GNU contributors' right to select this delivery model for their contributions, I find it the least friendly OSI license available.

    Further, GNU folk have a tendency to condemn use of any technology which does not yet have a 100% OSI path. In this case, this is condemning use of any portion of Java that is not covered by GNU Classpath. For those not in their ivory tower, use of the *full* Java spec (not com.sun.* red herrings) is the only thing that makes sense to get the job done. I see Mono as a bigger threat to cross-platform choice (by helping C# lock people into Windows by providing a pseudo-cross-platform tool) than the fact that no complete OSI Java implementation exists to date.
  34. I don't see it as all that sad.

    Well, insulting the FSF of being "fanatics" is nothing but sad to me.
    I see rather high and good values in their position, and I would rather thank them as well as all contributors over the world for what they did, and still do.
    GPL is an obnoxious, inflexible license.

    Yes it's strong. But freedom has a price IMHO.
    While I respect GNU contributors' right to select this delivery model for their contributions, I find it the least friendly OSI license available.

    I find it the most enforcing freedom of code.
    Further, GNU folk have a tendency to condemn use of any technology which does not yet have a 100% OSI path.

    Ahem, please read what you write : *you* actually condemn people :-P
    The "GNU folk" that wrote the article does not really "condemn" anyone. He just emits (strong, agreed) warnings AFAIUnderstood...
    In this case, this is condemning use of any portion of Java that is not covered by GNU Classpath.
    For those not in their ivory tower, use of the *full* Java spec (not com.sun.* red herrings) is the only thing that makes sense to get the job done.

    Fully agreed. Then enhance Classpath. But don't tell the FSF the idea is bullshit : it's only a question of goodwilling and investment.
    Classpath-like initiatives are good for us, Java developers.
    And the best for everybody would be to have sun in the project :-)
    I see Mono as a bigger threat to cross-platform choice (by helping C# lock people into Windows by providing a pseudo-cross-platform tool) than the fact that no complete OSI Java implementation exists to date.

    Well, these are different issues I think.

    Have fun,

    Remi
  35. In this case, this is condemning use of any portion of Java that is not covered by GNU Classpath.For those not in their ivory tower, use of the *full* Java spec (not com.sun.* red herrings) is the only thing that makes sense to get the job done.
    Fully agreed. Then enhance Classpath. But don't tell the FSF the idea is bullshit : it's only a question of goodwilling and investment.Classpath-like initiatives are good for us, Java developers.And the best for everybody would be to have sun in the project :-)

    I am not telling the FSF GNU Classpath is BS. Rather I take issue with them trying to spread FUD when OSI projects use portions of Java GNU Classpath does not support or create something which does not work well with purely open-source Java tools. If the project uses com.sun.* or the like, then that is a clear issue for Java portability period. Otherwise, GNU should not "raise concerns" about choosing Java (i.e. spread FUD) and should just get to work on GNU Classpath, etc.
  36. I've tried to make it clear that Stallman's article is not FUD. It's a take on an issue that is present with people who care about certain things. If that does not include you, that's fine. It is definitely not FUD, there's no fear, nor uncertainty nor doubt in his statements. It's a straight-forward warning that if you use Java, make sure you do not depend on parts that are not available in the free implementations. You may want to look at it as a gesture against Java, but I think it's not.
  37. <quoteblock>enforcing freedomI find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.
  38. no more no less[ Go to top ]

    enforcing freedom
    I find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.

    Its not enforcing freedom, it is protecting freedom. Think of the FSF this way...Let's say you own millions of acres of land and when you die you want it to become a national park. You write up the necessary legal documents so that it can never be taken into private ownership or used commercially. You want to be sure that your property is only being used for the good of the community at large.

    Richards statements are no more no less zealot that the Apache ASL folks. I hate that both the Apache folks and FSF folks have to make a religion out of it. That it is an either/or choice.

    I kinda wish Richard would do more recruiting for the GNU Classpath project rather than just annoying people with this ideological nonsense.
  39. no more no less[ Go to top ]

    enforcing freedom
    I find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.
    Its not enforcing freedom, it is protecting freedom. Think of the FSF this way...Let's say you own millions of acres of land and when you die you want it to become a national park. You write up the necessary legal documents so that it can never be taken into private ownership or used commercially. You want to be sure that your property is only being used for the good of the community at large.Richards statements are no more no less zealot that the Apache ASL folks. I hate that both the Apache folks and FSF folks have to make a religion out of it. That it is an either/or choice.I kinda wish Richard would do more recruiting for the GNU Classpath project rather than just annoying people with this ideological nonsense.
    Bill, the way I understand it, "enforce" better describes FSF, not "protect". Using you analogy, it is like "I'd like to turn my land into a park so anyone can use it, but if you want to take a walk in my park, you'll have to turn YOUR land into a park too.". As it is, not many people will go to your park, so your freedom protection (or enforcement) ideals may backfire in the end.
  40. no more no less[ Go to top ]

    enforcing freedom
    I find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.
    Its not enforcing freedom, it is protecting freedom. Think of the FSF this way...Let's say you own millions of acres of land and when you die you want it to become a national park. You write up the necessary legal documents so that it can never be taken into private ownership or used commercially. You want to be sure that your property is only being used for the good of the community at large.Richards statements are no more no less zealot that the Apache ASL folks. I hate that both the Apache folks and FSF folks have to make a religion out of it. That it is an either/or choice.I kinda wish Richard would do more recruiting for the GNU Classpath project rather than just annoying people with this ideological nonsense.

    Bill, that's completely wrong and probably one of the worst interpretations of the GPL I've ever had the misfortune to lay my eyes upon. Really, you should know better.
  41. no more no less[ Go to top ]

    Its not enforcing freedom, it is protecting freedom.

    Thanks for this correction. It was exactly what I meant but my english skills are too limited for this kind of "philosophical" discussions.
    I kinda wish Richard would do more recruiting for the GNU Classpath project rather than just annoying people with this ideological nonsense.

    Still, this does not explain such a buzz. The guy actually produced less FUD than this thread ;-)

    Have fun,

    Remi - but he may be bias...
  42. enforcing freedom
    I find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.

    Hmmm, the fact that freedom can be "enforced" is the current policy of an influent Government, as a matter of fact the Government of the Nation where most TSS readers live (and thrive, I hope). And, consequently, it is also the currently accepted policy of my country's government. So, calling it paradoxical can easily trespass into the domain of politics, which is not the best thing to do in this forum.

    However, once I have started the politics thread myself, I would like to share knowledge of an interesting coincidence that is possibly unknown to most for geographical reasons.

    Stallman has just written an interesting
    letter to the Italian Parliament, regarding its vote in favour or against the adoption of software patents in the European Union, the English translation of which is not available, I'm afraid (try AltaVista). The vote of the Italian House of Representatives can at this point substantially influence the acceptance of software patents in the EU, the importance of which need not be explained here.

    I feel that Stallman is now trying to do his best to fight the important battle of software patents, which, unlike the struggle for Free Software, which will always see people who care for it and people who do not, actually deserves to be turned into a crusade.

    Now, a few moments before being marked noisy, I have a disturbing question:

    If the referenced article is one year old, why did you (TSS) start the discussion about it exactly now ?

    And, frankly, I still believe it is just a coincidence.
  43. It's been brought up recently in light of the OpenOffice 2.0 conversations regarding the FSF and an "open java."
  44. It's been brought up recently in light of the OpenOffice 2.0 conversations regarding the FSF and an "open java."

    Thanks, this makes me feel reassured.
  45. [...] can easily trespass into the domain of politics

    I fear that this OSS thing and politics are not "loosely coupled" systems...
    which is not the best thing to do in this forum.

    Right. I'll follow Peter's advice, and go back coding. This way I'll have a chance to finish that damn project before all I use is subject to royalty fees and proprietary code !!!

    Have fun,

    Remi - btw, I though about it deeply and came to a single conclusion : the future is in free beer btw, not in free software ! OK, I'm out... :-)
  46. btw, I though about it deeply and came to a single conclusion : the future is in free beer btw, not in free software ! OK, I'm out... :-)

    Where's the download? ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  47. Where's the download? ;-)Peace,Cameron Purdy

    The community is very active but it's corrently working on the licence stuff...

    Cheers

    Remi - They should release soon... fingers crossed !
  48. I though about it deeply and came to a single conclusion : the future is in free beer btw, not in free software ! OK, I'm out... :-)

    The future pretty much goes out after 2 guinesses, 3 black russians and 2 long islands. Until the morning, at least.
  49. Richard Stallman and politics[ Go to top ]

    I though about it deeply and came to a single conclusion : the future is in free beer btw, not in free software ! OK, I'm out... :-)
    The future pretty much goes out after 2 guinesses, 3 black russians and 2 long islands. Until the morning, at least.
    That would explain some of your posts ;)
  50. I find it very contradictory. One can't "enforce" freedom, it's paradoxical, IMO.

    Yes it is, I fully agree with you, freedom should not be imposed in any way...

    But the world is full of paradoxical things IMO (even life often is), and OSS is in that boat, don't you think ?

    Have fun,

    Remi
  51. Yes it's strong. But freedom has a price IMHO.

    GPL is freedom the same way Stalin's gulag was free. People in there were free to die of starvation, exposure, disease, and lead poisoning of their choice.
    Ahem, please read what you write : *you* actually condemn people :-P
    The "GNU folk" that wrote the article does not really "condemn" anyone. He just emits (strong, agreed) warnings AFAIUnderstood...

    Wrong. He points out the hypocricy of the OS zealots, that's not in itself condemnation (though zealots often are less than comfortable with being exposed for what they are).
    Fully agreed. Then enhance Classpath. But don't tell the FSF the idea is bullshit : it's only a question of goodwilling and investment.
    Classpath-like initiatives are good for us, Java developers.
    And the best for everybody would be to have sun in the project :-)

    Wrong. If they think Classpath isn't good enough THEY should enhance classpath.
    Instead they blame the reference implementation for not being as restrictive as their vaunted perfect version.
    OK you're clearly one of those individuals who thinks the FSF is a bunch of commies and the Holocaust is really just a judaic conspiracy.
    I think this has got to be one of the most ill informed comments ever posted on TSS, clearly a runner-up to Rolf's rants.
    RMS also wrote Emacs, which has its own Lisp interpreter and dialect and most of Emacs is Lisp.
    And Perl has CPAN which is a well established and very large collection of Perl code that's community driven. I've never written more than a couple of lines of perl, but that doesn't mean I should be completely oblivious to the rest of the world.

    Read again...
    Apparently you consider anyone who doesn't pray to the Twin Gods of Stallman and Raymond to be fascist zionists?

    I never said anywhere that Stallman writes ONLY in C, all I stated is that he hates Java with a vengeance and wants it destroyed.
    He's in fact religious about that.

    CPAN isn't the same as the language spec... It's a repository of addon libraries for the language, much like what the Jakarta project is for Java (but larger).
    The Perl language specs are the closely guarded posession of a small group of individuals, quite in contrast to the JLS being the posession of the JCP which everyone can join.
  52. What a pile of crap !
    Can you actually provide reasonable arguments for all the shit you're spewing ? Can you provide any reason why the GPL is like the gulag, or a signle claim the GNU Classpath is "vaunted perfect", or anyone who blaims the RI for being more complete/not as restrictive ?
    And JT, I don't pray to any gods.
  53. all I stated is that he hates Java with a vengeance and wants it destroyed.He's in fact religious about that.

    ... which is of great interest, and no FUD at all, for sure...
    ;-P

    Have fun,

    Remi
  54. I think the main reason for all this tempest in a teapot is the interpretation of "Sun-only features":

    To a Java developer, that means classes from com.sun.* or sun.*

    But to RMS, those are all features that are present in Sun's JRE, but are not yet implemented in a GPL-licensed "JRE" (some GPL licensed VM + GNU Classpath).

    Sloppy language on his part - seems he's not aware there are other non-free J2SE implementations besides Sun's. He should call them "features not yet implemented in GNU Classpath". As he ended his pamphlet with a call for developers for GNU classpath, he really has no excuse for that piece of FUD.
  55. Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." is this statement valid?
    Simply, no. This really does sound like plain FUD. It is hard to imagine using com.sun.* classes 'without noticing', and the idea that you only find this out later is absurd.

    Stroustrup made similiar comments:

    "Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS."

    http://www.research.att.com/~bs/bs_faq.html#Java
  56. Stroustrup made similiar comments:"Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation.

    Well, this is the kind of thing that Stroustrup, as the designer of C++, would say. That it is wrong is clearly shown by existence of, for example, gcj. Java is a language with a rich set of standard libraries.
    It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS.

    It may not be language neutral, but that has not stopped a large number of languages being ported to it, including COBOL, LISP, Prolog, Modula, Pascal, Basic, Smalltalk... I'm not an expert, but as I understand it not that many VMs or OSes or (more importantly) instruction sets are that truly language neutral.
  57. Here comes UML/MDA[ Go to top ]

    Windows and UNIX are platforms, so we use JVM to abstract them to a common runtime.

    Java is a platform, so we'd better start to code Platform-Independent UML and use MDA to transform it to out Platform-specific models.

    Or, is UML and your MDA Tool a platform?

    Sadly, this kind of discussion happens to the detrement of productivity in places I have worked.

    I guess we just shoudn't code since eventually we have a dependency on something.
  58. Here comes UML/MDA[ Go to top ]

    I guess we just shoudn't code since eventually we have a dependency on something.

    LOL

    Very good.
  59. Stroustrup made similiar comments: "Java isn't platform independent; it is a platform."

    I appreciate Stroustrup .. his positive contributions in C++ were largely pulled into Java (and thus C#) so we should be thankful for the work he did and the usefulness that it provided in both C++, today's VM-based platforms and languages, and probably all future languages and platforms.

    Like many other pioneers, he doesn't accept that there is still unexplored country beyond where he stopped to stake his claim, so unfortunately he is forever cursed to be jealous of anything that goes beyond C++, even though he should be reveling in it instead.

    Java, as a language and a fairly complete set of standard libraries, is obviously a platform. That was already obvious in '96 .. Sun avoided calling it a "platform" solely to avoid positioning it directly against Windows etc.

    As for:
    .. you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation.

    I assume he means Sun. Despite the fact that Java is now the #1 programming language in the world, Sun's own relative fortunes have flagged considerably since the release of Java. One can only wish such "commercial benefit" on one's worst enemies.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  60. What he is saying[ Go to top ]

    I think he saying don't use sun jdk use a free jdk. Because the free jdk's are not complete. Saving you from rewriting to make a program work on a free (incomplete) jdk.

    Which makes perfect since. But would this be a problem if the free jdk could ever catch up...?

    Use gun-java (behind by a mile), not commercial-java...

    Guess FSF are limited to black and white vision only
  61. What he is saying[ Go to top ]

    Yeah, that was I figured too. The JVM itself is not open source and doesnt have flexible/open license like GPL. I suppose the same is true with the Linux port (Blackdown)

    I dont think Stallman is talking about com.sun.* packages, which is some low low implementation details which he doesn't care or will bother about

    IMHO, if sun were to release all of their _cool_ 'C' code that make up the JVM as GPL license along with the rest of libraries, then Mr. Stallman will be able to sleep tight. Also if they stop selling their SPARC/Solaris bundles as Java Desktop or what ever it makes it more clear of not having any vested interest

    Even the JCP process, that sets the direction for Java, as per many in this industry, is run corporations with vested interest in shaping Java so that make the money.
  62. What he is saying[ Go to top ]

    Yeah, that was I figured too. The JVM itself is not open source and doesnt have flexible/open license like GPL.

    Many of us would argue that the GPL is certainly not flexible. It has very strict requirements.
    I dont think Stallman is talking about com.sun.* packages, which is some low low implementation details which he doesn't care or will bother about

    It is hard to know what he is talking about. I assume it is sun.* and com.sun.* packages, as it is difficult to know what else he can mean, and little else is Sun-specific as far as I know.
    IMHO, if sun were to release all of their _cool_ 'C' code that make up the JVM as GPL license along with the rest of libraries, then Mr. Stallman will be able to sleep tight.

    It is not the JVM that is the concern, it is Java libraries shipped alongside the JVM in the JRE and JDK.
    Also if they stop selling their SPARC/Solaris bundles as Java Desktop or what ever it makes it more clear of not having any vested interest

    As I understand it Java Desktop is currently primarily Linux/x86, not Solaris/SPARC.
    Even the JCP process, that sets the direction for Java, as per many in this industry, is run corporations with vested interest in shaping Java so that make the money.

    Even if this were so, surely this is a good thing. If commercial companies are putting time and money into producing standards that have to be of commercial quality yet can be freely implemented, that is good for developers.
  63. What he is saying[ Go to top ]

    Yeah, that was I figured too. The JVM itself is not open source and doesnt have flexible/open license like GPL. I suppose the same is true with the Linux port (Blackdown)I dont think Stallman is talking about com.sun.* packages, .

    GPL is one of the most restrictive licenses in existence, not open at all.
    It's AFAIK the only license that forces users to adopt a specific license (itself that is) for their own products, thereby dictating the businessmodel of whomever is tricked into using it.

    Stallman is indeed not talking about a few packages, he's as usual ranting about Big Bad Corporations.
  64. com.sun.*[ Go to top ]

    I've been developing in Java for 6 years.. and I did not even know about the com.sun.* classes until recently. Then when I felt tempted to use one I quickly relented on my foolishness when I couldn't find the documentation (I didn't look real hard either).

    So no clue what RMS is saying. I bet he isn't a Java programmer. ::)
  65. com.sun.*[ Go to top ]

    I've been developing in Java for 6 years.. and I did not even know about the com.sun.* classes until recently. Then when I felt tempted to use one I quickly relented on my foolishness when I couldn't find the documentation (I didn't look real hard either).So no clue what RMS is saying. I bet he isn't a Java programmer. ::)

    I've been doing Java for 7 years, knew the classes existed and knew they're not meant for general use (in fact Sun mentions as much in their documentation, explicitly warning that they're for internal use by the JVM only and subject to change without notice.

    And indeed, RMS is no Java programmer. He's a C programmer (and probably some Perl, which btw is a language with much less community input on its development than is Java, it just happens to be controlled by some of his friends) who hates Java profoundly.
  66. com.sun.*[ Go to top ]

    And indeed, RMS is no Java programmer. He's a C programmer (and probably some Perl, which btw is a language with much less community input on its development than is Java, it just happens to be controlled by some of his friends) who hates Java profoundly.

    OK you're clearly one of those individuals who thinks the FSF is a bunch of commies and the Holocaust is really just a judaic conspiracy.
    I think this has got to be one of the most ill informed comments ever posted on TSS, clearly a runner-up to Rolf's rants.
    RMS also wrote Emacs, which has its own Lisp interpreter and dialect and most of Emacs is Lisp.
    And Perl has CPAN which is a well established and very large collection of Perl code that's community driven. I've never written more than a couple of lines of perl, but that doesn't mean I should be completely oblivious to the rest of the world.
  67. Perl[ Go to top ]

    For those that cannot be bothered to actually check their facts, quoth the CPAN main page:
    2005-05-13 online since 1995-10-26
    2862 MB 263 mirrors
    4338 authors 8026 modules
    What were you saying again?
  68. com.sun.*[ Go to top ]

    OK you're clearly one of those individuals who thinks the FSF is a bunch of commies and the Holocaust is really just a judaic conspiracy

    Truly amazing. Comparing the guy you disagree with to a Holocaust denier. Why should I pay any attention to anything else you say after something like that?
  69. This is just noise.

    The rules for producing a JDK/JVM implementation (that all implementers must follow, ostensibly any open-source producers as well) explicitly prohibit adding any classes/interfaces to java.* or javax.*, or adding any methods to existing interfaces. (This is what Microsoft allegedly did back in 1997 that caused Sun to sue them.)

    It's pretty hard to use a com.sun.* API "accidentally."

    Randy
  70. Yet that seems to be the core of the FSF's position against Java - that there's some kind of vendor lock-in to Sun. It seems to me that vendor lock-in is more a factor of programmer idiocy than any work on Sun's part.
  71. undocumented java[ Go to top ]

    there is undocumented java, not in tck. For example a soft hashmap, and some use it, mostly knowingly.

    It's like undocumented windows api. Make it harder to port.

    .V
  72. Religion[ Go to top ]

    Java works under the premis of "seporation of Church and Java". GNU is basically a religion. I have nothing against the religion of GNU, but Java works as a corporate product with a large amount of feedback/development from a user community. And honestly most of us seem to be happy with it and have no problem leaving it just as is.

    In the end sun will probably have to opensource java. Just as most government officals and leaders are having to procliam their religions faith to get public support for their ideas and proposals. Seems like an "idea" or "product" is not good enough these days, unless it is marketed under some religious context......
  73. In "The Java Trap," Richard Stallman writes: "If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months." This statement is being used to justify the FSF's request that OpenOffice 2.0 be delayed or supporters for a "free Java" be found.TSS asks: is this statement valid?

    Yes. There is a lot of bad code out there, and a lot of it seems to be copied and pasted from the same broken examples on the web. Sigh.
     While some com.sun.* classes are very useful (the JPEG codec comes to mind), use of the com.sun.* classes is hard to accidentally code, and is certainly not encouraged by Sun.

    They are not part of the specified APIs so they neither have clear defined semantics, nor are they guaranteed to exist on all implementations, certified or not. Using an unspecified runtime-specific API locks you into a specific version of a VM.
    In fact, it's more likely to occur in unlicensed or uncertified versions of the JVM, since they don't have the testing kit or the constraints it requires available to them.

    Hardly, as they are mostly missing stuff, rather than adding more unspecified cruft to it.
    Another aspect to RMS' statement is that "redoing the work" caused by accidental use of a Sun-specific API could "take more months." Is this an accurate statement?

    Yes. The work to fix OpenOffice.org took several months. And it is still not fully finished, there are various bits and pieces of sun-specific imports in a few sections, though he is fighting them down. See Caolan's blog for details.
    However, the Sun specific APIs are very low-level, consisting of rarely-used worker classes and GUI peers, which are definitely not deliberately exposed to the end-user.

    No need to tell me :) Nevertheless, some funny folks that insisted on writing their own Jar verifier thing in OpenOffice.org's sandbox module, complete with using a deprecated security API from within sun.* naming space. A masterstroke in portability. :)

    There was no way to get the thing to build with Kaffe until someone at Sun's OpenOffice team fixed the bug. I tried, and eventually went on to something more rewarding that wrestling with the OOo build system.
     However, do you think the concerns it has with Java - that using Java locks you in somehow to Sun - are valid?

    That is not what the Java Trap article actually says.

    It says that you should not use proprietary software as a foundation to build your software, and by extention, proprietary implementations of runtimes for programs written in the Java programming language.

    You should use free software implementations instead, as that way you can not write software that depends on some quirk in a proprietary implementation.

    Yeah, very idealistic, and all that, I know. But also very true, as my experience with OpenOffice.org and just about any other major application with huge (unmaintained?) blobs of Java code shows.
    However, Harmony is still likely to be encumbered with Sun's definition of Java, which would seem to violate the FSF's ideals.

    Hardly. The FSF has no problem with standards & their definitions. They just don't like non-free software that much.

    cheers,
    dalibor topic
  74. The work to fix OpenOffice.org took several months. And it is still not fully finished, there are various bits and pieces of sun-specific imports in a few sections, though he is fighting them down.

    Well, it actually is almost done, afaik. He's currently having a vacation, and his blog is at http://blogs.linux.ie/caolan/index.php

    Almost everything works fine by now using gcj.

    cheers,
    dalibor topic
  75. If a JVM is "missing stuff," then it's possible it's not a certifiable JVM, which the TCK would validate. If you don't have feature X, obviously all tests for X's functionality will fail.
  76. If a JVM is "missing stuff," then it's possible it's not a certifiable JVM, which the TCK would validate. If you don't have feature X, obviously all tests for X's functionality will fail.

    The broken phrase 'uncertified JVM' does not come from me but from the parent. No free software runtime has ever been certified as J2SE compatible.

    Yet.

    cheers,
    dalibor topic
  77. However, Harmony is still likely to be encumbered with Sun's definition of Java, which would seem to violate the FSF's ideals.
    Hardly. The FSF has no problem with standards &amp; their definitions. They just don't like non-free software that much.cheers,dalibor topic

    Not true. The FSF has problems with definitions they don't control.
    Their main adversity of Java is the very fact that it's a specification that's outside their control and that they can't fork it without loosing the right to call it Java.
  78. Hardly. The FSF has no problem with standards &amp;amp; their definitions. They just don't like non-free software that much.cheers,dalibor topic
    Not true. The FSF has problems with definitions they don't control.Their main adversity of Java is the very fact that it's a specification that's outside their control and that they can't fork it without loosing the right to call it Java.

    Oh I suppose you should know. After all, JT Wenting - isn't that the world renowned expert on FSF and their doctrine ?

    The GCC project is a GNU project right? Do you have _any_ idea how many languages does the compiler suite implement?
    Let's see, off the top of my head there's C, C++, Ada, Fortran, Objective C, Java. Of those none is under the control of the FSF as a specification. They're ALL outside their control, and they can't fork it without loosing the right to call it C, C++, Ada, Fortran, Objective C or Java.
    Duh ! Wake up, really, and stop spewing out such uninformed comments that defy reality grossly.
    Unless you're like 5 or something.
  79. (TSS UI guys -- buttons are in odd places...)

    Is anybody surprised that GNU zealots are up in arms about this, without understanding how the technology was implemented? Much like a political organization, their aim is to create FUD, not useful products, unless you adhere to their ideology. The insistence to precede Linux with GNU/, anyone?

    I figure that, if Java is good enough for a large portion of the Apache Foundation's projects, it's good enough for any other open-source project. As a long-time OOo advocate, and one who understands how the Java wizard dependencies work in OOo, it's hard for me to see how this is a problem. Those portions of the code can be implemented using gcj tools... assuming that they will ever fix their compatibility issues with the Java spec. Not with the com.sun.* packages but with the PUBLIC spec. The OOo folks already published instructions on how to do this.

    OpenOffice.org is a choice, one more tool that competes with Microsoft Office, KOffice, and a myriad of products. As a user, all I care about is that the tool does its job. As a developer, I respect the decisions made by the OOo implementation team. As an architect, I'd say to use the right tool for the right job. And as member of the community, I'd say to the GNU Free Software zealots to spend more time coding and less time bitching about non-issue licensing minutiae.

    Cheers,

    E
  80. For example, there are some areas that have interfaces defined within the JRE spec, but are implemented with sun classes in the background. For example, I think that https: is implemented this way when trying to open URLs as streams and such.

    Now, the spec doesn't say anything about https, yet the Sun implementation supports it.

    I believe there are other examples (someone mentioned JPEG) where the JRE specifies interfaces and factories, but not necessarily implementations and Sun back fills those with their own code.

    I don't consider this crippling, however.
  81. religious fanaticism[ Go to top ]

    Richar Stallman and his group of followers come across ever more as a religious sect of the worst kind.

    He's a prescribed Java hater and will stop at nothing to harm the platform. That's why he calls for Sun to abandon the JLS and JVMS (and as a consequence abandon the TCK) to his "loving" care so that he can destroy it.

    Now that Sun and ever more people outside his movement seem to have penetrated his lies about why he wants stewardship over the platform he changes tactics and tries to scare people away from the Big Bad Company who wants to subliminally force you to use its Evil Products instead of his own Divine Vision of Computing.

    There is no logic or truth to his claims, only religious fervor to further is own religious-political agenda and strengthen his control of the global open source movement, a lot of which is slipping away from his control as ever more open source is using Java instead of his own favoured C which would cause one to get locked into Mr. Stallman's world permanently when writing open source because he's the one who wrote that compiler.
  82. religious fanaticism[ Go to top ]

    So much ignorance in your comments, I can't even be bothered to address them.
  83. religious fanaticism[ Go to top ]

    There is no logic or truth to his claims, only religious fervor to further is own religious-political agenda and strengthen his control of the global open source movement

    Actually, RMS has shown open contempt to the open source movement because it steals mindshare away from the "free[dom] software" movement. (That's why people call it FOSS, meaning "Free[dom] and Open Source Software".)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  84. The man clearly knows nothing about Java.

    I am also sick to death of high school kids giving use lessons about the GNU religion and the "Free World".
  85. The man clearly knows nothing about Java.I am also sick to death of high school kids giving use lessons about the GNU religion and the "Free World".

    The Jack Jackson clearly has not even bothered to read the article he's talking about.
    I am also sick to death of high school kids giving us lessons on things they don't know shit about.
  86. The man clearly knows nothing about Java.I am also sick to death of high school kids giving use lessons about the GNU religion and the "Free World".
    The Jack Jackson clearly has not even bothered to read the article he's talking about.I am also sick to death of high school kids giving us lessons on things they don't know shit about.
    My humble apologies for insulting the great RS. (we are not worthy, we are not worthy....)

    FYI I did read the article.

    I am glad we agree about the high school kids.
  87. Perspective[ Go to top ]

    When you get down to it. OSS and proprietary software aren't so different in how development works. Ignore licensing stuff for a minute. Commercial software has just as many stupid idiotic fights. The difference is OSS throws it out to the public for everyone to see, whereas you won't see a corporation airing their dirty laundry.

    I find the whole argument rather pointless and waste of energy myself. I'll just keep on coding and Stallman can keep running around like a mad chicken.

    peter
  88. Yes, they are valid...[ Go to top ]

    FSF concerns are valid, at least with respect to FSF objectives.
    If the SUN's Java model turns out to produce better quality software with a large community support, thne maybe FSF GNU's model might be at risk.
    Consider that nowadays largest open source projects (Linux, OOo, Firefox) are backed by large corporations, which might decide to progressively 'drop' support for GNU (Stallman) and go for for more proprietary licenses...
  89. Maybe, just maybe, Stallman is not referring to the obvious. Isn' there something about the plublic, non-sun api that is vendor restricted?

    Technically speaking, I think Swing fits his description. Are there others?

    Swing fits his description becuase although it doesn't appear to be a sun only feature, but indeed, if you want this user interface library, you get it from Sun only, right? And also, a product written in Swing could require months of redevelopment to replace it.

    I haven't verified that Sun has the only implementation of Swing, so maybe it doesn't fit the description. Consider this a prototype: an example of another way of looking at Stallman's comment. Are there any libraries whose API are part of 'standard' j2se or j2ee and so appearing to be Free as in Freedom, but in practice, implementations of the API are strictly licensed (not Free as in Freedom) by their implementers?

    Sure don't want to cause any trouble on this fine web site, but Stallman is smart, despite some of the opinions held here, and not likely to get the obvious so wrong.
  90. I think I see it in a very different light. To me, Java Standard Libraries are java.*: Collections, Math, etc. (not com.sun.* that are implementations) so when Stallman says "you are liable to use Sun-only features without even noticing", he means simply that if the standard libraries to be implemented grow all the time, there migtht never be a free software JVM implementation.
  91. Is this just me who suspects that this article is deliberately misleading? The article repeatedly suggests that the main problem of the FSF guys is the usage of com.sun.* packages. That counterargument would be obviously silly, and I think this article tries to fraudulently discredit the concerns of the FSF. Correct me if I'm wrong, but I believe that the main problem of the sane FSF guys is that there is no working Free implementation of the Java platform, primarily because implementing the class library would be a huge work, not to mention keeping it compatible with the most widespread implementation (Sun's). Then, Sun extends the standard API so quickly that there hardly will be any Free implementation ever with acceptable version delay. So although your Java programs depends only on features that are part of the standard Java platform, in the reality those features are implemented only by Sun's Java platform implementation. Hence "you are liable to use Sun-only features without even noticing". This is a real concern, if we are talking about Free software (and we do). Also Richard Stallman refers to some licensing problems that makes it even harder to implement the standard API-s. Anyway, read this to see what did FSF said in reality: http://www.gnu.org/philosophy/java-trap.html
  92. Correct me if I'm wrong, but I believe that the main problem of the sane FSF guys is that there is no working Free implementation of the Java platform, primarily because implementing the class library would be a huge work, not to mention keeping it compatible with the most widespread implementation (Sun's).

    Sun's implementation is free.

    Please stop screwing around with my language (English) to make political points.
    Then, Sun extends the standard API so quickly ..

    It doesn't change that quickly. However, I think you could make a legitimate argument that more work should be made to "standardize" the API (instead of just to "implement" it, as Sun has largely done in the past). In other words, it bothers me how tightly coupled the API and the API-implementation are in Java.
    This is a real concern, if we are talking about Free software (and we do).

    No we don't ;-)

    However, I support your right to create a GPL'd version of Java, and I support the Apache group's right to create an open version of Java, and I support Sun's right to support or deny support to either / both.
    Also Richard Stallman refers to some licensing problems that makes it even harder to implement the standard API-s.

    That's unfortunate .. let's get Sun to address those issues. What can be done to fix it?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  93. Sun's implementation is free. Please stop screwing around with my language (English) to make political points.

    If somebody did screwing and political things here, then that was the author of this TSS article. He refers to the "Java-Trap" concern of FSF, and then he tries to render it to silly by suggesting that the problem of FSF with Java is the usage of the com.sun.* packages. This was a base thing, something like politicians used to do. The com.sun.* packages was not even mentioned in the linked FSF article (maybe this was a specific issue of Open Office 2.0, which is != FSF), so come on, tell me that the author has just accidentally misunderstood something. It is highly unlikely. Maybe it was some kind of revenge or biased rant on FSF after it dares to state that Java is not Free in reality, I don't know, and in fact I don't care. I don't even care too much if Java is Free (note the uppercase F), or if what is with FSF. I just wanted to point out that the article author seems to use a vicious trick here.
    Peace,

    Tell it to some of the Java guys who are rather behave as politicians than engineers. And of course they always want "peace", that is, shut up critical sound, while they shine as the nice and good guys who just want peace and developing software instead of spending time with silly debates. Therefore the criticizer is a nasty harmful guy. And, maybe also paranoid.

    Anyway... far enough. Who has the ear for it has already understood what I meant to say.
  94. I just wanted to point out that the article author seems to use a vicious trick here.

    I think in retrospect the article totally misunderstood what RMS was saying. However, RMS didn't do himself any favors in this regard, either. (He comes off as someone who learned Java from an article on slashdot, if you know what I mean.)
    Tell it to some of the Java guys who are rather behave as politicians than engineers. And of course they always want "peace", that is, shut up critical sound ..

    I don't think that's true at all, but if you're going to be critical, you can't have it both ways by wanting everyone to avoid being critical of the criticality.
    Therefore the criticizer is a nasty harmful guy. And, maybe also paranoid.Anyway...

    Just 'cause you're paranoid doesn't mean that everyone's not out to get you. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  95. search and replace 'sun-only'[ Go to top ]

    Maybe someone at FSF can do a search and replace of RMS's article to change 'SUN-only' to 'non-GNU'.

    It would make the whole thing pretty non-contentious, reasonably unambiguous, and would vent the steam of a few contributors here.

    BTW, I liked the way RMS tried (unsuccessfully) to divert the Java fury half way through the article by mentioning Windows as well... :)

    Cheers,
    Marcin
  96. Hot air and nonsense[ Go to top ]

    Guys,

    Who cares, get back to work and worry about something important rather than a load of nonsense.

    'nuff said

    "boardman" - I'd rather be boarding
  97. I just wanted to point out that the article author seems to use a vicious trick here.
    I think in retrospect the article totally misunderstood what RMS was saying.

    The TSS article is mostly a reaction to the "Free But Shackled - The Java Trap" article, it quotes from it... etc. It's hard to imagine that the TSS author has misunderstood that in this extent. (And again, the FSF article doesn't even have a single reference to com.sun.* API-s!)
    However, RMS didn't do himself any favors in this regard, either. (He comes off as someone who learned Java from an article on slashdot, if you know what I mean.)

    Maybe, but it is irrelevant. To tell whether a software is Free or there are concerns regarding that doesn't require you to master that software, but to be experienced with legal (licensing) issues. OK, it also needs the basic understanding of where/how Java fits into a system, and that in principle(!) it can be implemented by anybody, but we can safely assume that Stallman got it.

    BTW, another irrelevant point that is often brought up is that GNU guys should work on bringing GNU classpath to good shape instead of crying. Well, it seems they can't (yet), and I can imagine it's a very hard quest (and a never ending one... the standard Java API is constantly growing). But so what? Does it render the concern of FSF with Java invalid in any way? Of course it does not.
  98. It's hard to imagine that the TSS author has misunderstood that in this extent.
    Maybe to you. But not to me. I misunderstood too. Partially my fault. Partially RMS's. Partially ... . If you've ever taken a speech class you'd see where the problem lies.
  99. It's hard to imagine that the TSS author has misunderstood that in this extent.
    Maybe to you. But not to me. I misunderstood too. Partially my fault. Partially RMS's. Partially ... . If you've ever taken a speech class you'd see where the problem lies.

    I completely misunderstood, but, I think, in an understandable way. I think RMS's statement was misleading, and should have been phrased:

    "If you currently develop a Java program on a Java platform that has passed the TCK, you are liable to use features that 'free' versions of Java haven't implemented yet without even noticing."

    The emphasis on "Sun's Java" misled me, as the same 'trap' issue would arise with IBM's Java etc.
  100. It's hard to imagine that the TSS author has misunderstood that in this extent.
    Maybe to you. But not to me. I misunderstood too. Partially my fault. Partially RMS's. Partially ... . If you've ever taken a speech class you'd see where the problem lies.

    Where? Surely RSM’s article could be written better, but still, I can imagine 3 cases when one could misunderstood the "The Java Trap" article of Richard Stallman (this is what this TSS article is about, basically) on the way and in the extent as the author of the TSS article did:

    a) The reader's mind was already seriously infected with the absurd idea that the problem of FSF with Java is that usage of com.sun.* classes. (Again, it is not, and the quoted FSF article didn't mention this lame concern at all.)

    b) The reader has read RSM's article very very hastily and carelessly.

    c) The reader have some mental problems...

    And then add that this nonsense regarding the concerns of FSF is not from a hasty reply in a discussion, but this is the initial TSS article. This assumes some minimal care from the author. So, excuse me, but I would not bet on the goodwill of the TSS article author...
  101. It's hard to imagine that the TSS author has misunderstood that in this extent.
    Maybe to you. But not to me. I misunderstood too. Partially my fault. Partially RMS's. Partially ... . If you've ever taken a speech class you'd see where the problem lies.
    Where? Surely RSM’s article could be written better, but still, I can imagine 3 cases when one could misunderstood the "The Java Trap" article of Richard Stallman

    Or the 4th case. One reads Stallman's actual words:

    "Sun's implementation of Java is non-free. Blackdown is also non-free; it is an adaptation of Sun's proprietary code....

    If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing.

    Sun continues to develop additional "standard" Java libraries..."

    I would suggest that it is easy to miss Stallman's confusion of 'any 'non-free' Java that has passed the TCK' with 'Sun's Java'. I did. If you miss this, then it is reasonable, and not absurd at all, to assume that 'Sun-only features' means 'sun.* and com.sun.*' packages.
  102. Fully agreed.

    I think our problem (Java users) is precisely that we all say we "love free software" (we even have many so-called OSS projects), but we don't apply these principles to ourselves (at least most of us don't...) !

    The FSF's talk makes lot of sense actually, and I have to say it's "worrying" me (not that I'm not sleeping because of this but, you know...).
    Man, I never used any other VM than sun's... oh yes, there was blackdown too but apparently it's not free either :-/
    What about all my "hopes" about this movement ?

    I don't have time to really contribute to GNU Classpath (you can be sure I'll try it out).
    I need a robust, easy to use, and everything-I-love-in-Java platform for developing "finished" apps, deploy at my clients, etc...
    So what ?

    Get back to VIM/GCC ??? That's my worst nightmare, no way !!! ;-P

    Have fun,

    Remi - man, I jumped on the Java Trap...
  103. SLSTM[ Go to top ]

    Why would Sun produce the com.sun.* classes and then state that their use "is certainly not encouraged by Sun"?
  104. SLSTM[ Go to top ]

    Why would Sun produce the com.sun.* classes and then state that their use "is certainly not encouraged by Sun"?

    API versus API implementation.

    For example, the oft-cited base64 encoding question: There are com.sun.* classes that do base64 encoding, meaning that you can import com.sun.whatever.Base64Whatever and call its methods. Alternatively, you can pass the string "base64" to some method on some java.io class and it will return a java.io interface whose implementation comes from com.sun.*. In other words, you can achieve the same functionality either by using the standard API (which is portable) or by calling non-standard classes (which is only portable to JVMs that ship with a runtime library that is licensed from Sun). Obviously, if one uses the classes that come with the JDK but are not part of the Java standard, then the result is not "100% Pure Java".

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!