1. Cygnus made a business out of "fixing" GNU programs to meet customer needs. Cygwin was a means to increase their business.
2. BSD was portable across most compilers. GNU was convienent for BSD, because it was free and wasn't tied to a specific OS/Platform.
3. BSD and Linux of the time were very simple beasts (as OSes go). FreeBSD's design was considered so good in its simplicity, that they took far longer than Linux to switch to ELF instead of AOUT.
4. No one is denying that GCC was built by the FSF and volunteers. However, I am pointing out that the the GCC of then in no way compares to the beast that GCC is today. I still hear the complaints of GCC's performance (or lack thereof) ringing in my ears.
IIRC, the last Java GUI I used for any serious length of time was the Nokia J2ME SDK that I was using to develop Java apps for mobile phones.
Ugh. No wonder you think Java is slow. Nokia's Toolkit is absolutely horrible. I uninstalled the thing after using it for only a short while.
Compliance with copyright law is not nit picking.
You mean compliance with license terms. The JRE and JDK have licenses that allow bundling. RedHat used to bundle it with their desktop (not sure about their current server version) but won't bundle it with Fedora because of the stated goals of the project. FreeBSD is a non-issue since Sun doesn't distribute a binary JVM for that platform. (Although a binary 1.1.8 JVM is still available and under binary licensing.)
The project I'm working with doesn't have a lawyer as far as I can tell, so I'm helping them out. I'm getting clarification from Sun on the clauses that concern him, so we'll soon know if Sun is really being a bastard or has been given a bad rap.
What I mean is, the GNU project has multiple implementations of libraries, syntaxes and compilers. Your claim that they can't produce something as complex as Java is false because they already have implemented something as complex as Java.
No, my claim is that the FSF can't independently create anything as complex as Java. You're not saying anything to disprove that assertion.
Actually, I was just reading a thread elsewhere where Java aficionados were ranting about how Python was such a sloppy language and couldn't be as fast as Java.
*chuckle* Well, I guess what goes around comes around.
Supported by corporations? Hello? For example, Apple just donated tons of code to get GCC running on their systesm. Many Unix and embedded OSes help develop GCC because they want a compiler that can meet their needs. The GCC that GNU put out years ago was a very simplistic and not too useful beast in comparison to today's GCC. (Remember EGCS?)
For example, there's no other platform that has as many high quality, cross platform database drivers
perldoc DBI ODBC
Sorry, that doesn't stack up. On PerlDoc DBI, what if I need to connect to Pervasive 2000 (formerly BTrieve). This is a VERY popular database for converting mainframes. With Perl:DBI and unixODBC, I'm out of luck. With JDBC, the vendor provides support. Even if I want to connect to the big name databases with unixODBC, I have to pay for third party drivers. The vendor isn't going to support me. And I still have no support if I go outside of the big name databases.
It's a nice try, but only ODBC on windows comes even close to the amount of database support provided by Java.
What's the need for them all in an office suit? You need one mediocre-but-tiny implementation for Access-like features, and the ability to connect to real servers.
You just said it. "The ability to connect to real servers." JDBC allows you to do this for free, and get vendor support. This is a big point when you consider the value of corporate data stored in an Oracle, DB2, or Pervasive database. In addition, the smaller Java databases are all good options for embedding into OpenOfice whereas there are practically no non-Java options. The only one I found was SQLite, and they don't ship an ODBC driver. (Although there is a third party experimental driver, but it is not mature enough for use. Interestingly, that same third party produces a JDBC driver for SQLite.)
In F/OSS world, anything is "more unbiquitous" than Java - because no freeNIX ships with a real java implementation.
No worries. As I remember, OOo ships with the JRE.:-)
1. Where do you live? Iraq? 2. Export controls apply to Open Source software as well. This isn't Sun's fault, it's the US government.
In short, your argument is a non-argument. I'm sorry you can't get the software, but there's not much that can be done about it as long as it's produced by a US entity.
When I start a desktop application up that is written in Java it feels sluggish.
I assume you have a fairly recent JVM installed, no? Click here, use it to clean out your hard drive, and tell me if it improves your impression at all. Another really great Java app is Azureus. Are you already using it perhaps? There also used to be a really great Gnutella client called Furi up until Limewire stunk up the place. (In all fairness to Limewire, it has gotten better too. But they really need to ditch the custom L&F for something more platform standard.)
I suppose it's something of a double edged sword. As Java gets better fewer people realize that it's Java. Which means that the old ideas never die.
If you want people to stop calling Java slow, then by all means, speed it up some more, but don't get upset when people call a spade a spade, and don't call them stupid for doing so.
*sigh* The Swing GUI is actually running faster than Windows apps. Various tests have been done that have shown that during heavy GUI updates Windows programs skip several updates while the Java program always displayed every update in the same period of time.
If I can ask an honest question, what was the last Java GUI you used? Be honest, because I'm really curious at what is continuing to give Java a bad name.
All programming languages suck.
True 'dat.
Correct me if I'm wrong, but there's still difficulty simply distributing it, isn't there?
You're wrong. Java is completely free to bundle in binary form, and the Java Research License on the Mustang development path only requires that any recipients agree to the JRL license. No commerical use of the source code is allowed without negotiating a license with Sun.
As far as I can interpret the license, there is no issue with bundling it with Linux OSes. However, the upper-echelons of the OSS community have demonized the JVM and have found a few nits to pick. I'm already working with Sun to get clarification for them since the ones I've talked to don't want to do a tiny bit of legwork.
Or do you define "main OSS community" as "the subset of OSS developers that don't like Java", in which case that's pretty much a tautology and not worth mentioning?
More or less what is considered the "movers and shakers" of the OSS community. For example, we've heard from both Stallman and de Icaza about how "evil" Java is. Personally, I just think they're jealous (especially de Icaza) but it doesn't help Java's image any.
I don't feel the need to specifically attack Stallman for it though, and I think it's unjustified when you do it.
Sorry, but he is the leader of the FSF. AFAIK, blame rests squarely with him. If we're going to blame anyone that is. I really don't care that Hurd is not done after 14 years, but when you contrast it to the FSF's policy of "set it free" (i.e. "give it to us") you have to wonder why they think they'd be a better custodian?
And if we're talking about Java we're only talking about a collection of libraries, a syntax, and some compiler technology. The FSF have implemented those things multiple times.
If that were true, we wouldn't be talking. We'd be using GCJ/Kaffe and everyone would be happy. The reason why everyone isn't happy is that GCJ/Classpath/Kaffe have not been successful in producing a complete JVM. It shouldn't be as hard as they make it out to be, but for some reason it is.
If you choose to, you can decompose most software into smaller components. But I guess it suits your agenda to only do it for GNU and not for Java.
Nonsense. Let's do it right now:
GCC vs. JavaC -> GCC is obviously more complex. GCJ vs. Hotspot -> Hotspot has some of the most complex technology ever developed for
but they pretty blatantly dissed the Blackdown project and that's not honorable in my book.
Whoa, whoa, whoa. When did Sun blatently dis' the Blackdown project? I was there when this happened, and as I remember it as an error of ommission. Blackdown had worked on the JVM for years, and then one day Sun suddenly announces a Linux JVM without any credit given to Blackdown's work. A lot of people got upset about this ommission, and Sun came out with a public apology. Is there something you know that I don't?
Yes it is. The Sun's java licence explicitly forbids me to use it. In fact, even the website refuses to let me download it. I believe that is a pretty big 'standing in my way'.
B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights.
I also just grabbed the jarball without any issue. You were following Mustang link I provided, weren't you?
And that's why we've put up with it. For 10 YEARS that is. Very little of it was true as of 7 years ago, much less today. Yet people keep uttering the same stupidities. Is it any wonder why Java developers are ready to storm the gates?
In the last article on this subject I called the OSS fanatics "Assholes" for their treatment of Java and its developers. You might be amazed if you go back and check how many people agree with me.
That has no place in the topic at hand, it was a cheap shot because you were pissed off and wanted to piss off others.
It wasn't just a cheap shot. I really DID feel that way when I posted. In a previous post, you'll find that I mentioned spending time investigating Mach and OS X. That's true, and the investigations also lead me to Hurd. After looking Hurd up and down, left and right, I was absolutely shocked at how little progress has been made in its 14 years of development. Tracing the lines through a bit, it's easy to find that what I say is true. The FSF can't produce anything of complexity, and has no right to demand that someone else give them such things.
Yes it is. There have been Debian GNU/HURD distributions built for years.
Score one for the exception. Except for the fact that mentioning this exception is a really bad idea. If you want to hold up GNU/HURD as your example, one could come to the conclusion that "GNU" is a crappy, unstable system that took 14 years to build to its currently poor state.
Your ignorance of the FSF and GNU are showing.
Nonsense. I don't expect everyone to buy into all of Sun's crazy ass Java branding (I know I don't), so why should I buy into all of Stallman's crazy ass branding? When it comes down to it, we're only talking a collection of programs. It's a bit like if SourceForge suddenly decided that every program coming out of SF had to have the "SF" moniker attached because it's part of the "SF System".
Given the piss poor code I've seen from other languages, Java is almost certainly faster in many cases.
This is where Java shines. Since most of the performance enhancements are in the JVM, it can make even a bad programmer look quite good.;-)
Of course, a truely good programmer can produce high performance code in just about any language.:-)
Don't forget that Java is basically a cost-free modern platform to get your hands on. I'm sure there are a lot of students and amateurs that download it, but unfortunately that article isn't going to show the differences between them and professionals.
I understand the difficulties in finding accurate numbers, but I've seen quite a few figures that suggest we're well into the millions. For example, these figures from 1998 show 2,000,000 downloads of the JDK, but estimates only about 700,000 developers. Given their nearly 3:1 ratio, I have to say that Sun is probably being pretty honest. Also, the figures for Java in the employment marketplace (both from "professional" surveys and ad-hoc queries of Monster and Dice) show a staggering percentage of Java marketshare. If the figures are to be believed, Java has more marketshare than all other languages combined. Quite a good time to be a Java programmer, quite a bad time to be anything else.:-)
Just to interject on a small point. The only thing you mentioned there that is part of the OS is the kernel. This annoys the hell out of me. An operating system is the software system that operates the hardware. An operating system provides the foundation on which you build a system usable by programmers or users, but it is NOT that entire system.
Depends on who you ask. If you ask Stallman, Linux is "just a kernel" and the GNU userland is the most important part of the OS. Viva la GNU/Linux! (Whatever.:-))
However, the Free software community has developed solutions that are infinately more complex (like the Linux kernel).
The ability of the Free software community to help out is why Sun has Java development open to all developers. They even developed a license that doesn't threaten developer's ability to then work on an OSS version.
Actually even the first release of the kernel written by Linus alone was beyond the complexity of Java (although it hardly had the QA and stability of sun java).
If you're comparing Linux 1.0 to Java 1.0, then I'd say you're correct. But as far as complexity goes, Linux 1.0 was nowhere near as complex as Hotspot, the JVM libraries, and the various other components of the JVM. Trust me, the software running under the hood of Java is very much "next level" stuff. Most of the optimizations for the JVM had to be developed by Sun, because no one had developed an OOP system on this scale before.
You have to load the Java VM and initialize it. That takes a fair bit of time and memory. Then you have to convert the bytecode to native instructions (!!) and execute them.
Of course, all of this happens at startup and is a one time cost. The ongoing savings of a long time program can easily make up for this cost. Java programs tend to compare most favorably with large programs that take several seconds to start up. An equivalent Java program does the same, but provides better performance in the long run. (Server side applications are particularly good at taking advantage of this.)
A virtual machine can be an emulator. A VM is just not strictly an emulator in the modern definition. But it does create a fake environment that the code is "compiled" to. That "compiled" bytecode then has to be converted to native code to execute. You have abstraction between your code and everything else.
You're not saying anything I don't know. I did chose to use the modern distinction between a VM and an emulator, but that's primarily because the two ARE quite different these days.
Way back in the day we had a way of loading code dynamically without shared objects. They were called overlays. You literally loaded them on top of another segment of code. This was done mostly to get around memory limitations.
These two are like the Wright Brothers' first airplane compared to a 747. Java can not only load code dynamically, it can investigate it and tell you all kinds of wonderful things about the code. In JavaBean land, this allows components to be dynamically plugged in, and properties to be made available by reading in their "getXXX()" and "setXXX()" methods. Similarly, JSP pages are possible (and of high performance) because the page can be translated into Java, then loaded dynamically. The exception mechanism combined with the sandbox mechanism ensure that one of those pages can never crash the entire JVM either by accident or by intention. (Of course, in the real world there are some ways of exploiting the underlying OS's limits to crash the JVM, but overall systems are very highly protected against failure.)
Anything you can do in Java, I can do in C/C++. Java is written in C/C++!
Show me a dynamically compiled JSP-like system without resorting to a bytecode design. It's pretty darn hard, isn't it? How about a self-organizing code system that consists of nothing more than a bunch of SPI modules strung together? Not impossible, but quite difficult to do in C/C++.
The argument that C can do anything Java can do is just silly. Of course the same effects can be replicated, because both run on a computer. The features of the Java language, OTOH, make these things *easy* and *low cost*.
Also, don't get your hopes up about those "millions of other professional developers". I doubt there are millions of developers, and most are certainly not Java devs.
Apparently, the surveys say differently. Considering the number of JDK downloads alone suggests that we're well into the millions of developers. Trust me, Java is THE most popular development platform at the moment.
This is still a point that is heavily contested. This is hardly "evidence" of a dishonorable act, especially since SCO really did have software that Sun needed for their x86 verison of Solaris. Sun has ALWAYS been very good about keeping their licenses in row.
You'll note that you linked to a public apology. Sun screwed up and then admitted their mistake. It happens. If they *hadn't* admitted their mistake and given Blackdown their proper acknowledgement, then you'd have a case.:-)
If you read my original post, you'd find that I have looked at the OOo source code and found no usage of "hidden" APIs. The closest thing that exists is a point where the JVM's AWT package is plugged into OOo. Plugin code exists for Sun and other JVMs. Any open source JVMs (e.g. GCJ) merely need to add their own plugin code. You'll note that JVM providers are just as responsible for web browser plugin code.
I've said it before, and I'll say it again. Sun has removed all of the sun.* references from OpenOffice itself. If RedHat developers are having trouble compiling, it's because they don't understand how to plug their JVM in. I'm sure that this was resolved on the OOo mailing lists within an hour or two.
Sir, you have failed to provide any evidence for your assertions. I have pointed out quite a bit of evidence in the form of JDBC support, embeddable JVM alternatives, and have done the footwork inside the OpenOffice code to verfiy that there are no "hidden" APIs in use. If you want to refute that, then you are welcome to do so, but for now you are just trolling.
How is that not true? The new JRL license is still very limiting. In order to distribute and give away what you do, you still need to agree to agree with Sun's commercial agreement:
Don't confuse the issue. You said: "This has serious impacts on the GNU foundation creating an Open JVM, for example, if you use their source to create your own JVM, you can only give out your executable to those who agree to the sun license and other third parties only for the purposes of evaluation."
I pointed out that the JRL fully allows for knowledge gained to be transferred to an independent product. Confusing the ability to reimplement with the ability to redistribute the original code is ANOTHER disingenuous argument. (We've been getting a lot of them lately.)
The trademark issue is a HUGE issue. If a product claims to want Java.
As I said, Sun will give you trademark usage rights if you pass the TCK. If you can't pass the TCK, then you're not Java. If you're not Java, then why should you get to use the trademark?
Does TCK still cost money? It used to and if I remember right, was quite a bit
Sun has extended no-cost access to the TCK to open source projects several times. To date, only derivitives of Sun's source code (e.g. Blackdown and FreeBSD) have taken them up on their offer.
You just missed my entire point. There's a hell of alot more damage one can do by buying Java
No, I'm not missing the point. I'm trying to point out that it's a stupid argument. It's been argued to death 5 billion times, and it's no more reasonable now than it was then. Hell, it's less reasonable considering the number of Java licensees who can distribute JVMs independent of Sun. (e.g. Blackdown, IBM, JRockit)
Personal use. I'd hardly call the GNU foundation creating a Java clone based on the code they get by agreeing to the JRL to be personal use. Most likely, they'd get slapped by sun.
You're misinterpreting an explantion of the license. You need a commercial license if your code derives from Sun's. From TFL:
Sun is licensing the Technology under this Java Research License (the "License") to promote research, education, innovation, and development using the Technology.
[...]
B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights.
[...]
A. License and Copyright Notices. You must include a copy of this Java Research License in a Readme file for any Technology or Modifications you distribute. You must also include the following statement, "Use and distribution of this technology is subject to the Java Research License included herein",
Sounds reasonable enough to me. Especially the part about being able to retain what you remember. No, they don't give explicit access to patents, but that shouldn't stop anyone. If it does, then might I suggest asking nicely? There's no evidence that Sun would say "no", and in fact most evidence suggests they would probably be open to doing so.
I looked at Java several times, each time concluding it was a castrated C++
This may be your opinion, but I think that if you look beyond your prejudices, you'll find that Java is so much more. For example, C/C++ code can't dynamically load individual components (i.e. reflection) without extra metadata (e.g. a shared library).
the only available compiler was for a machine that didn't exist
You're pulling out nonsense now. Javac being a Java program is a GOOD thing because it is portable and available to Java programs. If you don't like it, go use Jikes. (Jikes is open source and runs natively.) Truth be told though, the Java compiler doesn't matter. Due to the bytecode design, there isn't much room at that level for optimization.
because for some daft reason they had decided to write the emulator first instead of the usual process of doing it AFTER the real hardware was no longer available.
Java is not an emulator. It is a virtual machine. The two are very different concepts and have very different performance characteristics. Emulating hardware is usually very slow. VM code, however, gains the advantage of being compiled at runtime thus making it both portable and sometimes FASTER than native code.
If you have a problem with this, I suggest you take it up with the inventors of P-Code
(Lots more whining and insults)
Don't worry, your insults toward myself and millions of other professional developers shall not deter me from getting your Java licensing issues resovled! The next version of White Box Linux shall have Java!
1) To get Sun's source code, I believe you have to agree to the terms of Sun's community license, which has some severe limitations on how it can be used.
Sir, if you had read my post, you would know that this is not true any longer. Bringing up a point that is thoroughly refuted is very aggravating.
The Java Specification is very useful for helping to create a Java-like language. However, the implementation details make creating a full Java clone next to impossible with just the spec.
The spec has 99% of what is needed. It is not impossible to create a clone from it, especially when there is a community available to explain to you where things function incorrectly. Even if this complaint were true, Sun has released the source code of Java under a license where it can be all but outright copied. Please see my original post at the top of this thread.
You can't really use the Java trademark to refer to your own Open JVM.
This shouldn't be an issue for anyone. Even if it is, Sun has granted access to the trademark to Open projects. You only have to pass the TCK compatibilty tests.
Sun is trying to make it seem like they're very open source savvy, but what it boils down to is that they want as much control as Java as they can get. In many ways they are just as insidious as microsoft is. (FYI, I am a java developer and get paid to do Java. I like the language, and use it on it's technical merits, but the licensing sucks)
Pure, unadulterated nonsense. Sun has been trying to open up Java as much as possible without losing their copyrights, patents, and trademarks. There isn't anything in the way of OSS developers other than imaginary demons.
Linux could be forced to be renamed, but realistically, that's not a problem.
Realistically, someone with money can have Java reimplemented in no time. That's not a problem.
It's just not an "AKAImBatman" post without an insult at the end, is it?
Sorry about that, but as you can tell I have a lot of pent up feelings about this issue. From day one all we Java developers have heard from the main OSS community is "Java is not free, Java is slow, Java sucks". This has been very much a last straw for me. I'm so pissed off, that I even took the lead on resolving the supposed "licensing issues" that are preventing Linux distributions from redistributing Java. With any luck, we'll see the one I'm working with including it soon.:-)
The "corporate backers" clause is irrelevant. The FSF (it's not called "The GNU Foundation") is fully capable of managing highly complex projects (which was your original claim).
Fair enough. The FSF has not proven its ability to manage these projects without corporate backing. Right now the FSF's concern is that Sun will disappear or tighten up restrictions. Look at it from the other side, though. Sun has invested a considerable amount in Java and has made it central to their business. Why should they take the risk that other corporate backing will dry up and they will be left to fund BOTH Java and the FSF?
Stallman's position on Java doesn't rely on corporate backers, it depends solely on how Java meets his ideals.
His position may not, but his ability to produce does. If he can't demonstrate that he is secure enough to be a custodian for Java, why should Sun trust him to be one? It's far better for everyone if Sun maintains control, but gives away all the info necessary to replicate their feat. I imagine that they're also getting pretty frustrated at the lack of a compliant GPL JVM. But since such a beast is not required by their business, they're not going to fund it.
GNU is not just "'ls' and 'tar'". It's an *entire OS*, including libraries, a kernel, etc. It's a far *larger* project than Java.
GNU is NOT an entire OS. There is the Linux kernel which is maintained by corporate backing. That is not in the FSF's posession. (At least, the last time I checked.) Then there is the X11 system. Also supported by corporate backing and also not in the FSF's posession. Then there is KDE and GNOME which are not in the FSF's posession. By the time you whittle it down, you find that "GNU" consists of a wide variety of command line tools, most of which are standalone and have nothing to do with each other. The few complex pieces (e.g. GCC) again are supported directly by corporations.
Sir, you have attempted to answer the question without answering it. Here are the points which are unresolved:
1. You need to provide evidence of specific difficulties that RedHat had with OOo. Right now there is no evidence that they have had any difficulties. Suggesting that someone else find the evidence for you (by digging through mailing lists) is silly. If you can't produce any examples of the issues they had, then it is not feasible to claim they had issues.
2. Brushing me off as a "Java Fanboy" does nothing to refute my assertions that no other platform has as complete of a DB support system. You must provide an example of a comparable technology that could have been used.
3. You have not backed up the argument that the FSF is a good custodian for Java. The success of Linux in the marketplace can be traced to heavy support from Oracle, IBM, Sun, and other large companies with deep pockets. Large projects without that backing (e.g. Hurd) show not only a lack of progress, but a lack of GNU employed resources.
4. The success of Microsoft Windows as a server OS has shown quite well that "fanboys" can put significant pressure on companies in large quantities. Windows 95 was in no way ready to replace Unix in many areas of usage, but was pressed into service because that is what customers wanted. The same thing happened with Linux.
1. You don't pay for that extra hardware. It's there for you to rent when you need it.
2. Installation of extra components (I believe) is covered by the contract. i.e. You only pay to rent the hardware.
Seriously, talk with a Sun rep and see if it works for your company. It may not, in which case nothing is lost. But if it will work, then you can *save* money.
Okay, this is spiraling out of control. Let me restate my position in cool terms, and then I am exiting this conversation before I get really heated up.
1. Stallman doesn't like Java because no GPLed version exists. 2. No GPLed version exists because the OSS community has failed to produce a fully functional version. 3. The GNU Foundation has not been able to show that it can produce a *singular* project of the complexity of Java without the assistance of major corporate backers. 4. GPLed Java versions don't exist for want of corporate backers. i.e. The industry feels no pressure to produce one when Sun is already so open. 5. Major corporate backers are not a bad thing. However, handing over software of Java's complexity to the GNU Foundation is suicide without those backers. 6. The fact that 'ls' and 'tar' exist in the same bundle of software does nothing to show that the GNU Foundation is ready to take on the challenge of maintaining Java. Nor does it equal Java's complexity any more than the combined output of Sourceforge exceeding the complexity of Windows XP.
Now if you'll excuse me, I am done with laying out pearls before those here.
Slashdot Mirror
1. Cygnus made a business out of "fixing" GNU programs to meet customer needs. Cygwin was a means to increase their business.
2. BSD was portable across most compilers. GNU was convienent for BSD, because it was free and wasn't tied to a specific OS/Platform.
3. BSD and Linux of the time were very simple beasts (as OSes go). FreeBSD's design was considered so good in its simplicity, that they took far longer than Linux to switch to ELF instead of AOUT.
4. No one is denying that GCC was built by the FSF and volunteers. However, I am pointing out that the the GCC of then in no way compares to the beast that GCC is today. I still hear the complaints of GCC's performance (or lack thereof) ringing in my ears.
MS is just doing what MS does best, adopt and improve.
;-)
You misspelled "embrace and extend".
IIRC, the last Java GUI I used for any serious length of time was the Nokia J2ME SDK that I was using to develop Java apps for mobile phones.
Ugh. No wonder you think Java is slow. Nokia's Toolkit is absolutely horrible. I uninstalled the thing after using it for only a short while.
Compliance with copyright law is not nit picking.
You mean compliance with license terms. The JRE and JDK have licenses that allow bundling. RedHat used to bundle it with their desktop (not sure about their current server version) but won't bundle it with Fedora because of the stated goals of the project. FreeBSD is a non-issue since Sun doesn't distribute a binary JVM for that platform. (Although a binary 1.1.8 JVM is still available and under binary licensing.)
The project I'm working with doesn't have a lawyer as far as I can tell, so I'm helping them out. I'm getting clarification from Sun on the clauses that concern him, so we'll soon know if Sun is really being a bastard or has been given a bad rap.
What I mean is, the GNU project has multiple implementations of libraries, syntaxes and compilers. Your claim that they can't produce something as complex as Java is false because they already have implemented something as complex as Java.
No, my claim is that the FSF can't independently create anything as complex as Java. You're not saying anything to disprove that assertion.
Actually, I was just reading a thread elsewhere where Java aficionados were ranting about how Python was such a sloppy language and couldn't be as fast as Java.
*chuckle* Well, I guess what goes around comes around.
Supported by corporations? Hello? For example, Apple just donated tons of code to get GCC running on their systesm. Many Unix and embedded OSes help develop GCC because they want a compiler that can meet their needs. The GCC that GNU put out years ago was a very simplistic and not too useful beast in comparison to today's GCC. (Remember EGCS?)
For example, there's no other platform that has as many high quality, cross platform database drivers
:-)
perldoc DBI
ODBC
Sorry, that doesn't stack up. On PerlDoc DBI, what if I need to connect to Pervasive 2000 (formerly BTrieve). This is a VERY popular database for converting mainframes. With Perl:DBI and unixODBC, I'm out of luck. With JDBC, the vendor provides support. Even if I want to connect to the big name databases with unixODBC, I have to pay for third party drivers. The vendor isn't going to support me. And I still have no support if I go outside of the big name databases.
It's a nice try, but only ODBC on windows comes even close to the amount of database support provided by Java.
What's the need for them all in an office suit? You need one mediocre-but-tiny implementation for Access-like features, and the ability to connect to real servers.
You just said it. "The ability to connect to real servers." JDBC allows you to do this for free, and get vendor support. This is a big point when you consider the value of corporate data stored in an Oracle, DB2, or Pervasive database. In addition, the smaller Java databases are all good options for embedding into OpenOfice whereas there are practically no non-Java options. The only one I found was SQLite, and they don't ship an ODBC driver. (Although there is a third party experimental driver, but it is not mature enough for use. Interestingly, that same third party produces a JDBC driver for SQLite.)
In F/OSS world, anything is "more unbiquitous" than Java - because no freeNIX ships with a real java implementation.
No worries. As I remember, OOo ships with the JRE.
Oookaayy.
1. Where do you live? Iraq?
2. Export controls apply to Open Source software as well. This isn't Sun's fault, it's the US government.
In short, your argument is a non-argument. I'm sorry you can't get the software, but there's not much that can be done about it as long as it's produced by a US entity.
When I start a desktop application up that is written in Java it feels sluggish.
I assume you have a fairly recent JVM installed, no? Click here, use it to clean out your hard drive, and tell me if it improves your impression at all. Another really great Java app is Azureus. Are you already using it perhaps? There also used to be a really great Gnutella client called Furi up until Limewire stunk up the place. (In all fairness to Limewire, it has gotten better too. But they really need to ditch the custom L&F for something more platform standard.)
I suppose it's something of a double edged sword. As Java gets better fewer people realize that it's Java. Which means that the old ideas never die.
If you want people to stop calling Java slow, then by all means, speed it up some more, but don't get upset when people call a spade a spade, and don't call them stupid for doing so.
*sigh* The Swing GUI is actually running faster than Windows apps. Various tests have been done that have shown that during heavy GUI updates Windows programs skip several updates while the Java program always displayed every update in the same period of time.
If I can ask an honest question, what was the last Java GUI you used? Be honest, because I'm really curious at what is continuing to give Java a bad name.
All programming languages suck.
True 'dat.
Correct me if I'm wrong, but there's still difficulty simply distributing it, isn't there?
You're wrong. Java is completely free to bundle in binary form, and the Java Research License on the Mustang development path only requires that any recipients agree to the JRL license. No commerical use of the source code is allowed without negotiating a license with Sun.
As far as I can interpret the license, there is no issue with bundling it with Linux OSes. However, the upper-echelons of the OSS community have demonized the JVM and have found a few nits to pick. I'm already working with Sun to get clarification for them since the ones I've talked to don't want to do a tiny bit of legwork.
Or do you define "main OSS community" as "the subset of OSS developers that don't like Java", in which case that's pretty much a tautology and not worth mentioning?
More or less what is considered the "movers and shakers" of the OSS community. For example, we've heard from both Stallman and de Icaza about how "evil" Java is. Personally, I just think they're jealous (especially de Icaza) but it doesn't help Java's image any.
I don't feel the need to specifically attack Stallman for it though, and I think it's unjustified when you do it.
Sorry, but he is the leader of the FSF. AFAIK, blame rests squarely with him. If we're going to blame anyone that is. I really don't care that Hurd is not done after 14 years, but when you contrast it to the FSF's policy of "set it free" (i.e. "give it to us") you have to wonder why they think they'd be a better custodian?
And if we're talking about Java we're only talking about a collection of libraries, a syntax, and some compiler technology. The FSF have implemented those things multiple times.
If that were true, we wouldn't be talking. We'd be using GCJ/Kaffe and everyone would be happy. The reason why everyone isn't happy is that GCJ/Classpath/Kaffe have not been successful in producing a complete JVM. It shouldn't be as hard as they make it out to be, but for some reason it is.
If you choose to, you can decompose most software into smaller components. But I guess it suits your agenda to only do it for GNU and not for Java.
Nonsense. Let's do it right now:
GCC vs. JavaC -> GCC is obviously more complex.
GCJ vs. Hotspot -> Hotspot has some of the most complex technology ever developed for
but they pretty blatantly dissed the Blackdown project and that's not honorable in my book.
Whoa, whoa, whoa. When did Sun blatently dis' the Blackdown project? I was there when this happened, and as I remember it as an error of ommission. Blackdown had worked on the JVM for years, and then one day Sun suddenly announces a Linux JVM without any credit given to Blackdown's work. A lot of people got upset about this ommission, and Sun came out with a public apology. Is there something you know that I don't?
I'm not sure how you're disagreeing with me when you're repeating the same thing I said? *shrug*
Nonsense. From the JRL:
I also just grabbed the jarball without any issue. You were following Mustang link I provided, weren't you?
And on day one, that was true.
And that's why we've put up with it. For 10 YEARS that is. Very little of it was true as of 7 years ago, much less today. Yet people keep uttering the same stupidities. Is it any wonder why Java developers are ready to storm the gates?
In the last article on this subject I called the OSS fanatics "Assholes" for their treatment of Java and its developers. You might be amazed if you go back and check how many people agree with me.
That has no place in the topic at hand, it was a cheap shot because you were pissed off and wanted to piss off others.
It wasn't just a cheap shot. I really DID feel that way when I posted. In a previous post, you'll find that I mentioned spending time investigating Mach and OS X. That's true, and the investigations also lead me to Hurd. After looking Hurd up and down, left and right, I was absolutely shocked at how little progress has been made in its 14 years of development. Tracing the lines through a bit, it's easy to find that what I say is true. The FSF can't produce anything of complexity, and has no right to demand that someone else give them such things.
Yes it is. There have been Debian GNU/HURD distributions built for years.
Score one for the exception. Except for the fact that mentioning this exception is a really bad idea. If you want to hold up GNU/HURD as your example, one could come to the conclusion that "GNU" is a crappy, unstable system that took 14 years to build to its currently poor state.
Your ignorance of the FSF and GNU are showing.
Nonsense. I don't expect everyone to buy into all of Sun's crazy ass Java branding (I know I don't), so why should I buy into all of Stallman's crazy ass branding? When it comes down to it, we're only talking a collection of programs. It's a bit like if SourceForge suddenly decided that every program coming out of SF had to have the "SF" moniker attached because it's part of the "SF System".
Given the piss poor code I've seen from other languages, Java is almost certainly faster in many cases.
;-)
:-)
:-)
This is where Java shines. Since most of the performance enhancements are in the JVM, it can make even a bad programmer look quite good.
Of course, a truely good programmer can produce high performance code in just about any language.
Don't forget that Java is basically a cost-free modern platform to get your hands on. I'm sure there are a lot of students and amateurs that download it, but unfortunately that article isn't going to show the differences between them and professionals.
I understand the difficulties in finding accurate numbers, but I've seen quite a few figures that suggest we're well into the millions. For example, these figures from 1998 show 2,000,000 downloads of the JDK, but estimates only about 700,000 developers. Given their nearly 3:1 ratio, I have to say that Sun is probably being pretty honest. Also, the figures for Java in the employment marketplace (both from "professional" surveys and ad-hoc queries of Monster and Dice) show a staggering percentage of Java marketshare. If the figures are to be believed, Java has more marketshare than all other languages combined. Quite a good time to be a Java programmer, quite a bad time to be anything else.
Just to interject on a small point. The only thing you mentioned there that is part of the OS is the kernel. This annoys the hell out of me. An operating system is the software system that operates the hardware. An operating system provides the foundation on which you build a system usable by programmers or users, but it is NOT that entire system.
:-))
Depends on who you ask. If you ask Stallman, Linux is "just a kernel" and the GNU userland is the most important part of the OS. Viva la GNU/Linux! (Whatever.
However, the Free software community has developed solutions that are infinately more complex (like the Linux kernel).
The ability of the Free software community to help out is why Sun has Java development open to all developers. They even developed a license that doesn't threaten developer's ability to then work on an OSS version.
Actually even the first release of the kernel written by Linus alone was beyond the complexity of Java (although it hardly had the QA and stability of sun java).
If you're comparing Linux 1.0 to Java 1.0, then I'd say you're correct. But as far as complexity goes, Linux 1.0 was nowhere near as complex as Hotspot, the JVM libraries, and the various other components of the JVM. Trust me, the software running under the hood of Java is very much "next level" stuff. Most of the optimizations for the JVM had to be developed by Sun, because no one had developed an OOP system on this scale before.
You have to load the Java VM and initialize it. That takes a fair bit of time and memory. Then you have to convert the bytecode to native instructions (!!) and execute them.
Of course, all of this happens at startup and is a one time cost. The ongoing savings of a long time program can easily make up for this cost. Java programs tend to compare most favorably with large programs that take several seconds to start up. An equivalent Java program does the same, but provides better performance in the long run. (Server side applications are particularly good at taking advantage of this.)
A virtual machine can be an emulator. A VM is just not strictly an emulator in the modern definition. But it does create a fake environment that the code is "compiled" to. That "compiled" bytecode then has to be converted to native code to execute. You have abstraction between your code and everything else.
You're not saying anything I don't know. I did chose to use the modern distinction between a VM and an emulator, but that's primarily because the two ARE quite different these days.
Way back in the day we had a way of loading code dynamically without shared objects. They were called overlays. You literally loaded them on top of another segment of code. This was done mostly to get around memory limitations.
These two are like the Wright Brothers' first airplane compared to a 747. Java can not only load code dynamically, it can investigate it and tell you all kinds of wonderful things about the code. In JavaBean land, this allows components to be dynamically plugged in, and properties to be made available by reading in their "getXXX()" and "setXXX()" methods. Similarly, JSP pages are possible (and of high performance) because the page can be translated into Java, then loaded dynamically. The exception mechanism combined with the sandbox mechanism ensure that one of those pages can never crash the entire JVM either by accident or by intention. (Of course, in the real world there are some ways of exploiting the underlying OS's limits to crash the JVM, but overall systems are very highly protected against failure.)
Anything you can do in Java, I can do in C/C++. Java is written in C/C++!
Show me a dynamically compiled JSP-like system without resorting to a bytecode design. It's pretty darn hard, isn't it? How about a self-organizing code system that consists of nothing more than a bunch of SPI modules strung together? Not impossible, but quite difficult to do in C/C++.
The argument that C can do anything Java can do is just silly. Of course the same effects can be replicated, because both run on a computer. The features of the Java language, OTOH, make these things *easy* and *low cost*.
Also, don't get your hopes up about those "millions of other professional developers". I doubt there are millions of developers, and most are certainly not Java devs.
Apparently, the surveys say differently. Considering the number of JDK downloads alone suggests that we're well into the millions of developers. Trust me, Java is THE most popular development platform at the moment.
That's not entirely clear. Recall that Sun (along with MS) put a lot of money into SCO: http://news.com.com/2100-1016_3-1024633.html
/ sun.apology.idg/
:-)
This is still a point that is heavily contested. This is hardly "evidence" of a dishonorable act, especially since SCO really did have software that Sun needed for their x86 verison of Solaris. Sun has ALWAYS been very good about keeping their licenses in row.
And their behavior regarding Blackdown was less than honorable: http://archives.cnn.com/1999/TECH/computing/12/10
You'll note that you linked to a public apology. Sun screwed up and then admitted their mistake. It happens. If they *hadn't* admitted their mistake and given Blackdown their proper acknowledgement, then you'd have a case.
s/embeddable JVM alternatives/embeddable database alternatives/g
If you read my original post, you'd find that I have looked at the OOo source code and found no usage of "hidden" APIs. The closest thing that exists is a point where the JVM's AWT package is plugged into OOo. Plugin code exists for Sun and other JVMs. Any open source JVMs (e.g. GCJ) merely need to add their own plugin code. You'll note that JVM providers are just as responsible for web browser plugin code.
I've said it before, and I'll say it again. Sun has removed all of the sun.* references from OpenOffice itself. If RedHat developers are having trouble compiling, it's because they don't understand how to plug their JVM in. I'm sure that this was resolved on the OOo mailing lists within an hour or two.
Sir, you have failed to provide any evidence for your assertions. I have pointed out quite a bit of evidence in the form of JDBC support, embeddable JVM alternatives, and have done the footwork inside the OpenOffice code to verfiy that there are no "hidden" APIs in use. If you want to refute that, then you are welcome to do so, but for now you are just trolling.
Moderators, please mod parent down for trolling.
How is that not true? The new JRL license is still very limiting. In order to distribute and give away what you do, you still need to agree to agree with Sun's commercial agreement:
Don't confuse the issue. You said: "This has serious impacts on the GNU foundation creating an Open JVM, for example, if you use their source to create your own JVM, you can only give out your executable to those who agree to the sun license and other third parties only for the purposes of evaluation."
I pointed out that the JRL fully allows for knowledge gained to be transferred to an independent product. Confusing the ability to reimplement with the ability to redistribute the original code is ANOTHER disingenuous argument. (We've been getting a lot of them lately.)
The trademark issue is a HUGE issue. If a product claims to want Java.
As I said, Sun will give you trademark usage rights if you pass the TCK. If you can't pass the TCK, then you're not Java. If you're not Java, then why should you get to use the trademark?
Does TCK still cost money? It used to and if I remember right, was quite a bit
Sun has extended no-cost access to the TCK to open source projects several times. To date, only derivitives of Sun's source code (e.g. Blackdown and FreeBSD) have taken them up on their offer.
You just missed my entire point. There's a hell of alot more damage one can do by buying Java
No, I'm not missing the point. I'm trying to point out that it's a stupid argument. It's been argued to death 5 billion times, and it's no more reasonable now than it was then. Hell, it's less reasonable considering the number of Java licensees who can distribute JVMs independent of Sun. (e.g. Blackdown, IBM, JRockit)
Personal use. I'd hardly call the GNU foundation creating a Java clone based on the code they get by agreeing to the JRL to be personal use. Most likely, they'd get slapped by sun.
You're misinterpreting an explantion of the license. You need a commercial license if your code derives from Sun's. From TFL:
Sun is licensing the Technology under this Java Research License (the "License") to promote research, education, innovation, and development using the Technology.
[...]
B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights.
[...]
A. License and Copyright Notices. You must include a copy of this Java Research License in a Readme file for any Technology or Modifications you distribute. You must also include the following statement, "Use and distribution of this technology is subject to the Java Research License included herein",
Sounds reasonable enough to me. Especially the part about being able to retain what you remember. No, they don't give explicit access to patents, but that shouldn't stop anyone. If it does, then might I suggest asking nicely? There's no evidence that Sun would say "no", and in fact most evidence suggests they would probably be open to doing so.
I looked at Java several times, each time concluding it was a castrated C++
This may be your opinion, but I think that if you look beyond your prejudices, you'll find that Java is so much more. For example, C/C++ code can't dynamically load individual components (i.e. reflection) without extra metadata (e.g. a shared library).
the only available compiler was for a machine that didn't exist
You're pulling out nonsense now. Javac being a Java program is a GOOD thing because it is portable and available to Java programs. If you don't like it, go use Jikes. (Jikes is open source and runs natively.) Truth be told though, the Java compiler doesn't matter. Due to the bytecode design, there isn't much room at that level for optimization.
because for some daft reason they had decided to write the emulator first instead of the usual process of doing it AFTER the real hardware was no longer available.
Java is not an emulator. It is a virtual machine. The two are very different concepts and have very different performance characteristics. Emulating hardware is usually very slow. VM code, however, gains the advantage of being compiled at runtime thus making it both portable and sometimes FASTER than native code.
If you have a problem with this, I suggest you take it up with the inventors of P-Code
(Lots more whining and insults)
Don't worry, your insults toward myself and millions of other professional developers shall not deter me from getting your Java licensing issues resovled! The next version of White Box Linux shall have Java!
1) To get Sun's source code, I believe you have to agree to the terms of Sun's community license, which has some severe limitations on how it can be used.
Sir, if you had read my post, you would know that this is not true any longer. Bringing up a point that is thoroughly refuted is very aggravating.
The Java Specification is very useful for helping to create a Java-like language. However, the implementation details make creating a full Java clone next to impossible with just the spec.
The spec has 99% of what is needed. It is not impossible to create a clone from it, especially when there is a community available to explain to you where things function incorrectly. Even if this complaint were true, Sun has released the source code of Java under a license where it can be all but outright copied. Please see my original post at the top of this thread.
You can't really use the Java trademark to refer to your own Open JVM.
This shouldn't be an issue for anyone. Even if it is, Sun has granted access to the trademark to Open projects. You only have to pass the TCK compatibilty tests.
Sun is trying to make it seem like they're very open source savvy, but what it boils down to is that they want as much control as Java as they can get. In many ways they are just as insidious as microsoft is. (FYI, I am a java developer and get paid to do Java. I like the language, and use it on it's technical merits, but the licensing sucks)
Pure, unadulterated nonsense. Sun has been trying to open up Java as much as possible without losing their copyrights, patents, and trademarks. There isn't anything in the way of OSS developers other than imaginary demons.
Linux could be forced to be renamed, but realistically, that's not a problem.
Realistically, someone with money can have Java reimplemented in no time. That's not a problem.
Ok, I'm cooled down now.
:-)
It's just not an "AKAImBatman" post without an insult at the end, is it?
Sorry about that, but as you can tell I have a lot of pent up feelings about this issue. From day one all we Java developers have heard from the main OSS community is "Java is not free, Java is slow, Java sucks". This has been very much a last straw for me. I'm so pissed off, that I even took the lead on resolving the supposed "licensing issues" that are preventing Linux distributions from redistributing Java. With any luck, we'll see the one I'm working with including it soon.
The "corporate backers" clause is irrelevant. The FSF (it's not called "The GNU Foundation") is fully capable of managing highly complex projects (which was your original claim).
Fair enough. The FSF has not proven its ability to manage these projects without corporate backing. Right now the FSF's concern is that Sun will disappear or tighten up restrictions. Look at it from the other side, though. Sun has invested a considerable amount in Java and has made it central to their business. Why should they take the risk that other corporate backing will dry up and they will be left to fund BOTH Java and the FSF?
Stallman's position on Java doesn't rely on corporate backers, it depends solely on how Java meets his ideals.
His position may not, but his ability to produce does. If he can't demonstrate that he is secure enough to be a custodian for Java, why should Sun trust him to be one? It's far better for everyone if Sun maintains control, but gives away all the info necessary to replicate their feat. I imagine that they're also getting pretty frustrated at the lack of a compliant GPL JVM. But since such a beast is not required by their business, they're not going to fund it.
GNU is not just "'ls' and 'tar'". It's an *entire OS*, including libraries, a kernel, etc. It's a far *larger* project than Java.
GNU is NOT an entire OS. There is the Linux kernel which is maintained by corporate backing. That is not in the FSF's posession. (At least, the last time I checked.) Then there is the X11 system. Also supported by corporate backing and also not in the FSF's posession. Then there is KDE and GNOME which are not in the FSF's posession. By the time you whittle it down, you find that "GNU" consists of a wide variety of command line tools, most of which are standalone and have nothing to do with each other. The few complex pieces (e.g. GCC) again are supported directly by corporations.
Sir, you have attempted to answer the question without answering it. Here are the points which are unresolved:
1. You need to provide evidence of specific difficulties that RedHat had with OOo. Right now there is no evidence that they have had any difficulties. Suggesting that someone else find the evidence for you (by digging through mailing lists) is silly. If you can't produce any examples of the issues they had, then it is not feasible to claim they had issues.
2. Brushing me off as a "Java Fanboy" does nothing to refute my assertions that no other platform has as complete of a DB support system. You must provide an example of a comparable technology that could have been used.
3. You have not backed up the argument that the FSF is a good custodian for Java. The success of Linux in the marketplace can be traced to heavy support from Oracle, IBM, Sun, and other large companies with deep pockets. Large projects without that backing (e.g. Hurd) show not only a lack of progress, but a lack of GNU employed resources.
4. The success of Microsoft Windows as a server OS has shown quite well that "fanboys" can put significant pressure on companies in large quantities. Windows 95 was in no way ready to replace Unix in many areas of usage, but was pressed into service because that is what customers wanted. The same thing happened with Linux.
The advantages are that:
1. You don't pay for that extra hardware. It's there for you to rent when you need it.
2. Installation of extra components (I believe) is covered by the contract. i.e. You only pay to rent the hardware.
Seriously, talk with a Sun rep and see if it works for your company. It may not, in which case nothing is lost. But if it will work, then you can *save* money.
*Deep breath*
Okay, this is spiraling out of control. Let me restate my position in cool terms, and then I am exiting this conversation before I get really heated up.
1. Stallman doesn't like Java because no GPLed version exists.
2. No GPLed version exists because the OSS community has failed to produce a fully functional version.
3. The GNU Foundation has not been able to show that it can produce a *singular* project of the complexity of Java without the assistance of major corporate backers.
4. GPLed Java versions don't exist for want of corporate backers. i.e. The industry feels no pressure to produce one when Sun is already so open.
5. Major corporate backers are not a bad thing. However, handing over software of Java's complexity to the GNU Foundation is suicide without those backers.
6. The fact that 'ls' and 'tar' exist in the same bundle of software does nothing to show that the GNU Foundation is ready to take on the challenge of maintaining Java. Nor does it equal Java's complexity any more than the combined output of Sourceforge exceeding the complexity of Windows XP.
Now if you'll excuse me, I am done with laying out pearls before those here.