Slashdot Mirror
Beyond An Open Source Java
Karma Sucks writes "LinuxToday is featuring a intriguing article on why Sun should open source Java, as a stronger followup to the recent ESR saga that was reported here. The writer notes: 'Sun needs to do some radical things to improve its chances of survival, and all of them involve Open Source in some form or the other.' One thing the article fails to mention is the threat of Mono, which should be of special interest to Sun, with its vested interest in GNOME."
I still prefer C/C++ though, honestly.
I just like having control of the code and being able to do hardware-level stuff. Also, it's just plain faster.
Java is cool for uber-OO projects, for but most stuff, I'm a strictly C/C++ guy.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
So what exactly is closed-source right now? The language is obviously out in the open. Is that copyrighted? Is it the compiling into binary code itself that is copyrighted?
Incompatibility would run rampant. My java apps barely work for my phone as it is.
Give Away the Recipe, Open a Restaurant
Consensus is good, but informed dictatorship is better
This is not to be a troll, because I hate being cast as one for being negative. But I've never ever liked Java. It never had the performance of native software and there are other ways of getting the code portability of Java. Qt and GTK (via dropline) are examples of this. Mono too has some great promise, but it's still a work in progress. I like the idea of portable code, but the code should still run without an interpreter/virtual machine/emulator. Those are my thoughts.
I guess you could say they're "sunning" (shunning!) Open Source!
It fails to note that these are the *most expensive* full-suites of these products that have lot of non-J2EE frills (you can get into Weblogic's base J2EE support for $10k). Other commercial J2EE application servers are well under the $10k mark (e.g. $1500 for Orion Server)
This article also fails to note that there are more than a couple very robust OpenSource implementations of J2EE application servers, that are of course free.
It's obvious that if they pointed these facts out that their argument would be weaker...
in previous discussion, those opposed OpenSource Java suggested that with MS's domination today, MS can easily 'improvised' OSJava to become a run-on-windows-only-OS-Java (WOOSJAVA).
it doesn't matter if anyone else is going to benefit from/use/modify this WOOSJAVA, most likely it will just be preinstalled in all Windows shipped.
and regardless of what others may like to think, most consumers of MS will think that this WOOSJAVA is now the standard.
so in the end, maybe even Sun needs to write things to accomodate this WOOSJAVA in order to survive, that'll be ironic.
Given the state of Mono, it's not in a position to give anyone pause.
There's no motivation to "Open Source" Java. It's supported on a myriad of platforms and you can even get access to the source if you want to take on the implementation on a new platform.
Are we supposed to be suprised that a bunch
of GPL zealots are claimoring for a private
company to relinquish ownership rights to a
piece of software? I doubt there is any "owned"
software that they don't wan't to demand they
be allowed to control. As long as their is a
standards process, preferably ANSI, ISO, etc.
I don't care if Sun retains ownership.
I think open sourcing it is ok, but they should do all the work on it internally and not let any 3rd party distribute their own Java.
When you have a cross platform interpreter, you need to make sure there is consistency. For example, Microsoft JVM ruined it for alot of people since developers will forget to debug it on Suns JVM, causing huge incompatibility issues that they blamed on Sun.
there's nothing vested about Sun's interest in GNOME. It's just an interest.
I'm not certain this is a move that should be made. All we need are 18 different 'forks' in the java tree like certain other open source projects. I can just see it now "No no, you need BobJavaVM-1.43.2.43 - it won't run with FastJava V 2"
...is that Sun allows Java to wallow in limbo until its development becomes unsustainable and people start using other languages and development environments like .NET, and then make it open source because it became a black hole for them.
.NET as a universal development language. You can bet diamonds to dollars that Microsoft will never open source their version though.
I mean, Sun could still have a vested interest in an open source Java and still derive revenue from custom design services and support while displacing the Beast. It isn't even like the implementation is a trade secret. Heck, the Beast has developed Java bytecode interpreters in the past. But the Beast would love to displace Java with
Hence, Sun has a great opportunity here. Will they see it?
It's good info.
That'll attract the mod points! Note to mods: Amsterdam Vallon = Blatent Karmawhore.
Sun has enough fingers in enough pies that will keep it going strong regardless of where it's open source strategy goes. The recent deal with the Chinese standard software company shows that it can leverage open source products without having to open source anything so big as Java to establish their commitment.
There are some interesting points, but others are nonsense. "needs to position its own (Open Source) NetBeans and rival IBM's Eclipse as mere IDEs that support the Ant way of building applications.". Is publicy know by anyone interested that almost every major IDE supports Ant.
" Sun can lend credibility to Mozilla and XUL.". As much as I like Mozilla (I'm using it right now) I don't know if anyone could do that.
This is just an order of magnitud above ESR lowly comment but it still missing the target.
"I think this line is mostly filler"
Microsoft effectively broke Java by extending it to allow the implimention of native windows widgets that wouldn't run cross platform and since Sun owns Java they were able to sue, and win. I think if Java were open source MS would be free to break it again. It's an old argument and one that we have heard over and over again but it has staying power, I believe, because it is true.
It's ludicrous to think that opensource in _any_ form will save _any_ company. No one has built a successful business model around opensource and Sun isn't going to do it either.
To borrow a phrase from John Stossel: Give me a break!
.Net for that matter. It's a simple matter of resources.
While Mono is cool project and, like many developers, one I've been following since it's inception, I don't see it ever overtaking Java, or
Though open sourcing Java may be beneficial, Java is doing just fine without it, just look at the Classified section ... most job openings are in Java.
That's because Mono is not a threat. Never has been, never will be.
"Perl and Python are hardly competitors to Java, so warning Sun about Java's impending loss of market share to these two scripting languages is laughable."
How so?
The term "scripting language" doesn't have the name meaning it used to; especially where Perl and Python are concerned. They both get compiled to an intermediate form and executed...just like Java. The only difference (other than the internals of the runtime) is that the Java's development "model" is closely related to it's static typing; i.e., you manually compile your code into a binary before executing. Trying to discount Perl and Python by calling them scripting languages is silly. The real issue is what works as an enterprise development platform, not the "taxonomy" of the language. As far as platforms go, Python has got a pretty good thing in Zope/Plone etc. And both Perl and Python have libraries for damn near everything you'd want to do. J2EE may be more prevalent at the moment, but in terms of bang for buck Python and Perl present some interesting alternatives in the long term.
It never had the performance of native software
Back when everyone was writing assembly the first C compilers came along and everyone said "it's too slow!". And they were right. But, the compilers improved over time and now no one complains that native code written in C is too slow.
The same thing is happening with the JVMs. At first, they were dreadfully slow, but they have improved, and will continue to.
I fail to see a decent reason that Sun should do it. Lower the cost of J2EE, sure, but give it away? Is Sun were nothing buy a service businesss I could possinbly agree. Buy Sun wants to sell Java app servers on Sun hardware. Or at least so they get a cut of the package sale.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
As soon as Sun GPL'd Java, it would start to diverge from Sun's commercial Java. Sun would not be able to incorporate changes made under the GPL into their corporate version. Sure, they could maintain their own "official" GPL version, but the dual license argument is complete rubbish. Java wouldn't die, but Sun would lose most or all control over it.
[J2EE] has replaced CORBA as the way to go for
.NET is satisfactory in this environment.
large, distributed enterprise apps
Has J2EE replaced CORBA in those scenarios where either the client or server is NOT written in Java?
One of the facts of life in the enterprise is that it is heterogeneous in terms of platforms, operating systems and (maybe) network technologies. Neither J2EE nor
Vested does not mean hidden in any sense. Often it means clothed, but in the context of the referenced post it means "Not in a state of contingency or suspension; fixed." Or at least that's what the dictionary says...
-Jem
That's pretty much what happened to Netscape.. They decided to open source it as a last ditch effort.
Can I get a bonus point for bringing up CLOS?
KFG
The article does mention that the only visible part of the J2EE iceberg (visible to the decision-makers, not the geeks) is webservers such as Websphere and Weblogic. It doesn't say anything else. It does mention open-source implementations.
What the author is talking about is a lack of the right communication from Sun on this matter. If Sun continue to advertise only WebSphere and WebLogic, they set the visible price very high.
Write boring code, not shiny code!
The author is not saying that sun shouldn't close the source but that if they do keep it open, it won't hurt the closed nature of the project and may not in fact not even have any affect on their desire to not close it.
Sun and Open source Java are a lot like communism. They're a nice idea in principle but just don't / wont work. I don't think Sun is in the business of giving away it's biggest assets now matter how good this would be for everyone else.
Lots of server side programs become bottlenecks. Clients is where the _free_ mips are. Server mips are _expensive_. The Hotspot compile is cool-but it isn't a solution to a bad architecture. Peer to peer take more work-but it will generate a faster overall solution when properly implemented.
The most compelling argument he makes is the complaint about the complexity EJBs:
An Enterprise JavaBean (EJB), which is a component containing business logic, typically requires 5 to 7 supporting files to deploy.
This is the real issue that Sun needs to address. Java is widely used in enterprise apps because it is easier and faster (therefore cheaper) to develop apps. However, EJBs have some fundamental flaws that add unnecessary complexity and network overhead. I have developed apps for some of the busiest sites in the world and the requirements to strip the code down to the essentials are not compatible with EJBs. More times than not, EJBs are ditched in favor of a servlet-based front-end and a proprietary persistence solution.
It's simple: I demand prosecution for torture.
I fail to see how many of the article's points relate to Java being open source or not. While we could agree that Sun hasn't been marketing Java the best it could, what's wrong with Ant/XDoclet/JUnit not being developed/sponsored by Sun? Do we really want a single provider like we have with MS? Do we need opensourcing Java if we get many of the benefits as it is, and no bickering/forks/whatnot?
As for Mono... I will not state my opinion about Mono per se, it's not the point, but let me just say that Mono is trying to catch up on a Microsoft implementation. I fail to see how that compares with opensourcing Java, or even how it is a threat.
Just my two cents...
The revolution will not be televised.
Hmmm - didn't ESR inspire Netscape to following a similar path to "salvation" back in '98? (Netscape)
Hopefully (for Sun!) history won't fall into its old habit of repeating itself.
Maybe it's because Python breaks compatibility at every major release, is freakishly huge with more add-ons than Mr. Potato Head, has syntax that would drive Intercal users insane, and has documentation that's harder to find than Waldo?
As for PERL, it's got more dollar signs, at signs, and hashes than TV-edited captions on Scarface and it's so cryptic that several small governments have considered "encrypting" messages into obfuscated PERL for protection. Besides, even the PERL authors admit that other tools are often needed when creating applications, that's why "there's more than one way to do it."
IBM is the first example that comes to mind of a company that successfully built a business model around opensource. I'm specifically referring to hardware and how IBM freely licensed the IBM architecture so that any company could manufacture and sell their own, competing, IBM Clone PCs. Perhaps you will remember the early '80's when Apple had all the market share, followed closely by Commodore and the IBM PC was a fledgling no company was worried about. What happened? They 'opensourced' their hardware architecture which Apple and Commodore refused to do. Within a matter of years Apple and Commodore were suddenly competing not just against IBM, but against scores of rival computer manufacturers. What was the end result? IBM-compatible PCs (clones) were far less expensive, parts were plentiful and easy to find, and all the software developers migrated towards DOS because that's where the market was... once that happened, most of the available software was also IBM PC-compatible which just further encouraged people to buy IBM Clones. Had Apple and Commodore been less stingy with their proprietary hardware technology, things could have played out very differently and today everyone might have an Apple and Microsoft might not even be around. But you might ask, "how is the free licensing that IBM implemented, open source?" It was open source because manufacturers were and still are free to propose and develop hardware standards designed to further improve the IBM Clone architecture and they don't need IBM's permission to do it, they need only to get approval from the various standards bodies. If this is not a clear example of how open-source has worked as a successful business model, then I don't know what is. Rather than fight over the market-share that Apple and Commodore owned, IBM just created an entirely new market -- far larger than the one it replaced. So what if IBM had to compete against their own technology they gave away to other Clone manufacturers? Which would you prefer: 10% of 50 million units, or 100% of 1 million units?
-- I'd give my right arm to be ambidextrous
They shouldn't use the GPL, they should use a new license which says its basically open source, so as long as you follow the standards for it set out by them. We don't want variants not fully functional and implementing things in different ways, so I need to have 15 Java VMs on my machine, and we don't want it to turn out like browsers where half of them don't support most of the standards making design a PIA.
Can someone please give me a refresher in how dual-licensing with the GPL works?
I know that MySQL charges only when the user redistributes its code for a profit, while internal use is free.
But the MySQL code is still under GPL, right? Doesn't the GPL require that the code be redistributed for free?
This guy must be a MS partner.........Most of the .NET development is taking place primarilly in Windows only shops. Also the great majority of .NET development is VB .NET.
After seeing how Microsft corrupted the JVM and developed J++ it's hard to see how moving Java to pure open source will help.
As for the desktop .NET is only strong because because it has the propietary features to lock people in.
Really need that right about now...
While Java stays Sun's closed-source product, Sun retains control over it. Releasing it open-source would mean relinquishing that control forever. Imagine, if you will, the overthrow of an essentially benevolent dictator followed by a less desirable character seizing power.
The questions Sun needs to ask itself are (1) whether or not Java is ready for that -- or is it more likely that differing implementations would lead to fragmentation, and thus nullify the whole point of Java?; and (2) if Java is ready to go open-source {and I personally believe it is}, what would be the best licence to ensure against fragmentation whilst not putting off purists?
All these things being said, Java is only a programming language -- a means to an end. Programming languages come and go. There is no reason why another contender should not arise to solve the same problems for which Java was invented, and eventually displace Java. Mono may be that, of course. It is just as likely that something totally new could arrive on the scene and change the whole picture.
Je fume. Tu fumes. Nous fûmes!
Until a couple of years ago, it mattered to me that Java was closed source and that the Java specification itself was closed. (Yes, the Java specification is not open--you can't just implement it without violating Sun's intellectual property.)
Now, I just don't care anymore. Java has fulfilled its function: it has made garbage collection and runtime safety acceptable among commercial programmers. The Java language and libraries themselves are nothing to write home about and never were. Java could have become a good, general-purpose language and a good, general-purpose platform, but it never really fulfilled its promise. It's become a mediocre specialty language mostly for some kinds of server-side hacking. Open sourcing it or opening the spec would only prolong the agony.
People should move forward and widen their intellectual horizons again. Look at languages other than Java and get over this illusion that we will ever have a single language in which everything will be done on every platform.
My roommate just got mono and trust me, you want to avoid it at all costs. You're sick and tired and it lasts for weeks.
...you sprinkle it on failing companies, and they spring back to life.
Yeah, but I find I can't get shit to run no matter how it's compiled.
What were they thinking implementing SWT in Carbon. Even that is not an excuse for the slowness though. About the only full blown java IDE that is slower than Eclipse on OSX is Netbeans :(
seSales, Point of Sale software for OS X.
The Gtk implementation of SWT is slower than Swing also.
Actually the only implementation of SWT I've seen which isn't slow is the Windows implementation, and until you hack your Java installation it doesn't look anything like Windows.
Karma: It's all a bunch of tree-huggin' hippy crap!
I don't understand why Sun is, on the one hand, so active in and dedicated to the GNOME desktop, whereas on the other hand, they're not doing a single thing about Mono becoming an important part of the desktop, pushing Java back even further.
Face it: Sun, one of the head developers of GNOME, is losing the fight of Java versus C#, which is the official language from GNOME (Linux)'s biggest enemy Microsoft. Where's the logic? I mean, if Java loses even *this* battle, then how are they ever going to keep any significant marketshare?
So yes, Sun should do something.
This Dutch company produces some interesting stats for those interested in the popularity trends of languages TIOBE Programming Community Index February 2004
Sun needs to do some radical things to improve its chances of survival, and all of them involve Open Source in some form or the other.
I hope they do this so they can end up just like another famous company who did the same thing: Netscape. OSSing your company's products is a winning recipe, so we've seen.
PS: Last quarter was Sun's best in 3 years. They're just waking up.
However, if you put your ear to the ground, you will discover that Microsoft's .NET framework is finding its way even into such organisations as a "tactical solution" for smaller, departmental level projects. It is dangerous for Sun to ignore this trend. In the early nineties, Sun's workstations were far more capable (and far pricier) than the humble PC powered by a lowly Microsoft OS called DOS. Today, Sun has lost the workstation market to an evolved PC, running an evolved Microsoft OS, in spite of its initial advantages in power and openness.
Java never had a strong presence on the client side. I know of several financial software companies that are going with a java middle/backend and .NET front end. There are several reasons for this: the first one is webservices and the second is proven scalability of java application servers. I won't name the companies, but those in the OMS (Order Management Systems) industry will know this is one trend. Just google for it and you'll see several of the top companies are moving towards J2EE for the serverside. In fact the companies winning in the financial software world is changing as a result of OpenSource software and J2EE.
Rather than see Sun simply OpenSource Java, I would rather Sun do two things. the first is make it a real standard and resubmit it to a standard body. the second is provide a BSD style license of Java. When I say Java, I mean just the JVM/JRE. I work with .NET on my day job. MS has made great strides with .NET, but scalability for large systems still sucks big time. Websites that used to use ASP + MTS will see great improvements in reliability and performance. What they won't see is a great improvement in scalability. That basically means transactional systems that were hard to maintain and difficult to develop previously on windows will be easier to build and maintain.
A professional developer, who is open minded will already know this. The real problem with using .NET is if your business needs to grow to support large scale deployments, it's a dead end. Eventually, the system will have to be replaced with a proven J2EE solution. what do I mean by large? Large might be a transactional system that is message oriented and needs to handle 300-500 transactional messages a second, or requires distributed transactions. Doing these things in .NET still very difficult, but like these types of applications were ever easy. The fact is, .NET makes easy stuff easier to build, but for hard stuff, it basically can't do it well. That's where java shines. Java is harder to learn for simple stuff, but ultimately allows you to scale to massive levels, like handling 2K transactional messages a second.
Most companies don't need that kind of power and probably never will. Microsoft is strongest in small and medium/small firms. Ignoring all the PR BS, that world has remained basically the same.
Mono (and .NET by extention will never amount to much in the .NET. There isn't
Linux/BSD/Open Source/Free Software space. Why you ask? Because
outside of the wannabe Windows developers nobody in the Open Source
world really gives a damn about either Mono or
really a whole lot of interest in Java for that matter either.
Don't just swallow all the hype. Think twice before bying in to child of marketing that is Java.
Java: Language of Tommorow
Java: Failure or Crime
many anti-Java rants on The Bile Blog
Sun itself won't use Java internally
Why is Mono a "threat"? Is it not possible for both to exist? Perl and bsh both exist on my machine and it doesn't explode even though they overlap in functionality.
According to popular legend, once all of Issaquah high school came down with mono.
I've never had mono, but it sounds like a shitty way to spend a month.
For some good information about why this is the case, I strongly suggest checking out the informative whitepaper [msdn] Microsoft (yeah, I know) has on the CLR. It's a good explanation of some pretty high-level stuff, without the usual MS-ass-kissing you find on MSDN.
This is the real issue that Sun needs to address. Java is widely used in enterprise apps because it is easier and faster (therefore cheaper) to develop apps. However, EJBs have some fundamental flaws that add unnecessary complexity and network overhead. I have developed apps for some of the busiest sites in the world and the requirements to strip the code down to the essentials are not compatible with EJBs. More times than not, EJBs are ditched in favor of a servlet-based front-end and a proprietary persistence solution.
I don't mean this negatively, but if your problem is simple enough to solve with servlets then use servlets by all means. And yes, Entity Beans suck and should be avoided at all costs. And much of the time EJBs are overkill.
But if you need clusterable objects with failover and seemless transaction support nothing is easier than EJBs. Go try and do some CORBA or DCOM programming and see how complicated is can get. More power=more complexity.
Brian Ellenberger
If you want to read quite a bit of diffrent views on the subject there are several threads on http://www.javalobby.org I think they cover this topic in painful detail. My favorite quote is by Guillaume http://www.javalobby.org/thread.jspa?messageID=917 90106&threadID=11559&forumID=61
One interesting thing the article brings up is XUL. Since it seems to do so well provided a pretty platform is written to run it, maybe it would be a good idea to, as they suggest, get it standardised at the W3C.
Actually in general, I feel it would be a good idea for Sun to start pushing towards an architecture which allows for server-side (in the X sense, where the server is the terminal) widgets, whether they use something like SWT (which will never happen due to wars with IBM) or even an improved AWT.
Server-side widgets would make the client even thinner, and if it were all in script you could just use the same code on all platforms and the rendering mechanism would determine how it looks. Maybe if Y-Windows ever takes off you could even have an implementation for that, and things would be lightning fast. :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
Well, you're right, but there tools that do profiling for C/C++. This thread should rather be named "(JIT) Bytecode vs native code"
.NET, but from what I heard, multiple frontends for arbitrary languages are possible.
Java".
The front-end languages C++ or java don't really do much about the perfomance (except that you can manually optimize things you can't do in java because of missing pointers etc.) (*)
IMHO, java bytecode suffers from the following things (and so do the users of java programs) - [they are the reasons,I think, why all java programs I've seen so far (and all the not-for-java-crafted benchmarks) are running considerably slower than C/C++]:
Technical:
- Java bytecode is low level enough to lose certain optimizations (JITs have to apply decompilation techniques) which you can do in C/C++. You can of course compile Java natively (e.g. with gcj), yes. But then, you lose portability.
- Java bytecode is not low-level enough that you can take advantage of the features of the particular hardware. Java's ints are 32 bit. What if you run your numerical java code on 64 bit machines?
Political:
- The java bytecode format is so specific that it is impossible or rather hard (there was once a java backend for egcs, admitted) to get other languages like C/C++ to run on it. Why does one have to chose the platform java with the language java? I don't know
I'd like to have a VM for C++ *and* Java. That would surely rock and end some of the flamewars.
(*)- The often stated security argument (java has no pointers and is therefore inherently more secure than C++) would fall with C++ on a VM.
I read the f***ing article.
.... probably the article has some insights but the start is way off.
... 3? Probably 3. Not sure.
... 10? 15?
... why should SUN "Open Source Java"? What bullshit idea. Probably there are indeed reasons to do so. However, the article completely fails to show them. Heck! Why should Mono be a competition to Java? Why should Mono, Open Source, cool ... Microsoft .Net, not Open Source ... cool either, why should that be a reason to Open Source Java?
... Closed Source, commercial ... discussion just sucks. Mono or .Net are no competition to SUN/Java.
.NET is a platform also, Java is a platform as well, also. But, the heck, where is the relation to Open Source in that regard?
... as Deutsche Bank buys not JAVA, they buy consulting.
After the 5th paragraph I stopped reading. After the 5th paragraph the new headline "Rephrasing Eric Raymond" I stopped reading.
Sorry folks
If I count commercial, non open source, Java implementations I count
If I count open source java implementatinos I count
Why
Man, this Open Source
Why should PERL be a competition to C++? This "are programming languages"!!!!! Sure,
Do you think any german customer, using Java takes a shit if it is Open Source? I would bet that 90% of the german projects done in Java, just download the JDK and code it, and thats it. No SUN, no IBM, no Open Source, no idiology involved.
Why the heck should anyone care if it is Open Source or closed? Especially if tehre are 5 times the Open Source implementations existing than closed ones? Especialy if none of the open ones are used in commercial projects?
Do you really think "Deutsche Bank" would "take" an Open Source java implementation for their next Enterprise Portal?
No, they take the CPL SUN implementation, or the semi open AIBM implementation, or the Apple colsed source implementation or the HP closed source implementation or the BEA JRocket, closed source JVM or any other closed source JVM.
SUN has absolutely no benfit in a contract with Deutsche Bank about a offering an Open Source Java
Using any JDK and Deploying any JDK based application is FREE as in BEER regadless which JDK you use, SUNs, IBMs, HPs, Apples.
The real world does not care if it is free as in SPEECH as long as they dont have to PAY FOR IT.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Open Source Java,
Use Linux instead of Solaris,
Move from UltraSparc to AMD64...
Hmmm, seems like a great business plan.
Its full of contradictions and silly mistakes.
.Net be a threat when Microsoft is struggling (making a loss!) on the server side? Unless the Mono folks unwisely give Microsoft an escape route, the eventual rise of Linux on the desktop will squash .Net flat. This rise is starting: I develop websites for international use. If I deploy anything that requires Microsoft on the client (as do .Net apps), I soon get enough complaints to convince me otherwise!
J2EE is small and easy, not large and expensive. Anyone can build JSP pages or use Servlets on a free but high-quality App server like Tomcat - this may not involve Enterprise Java Beans (the least used aspect of J2EE), but its still J2EE and it costs nothing.
How can
Why does Java need to be Open Source to ride the Linux revolution? High-quality Java VMs are ready for Linux.
Java is the most widely requested language for development, and its use is still rapidly expanding. Sun has nothing to fear.
It's more important to get binary packages qualified (FreeBSD...). But other than that, come on, Java can be used pretty much unencumbered. What's the problem for end user apps?
Heck look at the wave of new cellphones, they all have Java and Real as far as I'm aware. This is also where the DRM fight is going to be, not on your PC (otherwise I don't use the little plastic critters at all -- don't ask me).
And preferably mod the grandparent down.
That was all
"The GPL is also the only Open Source license that can keep Microsoft from "polluting" Java."
If Java is Open Source. MS can change it all they want from the Sun standard. The only stipulation is that they then must release their source code. MS would love this as it puts them in a far better position than they're in now, where they're not allowed to ship non-compliant versions of Java as ordered by the courts.
Vote for Pedro
"Java will not really take off"??
Seems to be some kind of reality blockage somewhere. I look forward to future comments such as:
"Linux will not really become widespread until..."
"Windows will not dominate the desktop unless..."
Hint: Scan the job ads. Java has taken off.
"Knows stuff"
Don't believe me? Don't take my word for it.
(EJBs)...typically requires 5 to 7 supporting files to deploy. Most development tools (IDEs) generate these automatically, but each in its own proprietary way.
By open sourcing this, it will make it worse. The EJB spec states bare minimum. It's up the the vendors on how to implement most of it. This it not an issue OSing Java will fix.
I dunno, there are a lot of reasons why I don't think making Java any more open, read: diluted, will help. But it's getting late, so...
Cygnus built their business around open source. Their main product was offering support for the Gnu Compiler Collection.
An optimizing JVM will often have to insert guards in order to guarantee the correctness of specialized code. Thus it not only should not, but for the sake of correctness CAN NOt "just get out of the way of the program and just let it run." Further, program behavior can change, and so a different version my become more appropriate as the program continues to run.
As for performance of Java on IA64, current benchmarks show very good performance. Future potential is even better, because there is a lot more scope for adjusting code based on observed behavior than there is in most architectures.
If you download the SDK, you've got the source. It's usually in src.zip.
You can change it. You can give your new stuff to whoever.
You just can't call it "java", you'll need to think of a new name,
like "java++".
If you want to make changes and call it java, don't be an ESR and whine, just joint the JCP. Java is "community guided" open source. It's a new concept I guess, but new concepts do come up sometimes.
If you reject any new variants of "open source" you still have plenty of options - there are many existing open source java implementations.
By ignoring all these facts, the article is effectively saying
something quite different than what the title indicates. An open source java is not what is wanted -- that already exists in many forms. What's the problem then?
I can only explain by analogy-
let's pick Gimp. It's open source. Photoshop isn't. Now, I write
a paint program called BozoPaint, give away the source, but
say that, to keep some level of compatibility, changes to
the BozoPaint file format have to be proposed and voted
on by the BozoPaint steering group, which anyone can join.
Completely reasonable...
The author of this article evidently cannot tolerate an article
in which BozoPaint (and Photoshop) exists.
This is the thing that really bugs me about the Linux community.
Linux is great, but so many of the people who speak up about
it are wacos.
Kind of like how Linus Torvalds completely lost control of Linux? </sarcasm>
Sun would retain copyright and the right to relicense or dual-license. The scenario could be parallel to Mozilla or Qt, but with Sun Java's existing huge userbase.
If the JVM (at least) was Qt style relicensed GPL, we might perhaps see some performance enhancements on Linux, as well as integration of Sun's JVM into GNU/Linux distros like Debian and Fedora Core. Sun would surely like that.
This makes a lot more sense than relicensing under BSD, as that would enable MS (say) to quickly release broken/incompatible JVMs in their future OSs without breaching their legal obligations and without giving the source away.
To sum up, My answer to your query (2) is 'GPL'.
It seems Sun needs to make Java to be open, not closed source if they want Java to be more popular.
A long time ago there was the MS Java JIT. It loaded up and ran Java applets and played nicely with others. The web was browseable and never caused the evil BSOD to appear. However, the father who never liked this child wanted to push their own JIT upon the people. It was known as the Sun JRE. It didn't like Windows, and often crashed it out of hatred. A great many web pages were blockaded by the JRE. It brought the terrible BSOD any time it could.
To be continued....
-]Phreak Out[-
(http://news.com.com/2100-1007_3-5165427.html?tag= st_lh)
"IBM on Wednesday sent an open letter to Sun Microsystems urging Sun to make Java technology open source, CNET News.com has learned.
In a letter sent by Rod Smith, IBM's vice president of emerging technology, IBM offered to work with Sun to create a project that would shepherd development of Java through an open-source development model. If implemented, portions of Sun's most valuable software asset--Java--would be freely available, and contributors ranging from volunteer programmers to large corporations would submit changes to the Java software."
We just scaled a single server asp.net solution to a 5 server farm without a single code change or recompile.
:p
I did have to change one line in the web.config file though. I guess that 10 minutes of my time isn't a great improvement in scalability?
Can you make it a double homicide and go kill Michael Simms now. Do it for the children man.
like we need a bad rash.
Now everyone sing:
Yeah for Java! Yah!
This was just published an hour ago:
IBM on Wednesday sent an open letter to Sun Microsystems urging Sun to make Java technology open source, CNET News.com has learned.
In a letter sent by Rod Smith, IBM's vice president of emerging technology, IBM offered to work with Sun to create a project that would shepherd development of Java through an open-source development model. If implemented, portions of Sun's most valuable software asset--Java--would be freely available, and contributors ranging from volunteer programmers to large corporations would submit changes to the Java software.
http://news.com.com/2100-1007_3-5165427.html
I call bullshit on this. If Sun released a GPL'ed version of Java, as they own the copyright to it, they can include whatever changes they made in their GPL'ed version into their own commercial version. On top of that, as they own the copyright to the name "Java", they could set the standards (as they already do) where if implementations did not conform to their standard, then the implementations could not be called "Java".
The real danger, which until now fortunately has been avoided, is when developers are presented with the choice of either having to open their source code when using the GPL Java, or paying Sun a fee for using the commercial Java. How can this be considered more "free" than the current situation where you can do what you please with your own software? If you want to GPL your software, go ahead. If you want to keep it closed, you are free to do so.
Currently as far as I understand you can implement Java any way you wish, as long as it conforms to Sun's standards. Isnt this what the OSS community has been calling for? Open standards? This appears to present us with both the advantages of OSS and commercial software. A central controlling body for the standard, with the openness to implement how anyone sees fit.
I am Monkey, the Great Sage, equal of heaven!
Take a look at .NET
.NET with all it's propietary extensions to the standard. The standard itself is gonne mean nothing.
IT has open ECMA specification - and Microsoft made a great P on that.
But the real programs will be made upon MS
Projects like www.DotGNU.org understands it well, so they are running behind (and trying to chase) the very MS libraries, not only the standards.
And Microsoft said that it is their strategy - add new technologies so fast, that competitors have no time to invent their own one.
Why? Well remember JVM and how Microsoft corrupted the compatiablity? Java's goal is to be cross platform and to do so means there needs to be a centralized development effort. If suddenly there are 50 versions of J2EE on the market, each with its unquie traits, which do I run? How do I know that the app I program will work on the others? If it doesn't run on everything, hasn't the point of Java been defeated?
I once worked for a company that was looking to port some of its Solaris & AIX Applications to Linux, but 3 months into the project, the question became what distros to support. They tried porting their application with some modifications. Got it to run fine on RedHat 5.x (it was a while ago), but then it took some playing around to work with SuSE and we never did get it to compile on Slackware. When they said they planned to support RedHat default only, meaning if system admins were using a tweaked box or kernal, we would not offer support. Needless to say, potential clients scoffed at the idea and after 6 months they decided that the Linux Market wasn't worth the hassle until some standards had emerged. This is why a lot of developers won't port to linux, especially desktop applications: too many variations.
I see the same potential of Java, to become slpit into so many forks, that it defeats the purpose in the first place.
I like opensource applications, but I don't think that Opensource is always the answer. Another good example is a good friend that is developing a support ticket application for the company he works for. I asked him, "Isn't there several GPL'd apps outhere that could installed within a couple hours?" He responded of course, but he put it this way: "I like to use my own code and not other peoples. Its a lot less messy that way." and I see his point.
IF it wasn't for opensource, I would have never learned how to program in PHP, PERL, and various SQL databases, it was a great learning tool, but like every tool, there is the correct tool for the job. I say this as I switched from Linux to Macintosh almost two years ago now and I am willing to pay for the luxury of having everything work. Just like we now pay for managed instead of self-managed servers for our business. There is only 3 of us and we now have enough business that its costing us more to run our own servers than to pay a little extra for managed services where the keep up with the updates and such.
All I am saying is that projects have goals. Sometimes Opensource meets those goals, but its not a cure all. The beauty is that we have the choice of using Opensource or to use a propritary solution.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
While Java stays Sun's closed-source product, Sun retains control over it. Releasing it open-source would mean relinquishing that control forever. Imagine, if you will, the overthrow of an essentially benevolent dictator followed by a less desirable character seizing power. I'm getting sick of everyone saying this - Sun has actually given up a lot of their control with the introduction of the Java Community Process. Please research you facts! Will.
...debug everywhere
The author of the LinuxToday article obviously can't read a financial statement very well. The reconciling amounts he goes on at length about are mostly corporate-wide expenses which can't be allocated easily by company segment. The biggest piece of them is stock compensation expenses which are not really expenses at all, but accounting fictions based on the imputed value of options granted and exercised.
I seem to have missed the facts part... too.
.NET system that is getting scaled right NOW to zillions (approx.) of users.
Orkut is another example of a
Granted they are hitting some bumps, but I've seen java based shopping sites with bigger problems and fewer active users. They ended up taking the site down for weeks. Not to mention the site was unusable while up.
Just goes to show that it's not the language... it's how you use it.
Interactive Visual Medical Dictionary
the GNU Compiler for Java (GCJ) posted a very nice and
much more pragmatic request to Sun. Reproduced below:
rmathew.com
Everything the article mentions about J2ee VS .NET and why .NET is advancing quickly is so true.
IDE, UI, productivity, these are things MS has been working hard at for years even as big iron has been chuckling at the concepts for years.
Now all that ignorant laughter is beginning to pay off for MS. These are things the java community, Unix, Linux can not ignore.
There is something to be said for a good productive development IDE that works on top of a powerful development platform. and no Mr legacy, a good GUI IDE does not mean a color coded text editor, and some pretty graphics.
What does people here use to develop java on OS X? I've tried Eclipse, wich is fast, but lacks of GUI editor. Netbeans would be great, if it wasn't that it is horribly slow and bind CTRL-C and CTRL-V for copy and paste operations (We apple folks uses APPLE key+C/V for that stuff).
... wich seems the best option so far..
I'm considering JBuilder X
Do any of you know the real issues:
.NET at the moment if you read up on the issues at all. It's domain more an enterprise framework now - not just a program language, so you should really all have been moderated as offtopic.
.NET. So you'll all end up giving more cash to MS because of the stupid java vs. c++ fantasy. .NET - thats where the cash is.
.NET - they cannot compete with free software that is fully controlable - open source, and a lower over all total cost of ownership. Essentially, we could see a new dominant force in the web domain - Linux and J2EE dominating over M$ and .NET
The survival of Java is important not because it's an alternative to C++. You could not compare them in the beginning and this is even more so now.
Java is best compared with M$
Why open source it?
Because, inevitably (almost certainly) if Sun don't do this M$ will coax every enterprise and small business into using
No, this is much more about J2EE vs.
So, if Sun makes Java open source this trend can be bucked because no matter ho cheap M$ go with
And also, I'm tired of hearing that you think Java is inefficent. Java uses far more native code nowadays, so actually when it comes down to it, thats c code being executed in the end when your app runs. It's very good c code too. For example, the the CDC (Connected Device Config) used in mobile devices uses the CVM I believe, a very fast and efficient VM programmed in C.
In summary, you should read the article..
I think it basically comes down to design intentions. The Oak project was intended to provide WORA with a sandbox model to reassure people that it was safe to run applets. The CLR, OTOH, was designed to allow people who already knew any VS language to write for .NET. I don't know quite what that means in terms of sandboxing, but I haven't noticed MS release an applet-style plugin.
As far as getting C/C++ to run on a JVM is concerned, I think someone with enough dedication and compiler skills could probably write a compiler which got most of it to run. Most pointer idioms can be rewritten, autogenerated mixins can simulate MI. Variant fields in structs could be tricky, although I think they could be hacked up. The question, though, is why people would want to run C++ on a JVM. Surely the reason for using C++ is obsession with speed or a desire to do really low-level stuff? If you're obsessed with speed, you should take to heart the mantra "Don't optimise. (For experts) Don't optimise yet", and if you want low-level stuff then you don't want a VM in your way.
As a .NET developer I'll be up front and say over the long haul I sincerely hope that Sun don't Open Source Java. More specificallymy hope is that Sun keeps Java closed for at least another 3 years.... I fugure it's going to take another 3 years for .NET to mature as a cross-platform prospect.
.NET developer you can't begin to imagine the childish glee I get from saying to Java developers... "my platform's more open than yours."... to which I'm quickly told "but there's 5 Java jobs for every .NET one", and I have to shut up.
.NET... I can't believe the OS community will stand and defend Sun when it's setting them up for such humiliation.
.NET is more open than Java.... the Mono CLR on Linux is more open than the Sun JVM on Linux. You can't dodge that.
IF... and it's an if, it might never happen... Mono matures over the next 3 years it is going to be absolutely excrutiating for the Open Source community to justify a closed Java.
As a MS
And yes it's incredibly childish, but at least half the motivation behind any platform comparison is childish spite that exposes the facet of a developer that has more in common with a cheer-leader than anything else.
More seriosuly Java has 3 years to go open or the Open Source and Free Software community will have it's nose rubbed in
We could argue the detail, we could justify, but
What the Open Software community should be doing is screaming blue murder at Sun, not sticking their fingers in their ears and saying "nah nah nah nah, it's not happening, it's not happening".
There are several languages with which you can write Java bytecode programs, like Jython
See here, so it is possible with Java bytecode as well.
Aside from the annual subscription rate for the software, they also stand to make money on selling hardware and services for infrastructure from these deals. Even if the actual office suite is be a loss leader (which I do not believe to be the case, but I could be wrong), it still brings in a tremendous amount of income on other fronts which would make it analagous to Microsoft and Internet Explorer.
Had Apple and Commodore been less stingy with their proprietary hardware technology, things could have played out very differently
This more or less BS. Back then you either got the whole completely detailed hardware documentation with the system on purchase (Apple II) or you could buy it cheaply afterwards (C-64). Both platforms were excellently documented and there were numerous Apple-II clones around. IBM PC did not win because they were "Open Source", they just gave the new PC segment credibility.
Sun has lost control of the Java development space. It does not provide leadership anymore or set the agenda. Open Source does.
There is a wellspring of innovation in Open Source that beats the productivity of Microsoft's friendly tools.
It mentions the JCP but ignores the power of that organisation over the OSS world. Open Source certainly does NOT provide the leadership in the Application Server space, BEA, IBM and SAP do. Open Source does not provide leadership in the IDE space, BEA, Borland, Compuware and IBM do. Open Source does not provide leadership in the J2ME space, Sun, Nokia and Ericsson do.
What annoys me about this article is its assumption that XDoclet and Ant can be compared with a J2EE application server. And that _standards_ are not important. The JCP is the key to all of this. In the same way as Ethernet won because it was a standard the JCP lays down standards for the Java space. ANYONE can take part, it doesn't even cost you money. And you can have a say in the direction of the platform, in a much more direct way that you could have with Linux for instance.
The point this misses is that Java has not succeeded as well as it has by being fragmented, it has succeeded because it is standardised. The JCP enables all of the partners to determine what goes into the platform. Sun propose JSRs, but so do IBM and BEA... and Oracle.... and SAP... etc etc etc.
Open Source could learn much by looking at the JCP.
Consider Wi-Fi, why is 802.11x successful ? Because its all open source ? Or because a regulated standard works well in a commodity marketplace.
Sun with have commoditised the Application Server and Mobile platform spaces. The JCP has for several years been the key to that success.
The trouble with Open Source advocates is sometimes they see everything as a nail.
An Eye for an Eye will make the whole world blind - Gandhi
One problem I had with Java was cross platform compatibility. I developed on Linux but the GUI looked like crap in Windows, font sizes were different, etc which made it look, quite frankly, ugly.
The other big problem I had was I could get code to work fine in one browser (it was a simple applet) but other browsers and their plugins would have different issues.
I'll admit, i'm not a professional programmer (DBA) but I have a CS background and just do this stuff for fun but I ran into alot of issues that I though Java was supposed to solve. If your developing an application (not talkigna bout jsp and servlets here but applets or straight java 2/3tier apps) as long as you can specify which browser and JRE to use your fine but once you try and support different variations your asking for trouble.
I don't intend this to come off as a troll because I do indeed love Java but I think there are some other issues that need to be addressed other than if Java should be opensource or not. Plus, by what I have read their community procces looks fine.
"Thanks to the remote control I have the attention span of a gerbil."
It works, and it works well. And it's something that is much easier and elegant to use than, say, CORBA. Just because it's not as elegant as .NET is like saying lemons aren't as nice to eat as oranges, much less apples. .NET is targeted at running multiple languages on a single platform, java is targeted at running a single language on multiple platforms. Minor different in target audiences.
The cesspool just got a check and balance.
It's "open" in the sense that you can see it. I don't think many of us are interested in a pedantic analysis of terms that mean something specific to one group and something general to another. In other words, not all of us subscribe to the Gospel according to Stallman, Perens, or whoever. You knew what he meant, so did the rest of us, let's move on.
What's more likely is that any 3rd party can distribute their own "Java", but they can't call it "Java". without Sun's permission because Sun owns the trademark.
That would help with confusion, but would still create dilution. I don't blame Sun for not wanting incompatible versions, even if they're not called Java (which obviously they couldn't be without permission that would certainly never be given). Even still, I agree with g'parent, access to view code without distributing it makes more sense.
That's not so; this week at Javalobby Sun JCP Director Onno Kluyt states that looking at Java sources does not taint
What Onno Kluyt says on Javalobby is legally irrelevant. What matters is what the license says and the license says you are tainted. And that's not hypothetical either: Sun has caused other companies problems with those clauses.
and is willing to answer FSF questions on the issue.
If Sun's licenses require Onno Kluyt to answer questions, then Sun's license is not written clearly enough. Sun needs to fix their licenses, not try to explain away deficiencies in their licenses in legally non-binding PR talk.
Sun likes to talk a lot of PR talk, but they are unwilling to address concerns by putting their licenses in clear, unambiguous terms. And after half a dozen years of waffling on legal issues, one has to conclude that Sun isn't ever going to fix these legal problems.
Besides, at this point, there isn't any reason to look at Sun's source code anymore anyway. There is nothing of technical interest in Sun's source code, and in practical terms, Sun's legal control over the Java standard and their Java-related patents mean that trying to create an open source implementation of Java is pointless anyway.
The facts are that .NET is an extremely capable platform for both small and large solutions. The combination of dev tools + languages + framework + documentation is UNMATCHED in the industry. Sun should be damn worried, since .NET is only in its second generation.
Its no wonder that Sun is bringing back all of their founders that have brains. They are concerned about the direction that Java tech is going.
As another poster pointed out (but it's worth repeating) GPLing Java won't prevent Microsoft from "polluting" it.
Sun owns the Java spec, also the trademark. Would Open-Sourcing Java necessarily allow MS to pollute it? I would think that such a polluted version would still violate the specification, hence could not be called Java or Java-compatible, or a Java implementation; trademark law and all that. True, it might be a bit more tedious to sue MS for calling it any of the above, but what essential protection would Sun lose here?
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
I don't know about the libraries, but Sun should definitely open source the JVM. I mean that's something where Sun would really benefit, and would still maintain control. Much like the way Apple benefits from developers working on Darwin, without losing control of OS X.
Then it's conceivable that GNU, IBM, Sun, and Apple could all work on a unified JVM.
Have you not looked around lately? In addition to virtual machines from Sun, IBM, HP, BEA and the like there are plenty of crufty proprietary clean-room implementations from tiny vendors who support them poorly. There are even high quality free software versions such as Kaffe and gcj/gij. A bewildering array of Java forks already exists and as it is these are often incompatible in strange ways, not least of which that most lack features found in Sun's J2SDK 1.2 and higher. And then there are the various forks that Sun perpetuates, such as J2ME and J2EE.
The likely effect of making Java free software would be to make at least the free software virutal machines *more* compatible, not less. People in the free software community actually want their virutal machines to be as compatible as possible and consider operational differences to be bugs. Notice efforts like GNU Classpath which tend to un-fork free implementations. The major obstacle to compatability is the need to create clean-room implementations of absolutely everything, and making the J2SDK free software would solve that problem.
Not all those who wander are lost.
Tell me this. What would stop MS from shipping a version of Java that it calls, lets say 'Java Lite'. Now what MS would do is simplify it by stripping all the 'extra' features. Of course it distributes it back to the community as GPL. Now, what you have is 90% of user computers running a crippled version of Java and there is nothing you or the GPL license can do about it. I like the fact that there is only 1 Java and it works for me (nearly perfectly) everywhere. I am happy enough with the JCP (Java Community Process). I am a Java developer and I am happy! Leave it (me) be!
Free speech is getting expensive...
Yes, BSD-style licencing is a serious pitfall; IMHO the BSD licence as it stands is overly permissive, in that it allows you to modify something ever so slightly and then lock up the source code. The GPL is unpopular with many corporations, almost certainly because it forbids precisely that.
Dual licencing, a la MySQL, might work; but it could lead to a division between the "paid" and the "Free" versions, depending on what the terms of the commercial licence say about distributing modified versions. But maybe I'm just being pessimistic; it would be nice to see something done well for once, and the ability to include a JVM as part of a downloadable Linux distribution would certainly be a Good Thing.
Je fume. Tu fumes. Nous fûmes!
Hey, then let's look at Pascal (say, Component Pascal - latest Wirth's creature) - it is Pascal that created the very terms of "p[ascal]-code" and "virtual machine" :-)
:-)
And read about Lilith project - CPU was designed for Pascal, OS was written in Pascal, Office components were written in Pascal, etc
BTW, i've heard that "esmertech" made some Java-based realtime environment "Jbed" sized less that 300Kb. Don't know nothing but rumours though.
Is Mono (or better and faster www.DotGNU.org) closer to native code than Java?
.NET will go to sleep.
.NET be relativelly slow client environment (non-optimised but enough for Office-like needs), why not ?
I hope sooner or later SuperCompiling (www.refal.org) will be completed for Java, then
On the other hand, let Java be highly optimised server environment, and let
I know this is about Sun's sources itself being opened, but what about Kaffe?
There are a few in the Opensource community that would love all software to roam "free" in all sense of the word, but I for one do not think that Opensource is the answer to every problem.
People who want to see all software "roam" free don't necessarily believe that this is the answer to every problem either. We do think it is the answer to some problems, though. For instance, it is a potent cure for vendor lock-in and protects important freedoms that we value. What problem does the proprietary approach to software solve that is worth giving that up?
Meanwhile, you seem to have completely missed the point that the article in question makes. The author spells out clear and convincing reasons why in the particular case of Sun and Java, a free software license is the right tool for the job -- not the job of making free software advocates happy, but rather for making Sun a dominant player in the information technology industry. He doesn't say that every software package should be free software.
If suddenly there are 50 versions of J2EE on the market, each with its unquie traits, which do I run? How do I know that the app I program will work on the others?
This is already the case. There are already a bewildering variety of Java virtual machines with unique traits available. Sun, IBM, HP, BEA and so on offer their own brand of JVM. Clean-room varieties of all shapes and sizes exist. Most are proprietary software. Why would making the Sun implementation free software aggrivate this problem? Most likely it would make things better as many vendors would use the Sun code to increase the compatability of their own versions.
This is why a lot of developers won't port to linux, especially desktop applications: too many variations.
This is nonsense. First of all, Windows is not a single operating system. In the last decade Microsoft has deployed NT, 95, 98, 2000, XP, ME and CE systems out there (I'm probably forgetting a few), and each is different in subtle ways. Somehow this collection of platforms manages to get plenty of applications. Second, a much more important reason vendors don't port to GNU/Linux is that they judge the available market to be too small for the effort. Remember that BeOS didn't go anywhere, and there was just one variation of that. Third, many developers do port to some subset of GNU/Linux systems successfully in spite of the variations. Some just pick a popular distribution such as RedHat. Of course, people creating free software applications can just wait for patches from people who prefer this or that obscure distribution. Meanwhile, a great deal of innovation is quietly proceeding in the many distributions available.
I see the same potential of Java, to become slpit into so many forks, that it defeats the purpose in the first place.
Perhaps your crystal ball needs a bit of polishing. At any rate you've given no convicing reasons why we should expect a free software release of the Sun JDK to result in forks. Most of the variety in free software comes from completely separate applications that share no code at all. That's not a fork. Actual forking is rare and usually happens for good reasons. Even then, much compatability is often preserved. For example, some RPM packages can be installed just as easily on RedHat as on distributions derived from it.
Another good example is a good friend that is developing a support ticket application for the company he works for. I asked him, "Isn't there several GPL'd apps outhere that could installed within a couple hours?" He responded of course, but he put it this way: "I like to use my own code and not other peoples. Its a lot less messy that way." and I see his point.
This is completely irrelevant. Not only does it have nothing to do with Java or this discussion, but it is completely unrelated to the difference between free and proprietary software. I could tell rather similar stories about avoiding messy proprie
Not all those who wander are lost.
I'd like to have a VM for C++ *and* Java. That would surely rock and end some of the flamewars.
So would I, but please let's not make it anything like the tortured and ugly Java Virtual Machine. I suggest using MMIX (Donald Knuth's updated virutal machine developed for demonstrating algorithms in assembly for his books). Start with a high quality free software implementation of this and make use of the GCC back-end for its instruction set, and all that's left are some browser plugins. Every language GCC supports (including Java) should work with this approach.
(*)- The often stated security argument (java has no pointers and is therefore inherently more secure than C++) would fall with C++ on a VM.
Not quite. The virtual machine doesn't really understand pointers at all, so implementing C++ on it -- which would probably involve simulating pointers using byte arrays -- might produce code with faulty security assumptions, but it would not enable malicious code to escape the sandbox. I'm not convinced that the lack of pointers as a security feature is really all that effective, but it will take a better argument than that to make progress on the issue.
Not all those who wander are lost.
I am also tired of all the "Java-should-be-Open-Source" by people who have never bothered to spend 10 minutes looking into the JCP and how Java IS currently Open Source and how Java is NOT run exclusively by Sun anymore. Every couple days/weeks, I log onto Slashdot and someone else is making these presumptious claims without looking into the facts.
No doubt this situation is complicated by the fact that "Java" means several dozen things, but Java (meaning the Java Developer Kit) is NOT Open Source. As a result, it is impossible to distribute it with any operating systems without obtaining some sort of permission from Sun. This is a real problem, especially for freely redistributable systems like Fedora and Debian.
As for the Java Community Process, while it is much more open than it could be, it is NOT Open Source. As a result, there are ongoing problems with free software projects such as JBOSS. Though Sun has taken some steps to address these, there is more work to be done. Surely you're right that there is plenty of ignorance in the Slashdot community that works against Sun, but the truth is there are real problems created and perpetuated by choices Sun has made and continues to make.
2) The coder wrote it in AWT
I like the concept of the AWT. A consistent look and feel for applications is desirable. Also, having as much as possible of the system -- and especially the fundamentally non-portable things -- implemented in a more efficient language[1] is a good thing. All of the advantages of Java are application focused, which may be why things like JavaOS never went anywhere. The trouble with AWT as I see it is that the interface caters to the lowest common denominator, which is backwards. An interface should cater to the highest common denominator and emulate features on systems that don't have them.
Sure, use a Java tree widget on platforms that don't have tree widgets, but give me an AWT interface that makes it impossible for me to tell that native code isn't being used without a special query. This lets the system improve as the underlying platform does without forcing anyone to rewrite code. Methods that can't be supported can throw exceptions (runtime exceptions please -- I loathe checked exceptions).
The problem I have with Swing is that it has so many bells and whistles that I don't need or even want, but nevertheless have to pay a performance cost for. I use GTK+, so I've already got a theme engine. An AWT backed by GTK+ would give my applications a consistent look of the sort I want. This will happen before long because of gij, but exposing all of GTK+ would either require more widgets or non-portable code.
[1] Please don't pester me with breathless praise of HotSpot here. I understand and agree that it is in principle possible for dynamically compiled Java code to be faster than C code in some cases. However in practice this just doesn't happen. All of my C applications run significantly faster than equivalent Java applications for all cases I have ever tested. I use Sun J2SDK 1.4.2 for this kind of testing.
I also concede that higher productivity can outweigh higher performance in many cases, and that some programmers do better in this regard when using Java. I'm not one of them. My productivity is consistently with object oriented C (and even C++). Feel free to presume that this is because I don't know this or that important facet of using Java effectively, but try not to think about how this undermines the argument that Java is easier to use. ;-)
Not all those who wander are lost.
> tortured and ugly Java Virtual Machine
p hp ?memo_id=1321
I did not want to be that explicit since I am no *expert* in the JVM, but it seems to be not really well implemented.
I have found an interesting thing, an alleged internal java memo from sun:
http://www.internalmemos.com/memos/memodetails.
Are you saying that the problem is that they can not download it and put it on the Debian CD for redistribution?
Yes. Other more subtle problems of a similar nature lurk here as well.
If that is the entire problem, why can't they do it like the BSD port system, where the makefile downloads the most recent one and installs it?
That isn't the entire problem, but even so a BSD like port system is not a good solution for everyone. For example it doesn't work well for people who have low bandwidth or inconsistent connections. Obviously you're right to point out that Java is somewhat accessible to Debian and FreeBSD users, but that is not what Open Source means. I use the Sun JDK on Fedora for everything GCJ doesn't currently do. Still, significant problems would be solved if Java were more open.
I am not clear why you prefer AWT.
I am more pleased with the concept of AWT than with the actual implementation. As you say, it is dreadful. However, as I understand it -- do correct me if I'm mistaken -- Swing is built on top of AWT, which means that while it doesn't have to be slow, it can't plausibly be much faster. Also, AWT is certainly as cross-platform as anything else in Java.
Do you mean that the look and feel varies by platform? I consider that a good feature in principle since I prefer applications to be consistent across a desktop. Clearly that's a matter of taste though, and there's no accounting for it. Naturally the lack of GTK+ and Qt based AWT implementations makes things much uglier than they need to be in practice.
I usually find myself implementing lighweight components in AWT, but then I generally use HTML and forms backed by Python for everything they can support and wheel out Java only for custom widgets. I suspect that if I were writing entire applications with Java I would grudgingly prefer Swing in spite of the look and feel issue.
Since the Java chips are 32-bit with only 8-bit operands, they are able to grab 4 instructions and use 1 every clock cycle, [...]
This is not an advantage that is unique to Java. Donald Knuth's MMIX architecture has the same property and there is a GCC back-end so C, C++, Fortran, Java and other languages can be used with it easily. Unlike the alleged .NET language neutrality no changes to syntax are required. Even standard libraries only need to be changed enough to make low level system calls work.
What do you mean by ["the advantages of Java are application focused"]? Do you mean that it is no good for server software (which it is even better for than GUIs), or do you mean that it is not good for things like device drivers?
I mean the latter. (I don't dispute the utility of Java for server software, but I prefer Python for a variety of reasons.) Well, actually, I mean that the advantages of Java are not especially compelling for system software in general. A Write Once Run Anywhere kernel seems a bit nonsensical. Similarly, running system daemons on top of a virtual machine seems unlikley improve anything.
USB device drivers are an interesting counter-example, though I think the notion that software which communicates with a device over a USB bus is a "device driver" is a bit misleading and conceals what makes USB great: it transforms something that was once clearly system software into something more like application code.
Every single time you see any application crash in your OS, that is a runtime exception.
That's an interesting way of looking at things. Are you saying all exceptions ought to be checked exceptions? Does that include NullPointerException and OutOfMemoryError? Plenty of shoddy software that doesn't deal with these gets sent to customers. What makes exceptions useful in the first place is that they allow parts of a program to ignore problems that they couldn't reasonably do anything about. Checked exceptions take that advantage away, often tearing enorm
Not all those who wander are lost.
I haven't looked at this since Java 1.0 or 1.1, so this might be out of date.
Java "binaries" are restricted in two ways:
#1: It must fit the machine's CPU -- the byte ocde sequence which is legal for the JVM.
#2: It must fit the restirctions imposed by the class loader.
#2 is critical. Years ago, there was an Objective C compiler that compiled to Java byte code. The implementation managed to do everything except (if I remember correctly) poseAs, and I'm not sure about categories (I believe that did work, don't quote me).
The problem? It was legal JVM code, but not legal according to the class loader.
C++ and Java are NOT closely related. Years ago I worked for a company that had a data architechture that started from (and still needed to support) 8 bit device drivers on IO boards; at the other end, they ported a large C code system into Java, and made it instantiable -- specifically to permit multiple copies of this large system to run at the same time. The entire high end of the system needed to suport all of C++, Java, and Objective C (this was running on Mac Os X).
The design results? C++ was the limiter. Both Objective C and Java were effectively identical -- either of them could do what the other could do, they could talk to each other (apple's native bridge), etc. But C++ was highly limited. The inheritance system of C++ is vastly weaker and more limited, the bridging for C++ had to be completely manual, etc.
I'd be suprised if you could get a C++ compiler to compile to a Java backend. It seems to me that the basic assumptions of the languages is just too different.
I can see that. So, really, what we need is a solution where an open-source OS (thus alleiviating their fear of M$ practices) could include it on the install disc?
Yes, that would be a considerable improvement. Note though that there are plenty of other benefits of making j2sdk free software, both for the world at large and for Sun Microsystems. I thnk the parent article on LinuxToday makes the case for that quite well.
From the way I understand it, [...] there is an AWT component for the main window.
This matches my (somewhat rusty) understanding of things.
Well, with Swing, you have the option of your application [...] looking like other native applications
I've not tried this, but I suspect that things will not work the way I want them to because, as you pointed out, Swing uses Java code to do the drawing of components. I want the buttons, scroll bars and other widgets to use whatever GTK+ theme I have configured. I also want it to change dynamically at runtime if I alter my GTK+ theme. Using GTK native peers would accomplish this easily, but to do it in Java code seems impractical.
I don't think that [implementing lighweight components in AWT] is technically possible.
I should have been more clear about what I mean. I create subclasses of java.awt.Component and override the paint() and update() methods. According to the API reference this creates a lightweight component with no native peer, much the way Swing does. A JButton is a subclass of java.awt.Component too.
I usually use XML
I do that as well. This has advantages over relational databases in places where absolute performance is not critical. I meant that for user interfaces I use Python CGI scripts that generate a web based user interface. (I keep meaning to try mod_python, but so far in spite of my best efforts I've been unable to make my Python code slow enough for this to be worthwhile. Imagine invoking a new Java VM for every incomming web process!)
I still don't understand. AWT is the one that looks really ugly, Swing has the look-n-feel/theming options.
I didn't mean that I think Swing is ugly (or that AWT isn't ugly -- though really the problem is that Motif is ugly and AWT uses Motif). I meant that the look and feel doesn't match my desktop GTK+ theme as I mentioned above.
I prefer writing all of my BSD software (and am in the process of replacing all my httpd, ftpd, sshd, smtpd, etc) in Java, because then I don't have to be tied to any specific OS.
I suppose time will tell and I wish you luck with the project, but I'm skeptical. Packages such as Apache (and even OpenSSH, which does run on Windows) are quite portable. All one saves with Java is a compile step, and while this is a powerful advantage for applications I think the dynamics of system software are less affected by it. Most people get their operating systems on CDs and through vendor updates, so code mobility is not a concern.
On the other side, I believe performance will suffer, particularly on non-Windows platforms where the Sun VM is grotesquely slow. Non-blocking I/O is indeed efficient (though it is best to combine it with threading for SMP systems), but this feature is at least as easy to use in C.
I am actually working on something like that, because I think that idea is the perfect solution. Make a Java-based OS on CDR(W), and run it on and i386, mac, ps2, dreamcast, etc.
Again, good luck but I'm skeptical. Ultimately you will need something very much like a Unix kernel to talk directly to the hardware and implement the Java VM. I'm also not convinced that maintenence will be much easer. Most C projects separate and minimize platform specific code. A JavaOS would still need testing for each platform, and for the same reasons. Note that Sun and IBM have tried and failed to create a viable JavaOS already. That do
Not all those who wander are lost.
I don't honestly know how difficult it would be to have the Swing team add the ability to ask the OS which theme is current, but it would probably be a hell of a lot easier than rewriting all the native peers to use AWT instead.
Why would I bother? As I said the GCJ and GNU Classpath developers are already doing this for me. Furthermore, I think having Java code that somehow emulates the current GTK+ theme would be much more effort and perform much worse than rewriting all the native peers. After all the native peers are *designed* to be rewritten for each new platform Java is ported to. All that is really involved is using JNI to bind constructors and methods to the appropriate underlying GTK+ functions. Simple.
Looking at the page you referenced, what it said was A lightweight component is a component that is not associated with a native opaque window. So, I guess the Component class itself is not associated with a Peer...
Exactly. I usually place my lightweight custom components inside an applet window and integrate them into a web application. Using Swing would be overkill in such cases. I suppose that technically I'm not using much of AWT other than the event model and graphics processing routines it shares with Swing.
I don't need to [invoke a new Java VM for every incomming web process].
Of course you don't. That would be insane. The point I was trying to make is that this is *not* insane for all but the most demanding Python applications. I think this says something troubling about Java performance in general, and in fact people at Sun think so too. That's not to say that a clever Java programmer can't make a reasonably fast application, just that he or she has an uphill battle.
Performance is not critical for every aspect of every application. And the good news is that the Python example suggests that much of the Java performance problem is due to poor virtual machine implementation rather than any fundamental flaw. That means things might get better over time. I don't think Java will ever be able to compete with C for speed in all cases, any more than C will ever be able to compete with assembly for speed in all cases. But surely Java could catch up to Python. Releasing a free software version of the Sun VM might bring that about since it would give more people a chance to make suggestions and test experimental virtual machine variants.
After working for companies that build everything on Windows, Linux, Solaris, HP-UX, AIX, AS/400, etc.... I can't tell you how happy I am to only compile once. I no longer have to modify the makefile every time we try to build X or Y on platform Z... it really is a HUGE timesaver for the developer.
Actually I've worked for companies that build for each of those platforms except AS/400 (plus some others like s/390 Linux). I never found the compile isses terribly challenging, and we used scripts to automate nightly and release builds. Much more problematic were things like the lack of a good pseudo-random number generator on many proprietary platforms, and these issues often affect Java no less than C or any other language.
In addition, I have downloaded services for my BSD box (that were newer than the Port Collection), and been completely unable to figure out how to get them to compile properly, and fix the errors. Had they distributed it as a jar (especially over JNLP), I would not have had to go through all that hassles, and those services would be currently running.
I think you underestimate how much this kind of problem affects Java. Just try installing two or more major enterprise Java applications. Each will require a virtual machine from a specific and often mutually exclusive subset of vendors and version numbers. Perhaps someday the Java platform will be less of a moving target and this argument will be stronger. A free software virtual machine
Not all those who wander are lost.
But, since Swing ALREADY has the GTK theme, I have to disagree that writing all the peers is any easier than calling a single line of code to switch themes.
I usually place my lightweight custom components inside an applet window and integrate them into a web application.
Hmmm.. I haven't done any applets or AWT for a couple years now. I always use Swing over JNLP. However, the key to my decision is the fact that AWT is always considered unacceptable in the looks department. If you need it embedded, I can understand using an Applet -- but otherwise, JNLP provides MUCH better performance (only updates jar-diffs if the jars have changed, instead of redownloading everything every time you hit the page). The apps I have been doing are Swing over JNLP -- and we have not had any speed problems. I can't speak to the overkill, as I think I would have to brush up on AWT to even remember how to do it.
The point I was trying to make is that this is *not* insane for all but the most demanding Python applications
I disagree. Starting a new process for every incoming request is insane regardless of language. Otherwise, Thread Pools wouldn't exist.
Python example suggests that much of the Java performance problem is due to poor virtual machine implementation rather than any fundamental flaw
I think it more likely that the Apache mod is the problem, rather than the Java VM. Pure java apps from the command-line seem to run very fast on both Windows and BSD. It is only from Apache that they seem slow.
I think you underestimate how much this kind of problem affects Java. Just try installing two or more major enterprise Java applications. Each will require a virtual machine from a specific and often mutually exclusive subset of vendors and version numbers.
Personally, I have installed a few different applications that installed their own JRE, and I submitted bug reports to those companies because A) They were installing JDK 1.2 when I already had 1.4.2 on my system; B) They were ILLEGALLY installing the JRE (which gets back to your original point). Of course, if they were using the Sun licensing correctly, their installer could have installed the newest JDK (or none at all since I had it installed already) instead of forcing me to install and end-of-lifed product.
As far as the enterprise software... I have installed a few of them, but none of them were pure-Java (WebSphere for example). The problem is that many of those Enterprise applications are being installed by big companies that have to have 100% control instead of doing 10 minutes of research to find the best way. JNLP is definitely the best Java solution for installs, but unfortunately very few big companies use it yet.
I think an open-source VM (not GPL, since they wouldn't use that) would not alleviate the problem you mention. Currently, the problem is that many times they include an end-of-lifed version of Sun's JVM. Making it so that they each have a slighty modified VM would definitely make this problem worse. IBM would have an extra opcode that no one else has, Oracle would have some pre-processing stuff that no one else has. It would more likely fracture the java stability instead of encouraging they all distribute the same thing. As an easy example, if they wanted to distribute Linux on their CD -- which would they use? RedHat? Slackware? Debian? Their own distro? I think you get my point.
Compare the sizes of the resident images, or use the "time" utiltiy (under Cygwin on Windows).
I am not sure what you are talking about with the "resident images", but using Cygwin is NOT the correct solution for measuring time on a Java platform. If you would like the correct source code to accurately measure how much time is taken on ANY platform, I can send you a copy of my class I wrote to test encryption/de
http://www.google.com/profiles/malachid
But, since Swing ALREADY has the GTK theme, I have to disagree that writing all the peers is any easier than calling a single line of code to switch themes.
This is misleading for two reasons. First, what Swing has already is NOT what I want. Since it is necessarily written in pure Java, the best it can do is emulate the look and feel of GTK. Perhaps it can do a reasonably good job, but it seems unlikely to be perfectly correct in all cases and even a small visual inconsistency can be distracting. Swing is less likely still to quickly adjust to GTK theme improvements over time. Of course, having a Swing theme that emulates the *default* GTK theme and one that emulates the *current* GTK theme whatever it may be are different things. I very much doubt that Swing does or will ever do the latter. (I notice that gtkswing clearly states that only the default theme is supported. Is that the theme you are referring to?) Remember that new GTK themes are created all the time, just as Swing themes are. How could Swing possibly have support for all of them, and why would the developers even bother trying? Using AWT peers will give complete and correct support for the current -- not just the default -- GTK theme no matter when it was created or where it came from, for no additional effort.
Second, much of the work needed to write such peers has already been done. Perhaps the GCJ team is reusing work done for java-gtk in which case the heavy lifting is already finished. Either way, from my perspective it's just a matter of waiting. Meanwhile my AWT applications, while terrifically ugly, are quite functional and will get better looking with no code changes when the GTK peers appear.
Starting a new process for every incoming request is insane regardless of language. Otherwise, Thread Pools wouldn't exist.
Not so. Starting a new process for every incomming request is perfectly sensible if performance requirements are within a certain range (this depends on the hardware in use and what other applications need to run on the same machine). Clearly a persistent approach such as mod_python or servlets will give better performance, but this is not always needed and is always more complex. That means more time consuming to create and debug. Consider a company that needs a prototype of a web application, for instance. A few simplistic Python scripts can be put together easily and will likely be more than fast enough to get the point across. Doing the same thing with Java is not likely to be a good idea, because the syntax is more complex, because there is a separate compile step (Python compiles to byte-code as it runs) and because performance is sure to be dire.
I think it more likely that the Apache mod is the problem, rather than the Java VM. Pure java apps from the command-line seem to run very fast on both Windows and BSD. It is only from Apache that they seem slow.
I think it is impossible for Apache to be the problem, because it has no idea what language a CGI script is written in and therefore would have to deliberately introduce delays to slow down Java. In my experience the overhead required to bring up a Java virtual machine is considerable, and this makes command-line performance unacceptable for many purposes where Python does fine. This point of view is seconded by engineers at Sun Microsystems in the internal memo I linked to last time.
Personally, I have installed a few different applications that installed their own JRE, and I submitted bug reports to those companies because A) They were installing JDK 1.2 when I already had 1.4.2 on my system; B) They were ILLEGALLY installing the JRE (which gets back to your original point).
Point A is quite deliberate and I expect your bug reports don't get far before being stamped WILL-NOT-FIX. These vendors want a JRE that they can depend on to behave pre
Not all those who wander are lost.
I have no idea what the current Swing implementation does, as I don't run GTK. That's why I asked if you had yet tested it. What I thought it *might* be doing is something like SkinL&F, which, as I understand it, can read the GTK and KDE themes themselves, thus emulation should be completely accurate. I am not sure if that is what the Swing team did or not. I also am not sure if they have the JVM setup to use the default GTK theme, or the current one, since I am not using GTK myself. That is why I suggest you try it and see. It *might* do what you want *now*.
Consider a company that needs a prototype of a web application, for instance. A few simplistic Python scripts can be put together easily and will likely be more than fast enough to get the point across.
A few scripts might get the point across, but every time I have seen this situation, they stress tested the website to determine how well it would scale. Any time something needs to scale or get stress-tested, I can't believe launching processes is the best way.
Doing the same thing with Java is not likely to be a good idea, because the syntax is more complex, because there is a separate compile step (Python compiles to byte-code as it runs) and because performance is sure to be dire.
That would depend on the approach. Serlvets or JSP, perhaps. In my approach, I simply load a compile .class file. You COULD precompile the script (whenever the timestamp changes) automatically inside the server, thus getting the type of behavior you are expecting... Personally, I leave it at letting them run javac, as all Java developers are used to that -- but I agree, the web-app concepts all suck for distribution. That's why I am not using them in my server.
In my experience the overhead required to bring up a Java virtual machine is considerable
I am not having that experience on FreeBSD or WinXP. I can not attest to Linux speeds, but I am using the Linux JDK on my BSD box. I use Java for a lot of command-line stuff (sometimes using a batch file to launch it so I don't have to worry about where it or the supporting classpath are)... but I never have any speed problems. It launches, parses the command line, determines what to do, and can be done before my finger leaves the enter key.
What I was saying was that I think the Apache java mod was the problem... I mean, they did make one that is supposed to be A LOT faster, but I could never get it to compile.
These vendors want a JRE that they can depend on to behave predictably and whatever version you have on your system -- whether newer or older -- is considered too great a risk.
I understand these arguments, and have heard them many times from previous employers. The fact is, however, they complain about performance and bugs, but prefer to stick with one that is no longer being patched instead of using the one that fixes their issues. They should have at least 1 engineer that is able to test their system with the newer JDKs. I mean, realistically, it is a very stupid argument on their part - they spend a lot of money (billions, depending on the company) because tech support calls increase as people are using a newer version that doesn't work with their product. In my personal experience, the only problem (other than the 'assert' or 'enum' changes) is that they specifically create a JVM in JNI code, which breaks because the u
http://www.google.com/profiles/malachid
What I thought it *might* be doing is something like SkinL&F [l2fprod.com], which, as I understand it, can read the GTK and KDE themes themselves, thus emulation should be completely accurate.
I am skeptical that it is even possible to do what I want with pure Java for the reasons I already mentioned, but I'll check it out.
A few scripts might get the point across, but every time I have seen this situation, they stress tested the website to determine how well it would scale.
One stress tests a prototype to learn how much performance needs to improve, not because it is expected to be fast enough for production use. The point, after all, is to get something work ing quickly to prove that the application as proposed can get the job done. Python CGI scripts are great for this purpose. Clearly a mod_python application will beat the performance of a CGI Python version, and I have never said anything to the contrary.
The point is that Python is more flexible than Java because (among other reasons) it permits this simple and effective techinque. Servlets and JSPs are demonstrably more complex to create and install. Python is also every bit as portable and free of pointer problems as Java. And as for simplicity, try teaching both to a non-technical user. I could go on, but you've clearly made up your mind that Python is no good ages ago.
I am not having [the experience of considerable overhead required to bring up a Java virtual machine] on FreeBSD or WinXP.
I suspect that is because you don't compare apples to apples by considering equivalent C programs. No doubt once one is conditioned to accept the sluggish start-up time of a Java virtual machine everything seems fine. I use shell scripts for many kinds of task and find them much snappier than command-line Java programs even though they often need to launch several processes running C programs.
However, without hard numbers which neither of us have at hand or are inclined to go generate, this is just so much subjective chatter. Go ahead and use command-line Java programs if you find that helpful for getting work done. I'll stick with C programs and shell scripts, thanks.
The fact is, however, they complain about performance and bugs, but prefer to stick with one that is no longer being patched instead of using the one that fixes their issues.
This supposes that later editions of Java simply fix their issues and introduce no new problems. That simply isn't true. Backward incompatible changes constantly creep into Java releases. On the basis of technical intuition, I doubt that the increase in support calls on this issue will cost more than the extra development time needed to identify and work around version compatability problems. Of course, any such problems that escape the testing net will generate those extra support calls anyway. Apparently the professional bean counters whose job it is to make such calculations for those vendors based on hard numbers agree.
In my personal experience, the only problem (other than the 'assert' or 'enum' changes) is that they specifically create a JVM in JNI code, which breaks because the user has a more up-to-date system then the distro.
And you think it is acceptable that JNI code can break between minor VM releases? I don't. Release a new interface and implement the old one interms of it, if necessary. Anyway there are plenty of actual classes that change their behavior between releases, so JNI is not the whole of the problem by any means.
Back to that argument? If Sun were to make the single class 'Object' GPL, it would cut off most of their development support.
Back? Please consider what I actually wrote: Actually, if Sun does choose to release a free software virtual machine they will certainly use the GNU GPL or something like it. Are you really unable to distinguish between the Object class and a virtual machine? As far as making Object GPL goes, y
Not all those who wander are lost.
Well, the problem is in the C code. The situations I have seen, they hard-code the location to load jvm.lib/dll from. In my experience, that was the reason they included Java at all, so they would know where to find that library. Unfortunately, however, if I am calling into their program, and it loads their archaic version of Java, some of the features my code might rely on may not exist yet. The problem was in the C code, though, not the Java code.
Back? Please consider what I actually wrote: Actually, if Sun does choose to release a free software virtual machine they will certainly use the GNU GPL or something like it.
Back, because discussions about "Open Sourcing Java" was what started this conversation.
Are you really unable to distinguish between the Object class and a virtual machine?
No, but the assumption is that they would have to OpenSource the core libraries as well as the VM itself.
As far as making Object GPL goes, you may be right that this would require derivative works to be released under a GPL compatible license (and you may be wrong, depending on how a court chooses to interpret a derivative work)
Even if a court chose to say otherwise, doesn't the whole concept that EVERYTHING extends Object (even if you don't do it explicitely) require GPL, by the Spirit of the GPL?
I doubt that Sun would do such a thing. More likely they would release the virtual machine under the GPL and the class libraries under the LGPL.
That, IMHO, would be a much more reasonable approach. I have nothing against the LGPL. Although, wouldn't LGPL allow two different vendors to have a DIFFERENT implementation of the Object class, perhaps with its own methods that only exist on their platform? That could break cross-platformability.
but your claim that this license hurts the open source community is completely preposterous
Since many companies have made me rewrite things because the current implementations were GPL (ie: reinvent the wheel), I claim this hurts the open source movement. Had those library been LGPL, for example, those companies would have allowed me to use and even improve upon (and return to the community) those libraries. Since they were GPL, we were not even allowed to download them. I can honestly say that I think the LGPL helps the community, but the GPL ensures that the same code gets rewritten over and over and over instead of being improved upon by those that can not use the GPL for one reason or another.
And by the way, how exactly do you reconcile despising the GPL while rallying to the defense of the much more restrictive license under which the Java virtual machine is currently distributed? That must be an interesting bit of mental gymnastics, and I'd like to know more about it.
Simple, I can license my Java programs under any license I want. The GPL restricts my rights to my own code -- the Java licenses do not. You say that they are more restrictive, but proof-in-point is that GPL puts restrictions on your Java program that Sun/Apache/etc do not. When I can do whatever the hell I want, I do not feel restricted.
Upgrading a platform does not have to make it unstable
If you look at the FreeBSD documentation, they explain that the reason they do not do lots of updates like Linux does is because sometimes those patches introduce problems, whereas BSD makes sure they don't before releasing them.
I never said Java was unusable, it just requires obnoxious steps like bundling a known good virtual machine version in some cases
I have never had to bundle a JVM with any software I have written. In fact, the last major software I did, the readme (html-based) had a link (JNLP) to launch the application, and a link to install the JRE if the JNLP link failed. But, I didn't have to include a JVM.
Linux is an excellent example. A c
http://www.google.com/profiles/malachid
No, but the assumption is that [Sun] would have to OpenSource the core libraries as well as the VM itself.
Certainly. But the assumption that the libraries must be released under the same license as the virtual machine doesn't follow from that. Even the Free Software Foundation notes that the GPL is not the best license for all software. They recommend a BSD-style license sometimes, as for the Vorbis libraries. More to the point, the FSF already distributes GNU Classpath, which implements much of the Java standard library, under an LGPL-like license.
Anyway, I think we can all agree that retroactively revoking the freedom to create non-GPL licensed Java libraries and applications (even if such a thing could be done, which seems improbable to me) would be quite impolite and not especially clever. People who wish that Sun would release the virtual machine under the GPL or some other free software license most likely do not mean anything of that sort. I certainly don't.
Since many companies have made me rewrite things because the current implementations were GPL (ie: reinvent the wheel), I claim this hurts the open source movement.
I would believe you if said this hurt you or the company that paid you to rewrite things, but I don't see how this hurts the free software movement (sorry, but I don't particularly care about the open source movement). Reinventing the wheel is the price one pays for not cooperating with the community.
Had those library been LGPL, for example, those companies would have allowed me to use and even improve upon (and return to the community) those libraries. Since they were GPL, we were not even allowed to download them.
Why did you put "return to the community" in parenthesis? This is the *only* germane part of your argument. No amount of harm to you or your company counts when asking whether the GPL harms the free software community, of which a company that forbids even *downloading* anything licensed under the GPL (an idiotic policy, by the way) is clearly not a part. Also, you are failing to distinguish between GPL applications and GPL libraries. Anyone willing to return improvements to the community should have no problem with the former. Do you admit that what you really despise is the use of the GPL for libraries and not the license itself?
As far as libraries go, even the FSF notes that whether the GPL or LGPL is preferable depends on strategic concerns. When there are competing proprietary libraries they prefer the LGPL for exactly the reason you mentioned. Only when a library is unique and innovative do they recommend the GPL. In such cases the loss of your potential improvements is probably made up for by the incentive this gives to more sane organizations to make their application free software. Remember that helping people to create proprietary applications is not the goal of the free software community.
Even if a court chose to say otherwise, doesn't the whole concept that EVERYTHING extends Object (even if you don't do it explicitely) require GPL, by the Spirit of the GPL?
Not really, no. The GPL was created in order to prevent companies from improving free software and releasing the result under restricive proprietary licenses instead of giving those improvements back to the community, essentially tempting users away from free software using the efforts of free software developers themselves. This is essentially the situation economists call the Tragedy of the Commons. Public domain software and software that is licensed under BSD-style terms is regularly treated this way.
(In practice free software development has turned out to be so effective that proprietary companies have trouble keeping up. BSDi isn't as successful as FreeBSD, for example. Still, that isn't the case for every project and there are other good reasons for using the GPL in many cases. For example, I don't want soft
Not all those who wander are lost.
Here is an article that offers further explanation of how the GPL helps the free software community and is even advantageous for corporations in many cases.
Not all those who wander are lost.
That isn't what I got from reading that article.
Apparently you overlooked passages like this one:
And this one:
And this one:
I could go on, but before long I'll have quoted most of the article. Once again, the point is that many companies prefer to contribute to GPL licensed projects. That makes your claim that this license is hurting the community because companies are afraid to deal with it seem rather weak, to say the least.
He also said that most of the developers he talked to were GPL-fans, which obviously skews the overall results.
Exactly how does it skew the results? This wasn't an election. He was collecting arguments and attempting to understand why corporate sponsors seemed to prefer GPL licensed projects. Are you suggesting that there are BSD license advocates with powerful points to make who simply didn't bother to communicate them for some reason? Or are you just seizing a point you barely understand and waving it around as usual?
I think that is where you and I differ. If I had to choose between everyone (even MS) using my code or only the Linux users using my code (because that is where most of the GPL development is), I would choose widespread usage.
No, I think you have managed to misunderstand yet again. For one thing, you have failed to distinguish between running code and integrating it into proprietary applications. I have no objection to Microsoft or anyone else running my code for any purpose, studying it to learn from it, redistributing copies or improving the program for the benefit of everyone. What I don't want is to permit a situation like what happened with Kerberos, where Microsoft made proprietary changes to create incompatability and refused to release them. Notice the BSD-style license there. I also want to prevent organizations that might one day maintain my code from later deciding to make the code proprietary, as almost happened to the X Window System twice now. Again there is a BSD-style license involved. Have you ever heard of something like this happening to a GPL project? I haven't.
I find the GPL an effective tool against that, and so do many people around the world. Maybe you don't care if your code becomes the next thing Microsoft mangles in an effort to protect market share. In that case, go ahead and release your code under a BSD license if you want, or just commit it to the public domain. Any contribution to the free software community is a good thing, so I'll not complain. But spare me the nonsense about how the GPL is hurting the community.
For another thing, your claim that most GPL development is done on Linux is suspicious. Maybe it's even true, but it is certainly unenlightening. FreeBSD, NetBSD and OpenBSD all ship GPL licensed applications in their distribution. I am sure you are using plenty of GPL applications on your FreeBSD machine without even knowing it. I'm also sure that many capable engineers from all three projects have made valuable contributions to GPL projects over the years, just as people who prefer the GPL have nevertheless been quite willing to contribute to projects using BSD-style licenses. I know for a fact that some FreeBSD kernel hackers have contributed to the Linux kernel and vice versa. The quasi-religious schizm you imagine is mostly fictional among the people who do the heavy lifting.
Realistically, I wish *all* code was Public Do
Not all those who wander are lost.
While that may be true on the Linux platform, I do not believe that to be accurate on either my Windows or BSD box. MOST of the software on my BSD box is free and NOT GPL.
Over half of all free software available on the most important internet archives for the stuff is licensed under the GPL. Check the statistics found here. I didn't say that half of the software on your FreeBSD or Windows machines was GPL licensed. More than half the software on your Windows machine is surely proprietary. I'm sure that the FreeBSD base system is almost entirely BSD licensed. However, stroll over to the ports system. There you will find a convenient way to install GCC, Bash, Emacs, and an endless selection of powerful and useful GPL applications and libraries.
Does FreeBSD even come with a C compiler that isn't GCC? On my FreeBSD machine "cc --version" gives me GCC output, but the first thing I do when I install such a thing is setup a variety of useful GPL applications, so I very well may have clobbered or overlooked some anonymous BSD licensed compiler along the way.
Do you disagree? Are you saying it is OK for me to scavenge code from GPL software to make other non-GPL free software? You make it seem like GPL is the only 'free' solution.
Are you even paying attention? I did not say it was acceptable for you to scavenge code from GPL software and place it into proprietary code. However, merely looking at GPL code will not prevent you from writing your own oringinal non-derivative but possibly similar code that does similar things. Read the GPL and tell me where it says that you can't do this.
Even IBM has their own open source license.
I have said over and over again that the choice of whether to use the GPL is a strategic one. Have you read the IBM public license? Here is what the FSF has to say about it:
In other words, the GPL is not restrictive enough for IBM in some cases. Meanwhile IBM contributes to GPL projects including Linux all the time, so they are clearly not allergic to it.
However, nothing on either of those pages show anything about the "Spirit of the GPL". However, a quick search of Google OR Slashdot will show that people quite regularly complain about projectX or licenseY breaking the Spirit of the GPL.
Good grief. Do you mean to say that the hoards on slashdot and various web logs are a better arbiter of what is and is not within the spirit of the GPL than the Free Software Foundation, the organization that created it, simply becuase the latter doesn't use the exact phrase "Spirit of the GPL" on the page?
Perhaps this is an issue that would be better resolved directly with licensing@gnu.org, with whom I will email directly to get clarification.
Yes, do. I'm sure you'll be back with an out-of-context quote that you've only half understood and turned upside down to make into some nefarious thing, but at least you will have had the opportunity to see learn something.
And can that resulting application be BSD-licensed? NO! It has to be GPL'd.
And your point is what exactly? What I said was that the GPL gives you an incentive to make your work free software, and it does that.
However, if the code was Public Domain, then NO ONE would question that everyone could use it without reinventing the wheel. GPL does not add this capability -- since Public Domain (BSD, etc) all have been around with that sa
Not all those who wander are lost.
However, I can tell you that every company I have worked for forbade GPL, but have encouraged me to contribute to multiple projects using Apache, BSD and SCSL licensing. Actually, even a few LGPL.
Anecdotal and irrelevant.
If I go and collect the opinions of all the people on the JCP (whom all use different licenses) or just Java-using companies in general, the results would be just the opposite.
Obviously you didn't notice that the original column from which the author collected his data was posted on ZDNet, which is not exactly a pillar of the free software community. Even so, I say again that this was not an election. Evan Leibovitch did not set out to compare how many people prefered the GPL against how many didn't, nor did I bring the article to your attention to show that the GPL was winning some kind of popularity contest. He started by *noticing* that the GPL was winning the *money* contest and asked why.
Whether you admit it or not, the reality in the market place is full of evidence that the GPL does not in fact harm the free software community and in fact is probably helping to bring in companies that don't contribute to projects with less restrictive licenses. (That is not to say that companies that do contribute to non-GPL licensed free software are not contributing to free software -- they are. Think of it as a two pronged approach.)
For something like the Grep utility, there is no difference if it is run from a GUI find-button; as I understand it.
Running an application and using as a library are different things and are affected by the GPL differently. Anyone, including Microsoft, can freely run a GPL licensed application. No, they cannot simply transform it into a library and incorporate the code for it into a proprietary software application. That is why we must distinguish between the use of GPL code as a part of a GPL application or as part of a library. I want my code to be usable in the first way but not the second. Maybe you have different goals for your code, and if so you should not use the GPL to cover it.
Everyone is afraid of Microsoft stealing their code and claiming it to be their own. I just don't honestly think any license will stop them, since they seem to break them all the time. Sure, they end up in never-ending lawsuits, but they still do it.
Microsoft is forced to comply with licenses they have violated and often to pay significant damages all the time. Nevertheless, (can you tell what's coming next?) you've missed the point. I don't want *any* company anywhere to incorporate my code into proprietary software. Even if the GPL somehow just didn't apply to Microsoft it would be solving most of the problem for me.
When contributing to the Apache Ant project, they insisted I not event look at GPL code.
I find that claim suspicious, so perhaps you would care to back it up with some facts. I notice that the Apache Ant task guidelines explicitly mention the incompatible nature of the license they use an the GPL. I see that checking that a task does not depend on GPL or LGPL code is listed as an important step before submission. That is all quite sensible. However I see no indication there that merely reading the GPL licensed source code with a similar purpose is enough to disqualify submissions. One would think such a requirement would be well documented to eliminate confusion.
I don't doubt that you have been given such instructions when working on propriretary products. That is how the proprietary software industry looks at these things. Such an attitude would be quite appropriate regarding most non-disclosure agreements covering proprietary software, but that doesn't mean this is a sensible policy for GPL covered code.
Even if I concede all this nonsense for the sake of argument, it would still fail to prove that the differences between the GPL and BSD-style licenses
Not all those who wander are lost.