Slashdot Mirror
Sun to Release Java Source Code
pete314 writes "After resisting for years, Sun Microsystems CEO Jonathan Schwartz at JavaOne this morning said that he will release the source code for Java. The company is asking developers to provide feedback on how to best get there and prevent forking and fragmentation."
"After resisting for years, Sun Microsystems CEO Jonathan Schwartz at JavaOne this morning said that he will release the source code for Java.
:-/
BZZT! WRONG! Java source code has been available for YEARS! (And no, I'm not going to bother linking. If you don't already know where to find the SCSL and JRL licensed code by now, you need to pull your head out of your butt and Google it.)
This article is nothing but a blurb that suggests that Sun is looking at Open Sourcing Java. (What the Slashdot pundits have been screaming for, for years now.) Unfortunately, one of OSI's core requirements is forking. So Java will never be able to make the pundits happy.
Javascript + Nintendo DSi = DSiCade
Use a spoon. Not only does it prevent you from forking, but its really hard to fragment anything with it.
Well.. maybe. Or Maybe not. But Definitely not sort of.
C'mon Sun, we're sick of hearing about the pending open sourcing of Java. Show us the license!
I know, I know, Sun's afraid that Eclipse is going to... well eclipse the sun, but c'mon! make it GPL, retain the trademark and you won't believe the explosion in Java coding you'll see!
There are shills on slashdot. Apparently, I'm one of them.
That's why they have resisted it for so long. Now it will just be one more thing where there are sneaky, annoying inconsistencies between distributions. Nothing will be "broken", but things will end up being implemented slighly differenty and some portability will be lost.
I guess it doesn't *have* to happen, but there seem to be more than enough people that want to take Java away from Sun that it's inevitable.
Jonathan Schwartz at JavaOne this morning said that he will release the source code for Java. The company is asking developers to provide feedback on how to best get there and prevent forking and fragmentation.
Well, as a developer, I will tell you THE one and only way to prevent forking and fragmentation...
Don't release the source code.
Oops.
The code isn't going to fork itself. If Sun is doing a reasonable job maintaining the source code, they don't have much to fear from a fork. If they are not doing a good job, a fork would hardly be a bad thing.
The title should read "Sun to Open Source Java". The source code has been available for a long time.
Java offers nothing useful or exciting compared to what's out there.
What else is *out there*? c,c++,C#, Visual Basic, Python? If your going to tell me its terrible, I certainly understand that point of view, please at least tell me what you cosider to be better and what applications you have in mind. Just telling me its bad and not good for much, doesn't help much.
Any suggustions to what is out ther that holds such great advantages to Java?
Well.. maybe. Or Maybe not. But Definitely not sort of.
What I don't get is why Sun have such a hissy fit over supposed Java incompatibilites introduced through forking of free licensed code. What's to stop them preventing people from calling derivitive versions 'Java'? Sun could implement strict compliance testing, a-la UNIX, to ensure that derivitives are compatible, and can license the 'Java' trademark for use by those compatible versions. Problem solved.
Create a strong community with strong corporate involvement. If somebody does fork the code, the project will either die or be assimilated back into the main branch. Don't worry too much about others, just make sure that Sun will stand behind an official community. And standing behind them also means listening to them, even the ideas that you don't like.
Look at Perl. It's open source, and hasn't really forked. It has, however, evolved.
Anyone can use the code. You can only call yourself "Java" if you hit certain specs and pass some tests. In other words, if you can prove that you meet the Java standards (with API support etc), you can call yourself Java and use the source code. If not, you aren't Java. Feel free to use the source code.
This may not be a GPL license, but that's alright.
Is there any reason why such an approach wouldn't work?
Except for ending slavery, the Nazis, communism, & securing American independence, war has never solved anything.
IANAP(rogrammer), but I can see how it would make a variety of things possible within the open source community.
For instance, if one knows exactly how Java works, one should be able to make code intended for a Java VM compile into native binaries. That means that every Java app out there, and there are a lot, should be able to run much faster and in native windowing environments within Linux - and that Java code written natively for Linux would also be (somewhat) portable between platforms using VMs.
Again, I'm not a programmer, so someone correct me if I'm wrong.
Step into a huge movement. Don't Tread In Me.
Again, I'm not a programmer, so someone correct me if I'm wrong.
You're not wrong, but such tools already exist. IMHO, all this will do is lead to incompatible versions of Java.
But GPL'ing it would create the requirement that every project that used it would also have to be GPL'd because at runtime everything links to its runtime environment.
Which would make the commercial use of Java impractical.
I can't think of a faster way to kill it that to put the GPL on it.
File under 'M' for 'Manic ranting'
Whatever 'how' you come up with must satisfy one simple criterion: make it possible for the major Linux distributions to include the Sun JVM, runtime (tailored to whatever degree necessary to work well,) and source, in their product.
Lurking at the bottom of the gravity well, getting old
Gee, given your handle, is it any surprise what sort of Java you'd be focused on?
It's not offtopic, dumbass. It's orthogonal.
Is there any reason why such an approach wouldn't work?
That approach works great. That's the license they already have.
Although the source for the reference platform has been available for some time, the fact that it may become 'free' means forks are inevitable, and that's the only thing that's missing from Java, namely the freedom to fork it. Mind you, if the C++ crowd get hold of it that's what it will be... completely forked.
My favorite Java feature is that it works well when you export the DISPLAY.
Some excellent examples of this are
Java in Mozilla, OpenOffice, Veritas NetBackup and UGS TeamCenter products.
I too think that it's important that Java does not get forked.
Oh well, that my 2 cents.
"""A group of developers could split off from the main Java community and form a second, independent group that follows an independent course. This could lead to confusion with developers and cause Java to lose focus.""" Am I the only one tired of hearing nonsense like this? Java has already been forked. Multiple times. There are already open source implementations of both the VM and the base class libraries. These implementations are distributed by default in most big Linux distributions: RedHat, Ubuntu, at least. I know. I started the port of Eclipse 3.0 to Ubuntu/Debian. It runs on GCJ and Kaffe or IKVM. All very high quality *FREE AND OPEN SOURCE* virtual machines. It uses Classpath as it's base class libraries. Exactly what more is there to fear? There are ALREADY other entities out there who have "forked". Why don't most people realize this?
Really? Not in C/C++? How do you get the first compiler to run on a new architecture? Probably a cross-compiler.
(Not a troll: genuinely curious & ignorant)
Slashdot entertains. Windows pays the mortgage.
Whereas I'm not surprised that Slashdot is bringing out the normal anti-Sun's-attitude-towards-Java dogma, is this really a surprise? Jonathan Schwartz is closer to being a pro-Slashdot geek than Scott McNealy ever was. If anything, McNealy was just an arrogant ass who liked staying in his ivory tower with Bill Gates and Larry Ellison. Schwartz has always shown to be more of a geek than McNealy, and releasing the source code to Java has been a "cry of the geeks" for a long time.
(Note that I don't use "geek" derogatorily as I fondly consider myself to be one.)
Sun is giving us a ton of surprises in the past few years with Schwartz on board - from AMD processors to their first, AFFORDABLE powerhouse workstations (Ultra 20). I'm not surprised by this move at all, but I also don't blame them for wanting to be able to protect one of their revenue streams. At least Sun is trying. I guess the Slashdot "make it free or forget it" is still too strong, based on the responses I've seen so far in this thread. Looks like when it comes to Java, Sun is damned whether they do or don't. Pity.
That means that every Java app out there, and there are a lot, should be able to run much faster
Compiling has trade-offs. You must target the end environment (CPU, OS), and also try to optimize code (for the target CPU). But you can only do static optimization.
Modern JVMs optimize on the fly. So the more you use a particular path through the code, the more it will be optimized (obviously only so far...). See this article: "The dynamic nature of the Java language provides opportunities for better optimization based on runtime profile information, and this is a significant advantage of a Java dynamic compiler over a traditional static compiler."
So having a compiled executable may not yield faster run times. It may have faster load times, which is where most of the perception of slowness comes from.
I use a rather large Java IDE (Eclipse) for development. It takes 10-15 seconds to load up the IDE from a cold start (2.1 GHz laptop). After that it is just as fast as I can type, which includes on-the-fly error/syntax checking, code assist, and so on.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Don't get me wrong, I'm all pro-FOSS, still... We have this: http://java.sun.com/j2se/1.5.0/source_license.html and I don't see how this "new" turn of events will further help Java. I think it will be like with OO.org, it's open still, only a handfull of devs care about it for various reasons. I really like Sun as a company and as a source of hw and sw (no, I'm in no way affiliated or related) and I hope this turn will be in the right direction.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
General Public License
Seriously, there's a reason it's so popular. It ensures that noone can hijack the project and the source code will be legitimately free. You will make the most people happy with your decision if you go that route. Anything else will be seen as hedging your bets.
Tom Caudron
http://tom.digitalelite.com/
-Tom
There are already open source, free, and feature complete Java Virtual Machines. There are also open source and nearly complete class libraries. Check out kaffe, gcj and classpath.
These can run most non-Swing applications perfectly. They are distributed By Default in Redhat and Ubuntu. Eclipse runs on them, Tomcat runs on them. Most Java applications run on them. This is old news.
It is not under question how "java works". It's easy. It's well published and well known.
Just so I fully grasp your analogy, do you mean Perl < 6.0, which was damnably hard to read, or Perl >= 6.0, which will be impossible to understand?
Rich And Stupid is not so bad as Working For Rich And Stupid.
IBM already has their own cleanroom JVM. Anyone who HASN'T already seen the Sun JVM source code can write their own JVM (and there are already some opensource ones). It's all just a matter of manpower.
Even in this here Slashdot page, I see the java tag used all over the source code for this page.
/. who don't know this.
For the bazillionth time, Javascript is not Java. I can't believe there are people on
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
Are the various demagogues of Open Source going to track how the new license helps Java grow?
:)
I'd say that this is a classic situation where Java will not be the only thing worth studying. Once the license is decided and the code is even more out there for even more possibilities will we see IBM do even more with it? Will we see schools teach more Java because it has passed open source muster? Will this help it gain market share? Force M$ to open its languages? What about a new free Delphi?
I hope everyone, including Sun, is pleased with the outcome of this. Its not everyday such a big player takes this step. What do people think will happen?
We'll have to see.
LS
That would explain all the Java I was taking at school. Of course, the fact that it took the school three years to find the money to upgrade the Microsoft site license to .NET was probably a coincidence while Java was so big.
if people didn't like 'em, they wouldn't happen.
Twenty years ago people were all the time telling me that the biggest problem with unix was all the different versions, nobody was ever gonna use it if they couldn't be certain tht the version they picked will still be around in ten years. They were for the most part MVS bigots (or CDC cybernaughts).
I've heard a lot of the same stuff 'bout linux, mostly from windows washers.
This talk about forks doing harm to java is pretty much the same type of FUD.
I just see Emily Latella saying "Forks are good! I think there should be more forks. Just imagine how much more the Chinese could have contributed if they hadn't spent so much time fumbling around with those chopsticks..." Finaly, Chevy leans over and whispers "fork me"
I can't wait to make the Javalord JVM. Soon the internet will be overrun with craplets that only work on my JVM. MUHAHAHA
Duke Nuke'em forever will release their source code....
That is, come up with a new implementation that will become more popular than the original.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I don't care one bit about Sun Java as open source. Sure, it could be nice, but do you really think that a great number of amazing programmers would eagerly step up and immediately start to maintain and improve Java? And in that doing a better job than Sun & JCP is doing right now? Don't think so...
However, there is one thing Sun could do... one very important thing: remove the stupid click-through license on downloading the Java source-code. That one thing would mean that the BSD portstree or Gentoo portage could build Java from source - unsupervised. Today it's a total pain to manually download a bunch of distfiles. Even the patches can't be distributed without a click-through license. That sucks.
But then ofcourse, legal redistribution of Java binaries wouldn't hurt either...
But Open Source Java? Nah... Not really needed.
Seriously, at this late date in the game who cares anymore what Sun does? Those who care not for Freedom have already adopted Java and those who care are either using another language or are now firmly in the GCJ camp and, knowing Sun, won't leave for any bait & switch offer from Sun. I mean, raise your hand if you believe Sun's offer to "open source" Java will actually become a code dump under an OSI approved license. And the odds of it's license (and you can bet your last dollar it WILL be Yet Another License) being GPL compatible are null.
Even today's new initiative to loosen the binary license to permit distribution repackaging is being being greeted by a certain amount of scepticism just because it is Sun. Personally I'll believe it is for real (as opposed to a deal for certain select popular distros, much like the Firefox trademark bullcrap) if jpackage.org can finally ship a binary rpm.
Democrat delenda est
For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support, making it not much more OS-independent than C when it comes to open source development. The result is that any apps that are very complex at all will utterly fail to "run anywhere".
For another, there is little incentive to ship a single binary for multiple hardware platforms. The extra overhead of building a binary for another platform is negligible once you get past the OS-dependent stuff (which Java for the most part fails to solve). If you have to do extra work for each platform anyway, you're 80% of the way to doing it right....
Next, Java generally fails to result in apps that match the native OS look and feel, so Java apps tend to seem very foreign on any platform on which you run them. They don't integrate well with other apps, don't do a good job of supporting OS services, etc. This makes them far less ideal from a UI perspective than writing in C/C++. With C and C++, assuming you separate out the interface properly, it is possible to write an app in which the vast majority of code is shared across platforms, but the UI portions are per-platform. This allows much tighter platform integration for a relatively small amount of effort. You just can't do that sort of thing with Java in any practical way.
Finally, Java makes it hard to add debug functionality into your code without a performance hit. You can do this trivially in C with #ifdef code that makes the debug code fall out entirely. All you can do in Java is run-time testing, which hurts performance. The more debug code, the bigger the hit.
The bottom line is that pretty much any compiled language has great advantages over Java. Platform independence was made out to be the be all and end all of software design, but it turns out that most people would rather have software that runs well than have software that runs everywhere.
Check out my sci-fi/humor trilogy at PatriotsBooks.
you get the slow startup times associated with JIT, and slow execution due to fiddling with bytecode. Let's not forget that the only type of optimisation carried out on the bytecode is peephole optimisation, which is inadequate for the majority of I/O intensive operations. The list goes on and on.
While the following benchmarks are somewhat biased, they fairly reflect the speed of the previous generation of Sun's JVM. The latest one (5.0) improves upon this.
http://kano.net/javabench/
Java's not the perfect tool for everything, but in my experience, it's great for making server applications that need to be reliable, maintainable, and fast, in that order. This is roughly the order in which many businesses need their software to be.
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
Don't release the source code.
Or another option is to not piss off contributors by rejecting suggestions and otherwise being resistent to change. Nobody is going to bother forking if Sun remains responsive to the community.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
There is demand for a Free implementation of Java and its standard libraries. One way or another, it will happen. The question is, how is it going to happen?
One way is for Sun to keep a tight grasp on Java and not open-source their implementation. That means a from-scratch implementation has to be written.
Another way is for Sun to open-source their implementation. That way, alternative implementations don't need to be written.
The question is; which do you think will produce most divergence? A competing, from-scratch implementation, or a continuation of the existing implementation? I think it's obvious the latter is the obvious solution if Sun genuinely want to retain interoperability between implementations.
Bogtha Bogtha Bogtha
I think that the reason Java doesn't want forking is to make sure that a program one person writes will always work on all Java interpreters. Sounds familiar to Knuth's concepts about TeX. The way they achieved it was by prohibiting new derivatives from being released under the same name (see http://en.wikipedia.org/wiki/TeX#License) and those using TeX in their name must pass a rigorous test suite. The license is not GPL compatible, but perhaps Java could adopt something similar?
So Ubuntu can't package it in such a way that gcj and java reside on the same system (forget alternatives)
So Mark Shuttleworth must have been quoted before reading. Sorry Mark, Sun tried to fool you and the Free Software community!
At this time, I stopped reading the license as it's irrelevant. gcj is turning proprietary java irrelevant by the day.
A meaningful license would be a GPL and DFSG compatible Open Source license. Anything else is just jerking the community around and won't change the resistance to Java, or could cause forks.
Firstly, IBM are the good guys nowadays. They like open source, because they make their money selling integrated systems and it's nice if someone else does the donkey work.
Second, MS may be as evil as they ever were, but the whole "they'll fork Java" thing is so 1990s. Java is (a) very very solidly entrenched in its serverware and small cross platform app niche (b) a competitor to their flagship C#, so the last thing they want is draw people back to Java, of any fork or species.
Microsoft's probable response to OSS Java, would be to comb through the source code for bugs, and call a press conference to announce "one gadzillion bugs found in open source Java, more probably exist".
Not coincidentally, new Perl (version 6) has abandoned this model. They're going for "the spec is definitive" rather than "the implementation is definitive". There are already two-plus implementations of Perl 6, the most far ahead of which isn't even the official version.
should we start calling you "non-dairy" or "half and half"?
It's not offtopic, dumbass. It's orthogonal.
In other words, if you can prove that you meet the Java standards (with API support etc), you can call yourself Java and use the source code.
It's worked well enough for the C camp. Has Java been submitted as an EMCA or ANSI or ISO standard? Of course there are multiple competing compilers which I guess is what Sun wants to avoid.
This is good for the community; maybe not so much Sun. It will at least force Sun to stay on their toes; maybe by doing so they'll manage to invent a new business along they way (and disappoint Cringely).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You are delusional. Like or dislike the language, but it's had the fastest, strongest uptake of any language in the history of programming languages. It went from zero in 1994 to being almost neck-and-neck with C++ by 1998. In other words, it did in four years what C++ took nine to do, more if you amortize some of C's growth into C++'s history.
Popularity isn't everything, but don't try to say Java isn't popular. Do some searches on some job sites and see how many Java programmer jobs there are.
you get the slow startup times associated with JIT, and slow execution due to fiddling with bytecode. Let's not forget that the only type of optimisation carried out on the bytecode is peephole optimisation
Now you're just trolling. Slow startup time: sure. With the jdk 1.3, you had around an additional 700 ms. startup time penalty that you didn't have with C code; since then, it's gone down. These hundreds of milliseconds are enough to make Java a bad choice for a program like "ls" which gets run constantly, but is irrelevant for server use.
And the fact that little optimization is done on the bytecode ignores the huge amount of optimization that the hotspot compiler does; optimization that in some cases a statically optimized language like C++ cannot do.
"Microsoft's probable response to OSS Java, would be to comb through the source code for bugs, and call a press conference to announce "one gadzillion bugs found in open source Java, more probably exist"."
.net apps seems more stable.
No.
like before, M$ will be able to ship inside windows a m$ java virtual machine with limited compatibility with the real java. This alone will be a major blow in the java brand, where everyone will see applications breaking in every desktop while
On the other side you will have J++ (or whathever name they will give it) in visual studio and claim that is the same java, but will be a M$ fork designed to run with optimizations in windows machines and behavig strangely in other VM's. No one will care about this in the beginning as 90% of the desktop machines are running windows, but will split the Java community into 2, a Java for windows community and a Java cross platform community.
To make a long story short, will be the end of Java as a cross platform language/platform
The freedom to fork the Linux kernel has resulted in varieties of Linux running on all sorts of platforms, including many that that the mainstream kernel development team has absolutely no interest in.
That's the beauty of being able to fork the code -- people can use it as the basis for scratching their own itch.
The freedom to fork Linux distributions has resulted in something that most markets identify as "competition", something which the x86 desktop OS market hasn't seen in some time.
In spite of Sun's touching concerns, this can actually be a healthy situation, and usually is.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Personally, I'll probably stop at a near-future release and not go forward. I'm guessing I'm not the only one.
I expect java will fork a few times, then the forks will fork. It will quickly descend into dozens of incompatible custom builds while those who want to get work done stick with 1.5 or 2.0 or whatever sun ends with.
I imagine an official sun build going forward for a while--pulling along behind it an ever-increasing pile of hanging-on junk projects. Eventually it will lose it's steam because of the fragmentation of the user base and the requests to "Keep up" with features in these side versions until it grinds to a complete halt.
All this time, committees will be adding "Features" that sun has been holding off on. Features that might save a programmer two keystrokes or allow some trixy maneuver while sacrificing "just a little" readability (like Generics did--IMO sun is already moving too fast!).
I guess now I'll start the search for the next beautiful language that can pull itself up above the fray--above the garbage that is the syntax of Ruby, C++, VB and all these other pretenders.
I suppose that it is possible that Sun will manage to keep control over the language definition via licensing, but I'm not going to hold my breath.
It's been fun.
Anyone can use the code... Is there any reason why such an approach wouldn't work?
I'd have to toss in "can modify and redistribute." Open Source ain't Open Source if I can't let others try my dodgy hack.
Stop-Prism.org: Opt Out of Surveillance
There is no way to prevent fragmentation. Open source projects fragment when a single code base can't serve every community anymore, or when the people running the project are screwing up. That's a good thing. Giving users the freedom to fork an open source project when they choose is what open source is all about. The concept of open source without the ability to fork and fragment doesn't make sense.
Sun is right to fear fragmentation; the minute they open source Java, they will lose control. Personally, I think that's a good thing for Java. but Java zealots disagree. In any case, I stopped worrying about it. It's taken Java only 10 years for its spectacular growth, but it can disappear even more quickly than it has grown. if Java continues along its current path, it will collapse under its own weight and become irrelevant in 5-10 years.
i think this is a great idea. one of my biggest annoyances with writing java apps has been that if i ever wanted to release my programs and didn't want to make any assumptions about my users (mainly that they had any version of java already installed on their system let a lone a level of java that matched my own level) i would have to deploy a very heavy 50MB JRE with my 100K app... i think with the opening of the java source, much like in the linux world, someone will repackage the JRE and just keep the very bare-bones essentials so that instead of deploying a 50MB+100K apps i can deploy a 5MB+100k app.
--
http://unk1911.blogspot.com/
Suggesting that Microsoft wouldn't bundle a look-a-like product in their monopoly OS and then do exactly what the parent post suggests (start making small changes) makes you sound naïve. For God sakes man, they did already try it once!
Microsoft hasn't learned to play fair and not cross that good ol' antitrust line. They wouldn't think twice if they decided that they could destroy Java that way.
The race isn't always to the swift... but that's the way to bet!
Well, for one thing, it is slower than native code.
Patently false. It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks. (More recent benchmarks here.)
It's now down to the skill of the programmer. A good programmer will write speedy code, and a bad programmer will write garbage. Who'da'thunk?
For another, its garbage collection has a tendency to result in really bad performance stalls
When was the last time you used Java? 1.1? The modern hotspot JVM uses a generational collector which should NEVER stall during runtime unless it begins running into memory pressure. Go try this game and tell us how many stalls you see. If you think that's too "simple", try this one.
For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support,
Is there something wrong with the javax.sound packages? I'm REALLY thinking that you haven't tried Java since 1.1.
They don't integrate well with other apps, don't do a good job of supporting OS services, etc.
Psst!
Finally, Java makes it hard to add debug functionality into your code without a performance hit.
That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.
The bottom line is that pretty much any compiled language has great advantages over Java.
The bottom line is that you haven't used Java since the days of 1.1, but you feel that you're fully qualified to make statements about a platform you know nothing about. Whether you intend to or not, you are trolling, sir. So I would ask you to stop spreading FUD by not commenting on Java until you are again familiar with the platform.
Javascript + Nintendo DSi = DSiCade
I will finally be able to run Tomcat on my NetBSD/mac68k box without waiting for Kaffe to mature. Hooray!
Constitutionally Correct
Statement with no proof, got to love that. If you even bother googling "java vs c++", you'll see plenty of benchmarks that demonstrate pretty much speed parity at non-GUI tasks.
Hence the reason for the related JSR and Sun's implementation.
Not much to argue although the JDK is constantly expanding to incorporate new features. The trick of course comes in when you have to decide - if feature X is only available on Windows, does one include it? Generally however, this is only an issue for the desktop - a space it's been struggling in. The enterprise market doesn't tend to face this issue.
Umm... the JVM comes for a wide variety of platforms - even the ones for which Sun doesn't release the JVM, the companies developing the OS do (i.e. AIX, MacOS). And you say that Java fails to solve the OS-dependent stuff - compared to C/C++ it's far far ahead. I mean look at something like Netbeans - no OS dependent stuff (except maybe some look and feel). So you're argument is just flawed in so many ways.
When was the last time you actuall used Java. Swing's come a long way and integrates very cleanly into the OS (if done correctly). And it's also getting faster with every release.
Not quite sure what you mean there.
With Java you don't even have to do that saving on development time. Not to mention that with C/C++ you have to be familiar with the appropriate OS-specific API. With Java, there's only 1.
Define "relatively small" and what features you're adding that make integrate it better. And with Java you can do it in a more practical way - that's why there are 3-party libraries such as the Java Desktop Project
Finally, Java makes it hard to add debug functionality into your code without a performance hit.
That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.
Actually, you can use the assert facility (since Java 1.4, I believe) to achieve something similar as a pre-processor out of the box.
Specificly, about 60% down the document, the following can be read regarding removing any assertion code from the resulting class files:
Removing all Trace of Assertions from Class Files
Programmers developing applications for resource-constrained devices may wish to strip assertions out of class files entirely. While this makes it impossible to enable assertions in the field, it also reduces class file size, possibly leading to improved class loading performance. In the absence of a high quality JIT, it could lead to decreased footprint and improved runtime performance.
The assertion facility offers no direct support for stripping assertions out of class files. The assert statement may, however, be used in conjunction with the "conditional compilation" idiom described in JLS 14.20, enabling the compiler to eliminate all traces of these asserts from the class files that it generates:
I can't believe I'm about to defend java. It is sort of like shooting yourself in the foot but I really can't let this fud go on either.
... eclipse and azerus stand out off the top of my head as the best examples of COMPLEX guis that take advantage of the native os features, looks, and feel.
... audio support is not an os-specific extension. It comes as part of the standard runtime environment.
/* do code */ } is NOT any kind of performance hit at all. It is actually invaluablly more useful in enterprise grade applications where PEFORMANCE is critical because it also allows you the ability to introspectively examine the application internals.
Well, for one thing, it is slower than native code.
This myth has long since been dispelled. The java language compiled code running on a running virtual machine has actually proven to have faster startup/take down time, more efficient code executions, and oh thats right runs FASTER then compiled native code. Why you ask, simple. The virtual machine is architecturally specific and the virtual machine knows to reoptimize code at runtime to take advantage of your specific architecture. Native compiled code on the other hand are often compiled for the lowest common denominator and/or require a lot of extra work and instability in many cases when trying to optimize towards a specific architecture.
its garbage collection has a tendency to result in really bad performance stalls
More fud. There are many optimized routines used by the garbage collectors these days that it results in practically no stalls what so ever. Why do you think most of the fortune 500 companies use JAVA based webservers like WebLogic and SunOne and such. You don't think that there is a ton of garbage generated by 1000's upon 1000's of rapid connections slamming a webserver?
So it's worse than just about anything other than scripting languages in that regard.
You really should learn the difference between a scripting language and an enterprise grade industrial programming language. I'm so shocked by this comment that I am left speachless that anyone could even make such a ludicrous comment.
Java generally fails to result in apps that match the native OS look and feel
Swing yes. AWT perhaps yes and no. It does match the native OS look and feel but yes it does have a few issues. the SWT toolkit however is well undeniably native cause well it is actual native OS toolkits. Several examples you should look at
which means that there are all these OS-specific extensions to add things like audio support
Um
Java makes it hard to add debug functionality into your code without a performance hit.
Again not at all true. In fact I make use of this many times. The logging api even allows you to set debug specific configurations on a class by class level so you could have portions of the code in debug mode and at any point in time dynamically change all that WITHOUT taking a performance hit. News flash, if (logger.isDebugEnabled()) {
The bottom line is that pretty much any compiled language has great advantages over Java.
Total load of crap. Java has the 1 great advantage that it is faster, more stable, more efficient code production capability for any kind of real application. You can without a shadow of a doubt produce more code, faster, and more stable in less time with Java then you can with your other compiled languages.
A "fork" will happen no matter what. What needs to be prevented in an incompatable fork that is non-standard Java. They need to prevent others from taking over the standard. One way that has worked is the way Ada did it. There are many Ada compilers (including the Open Source gcc Ada front end) but the language spec for Ada is closely followed by everyone. What they should do is hold onto the trademark but offer to let anyone use it whos Java implementation passes a large test suit. By "large" I mean something like a 100,000 lines of Java code. Should there ever be a problem they can extend the test suite. After all the whole point of OSS it so people can change the software. The first time one guy checks it out of CVS and make an edit you have a "fork" but hopefuly these get checked back into the main brabch after so testing
Right to fork is the most important one in the open source definition. Where do these guys live??
evil is as evil does
So, after resisting for years, let's see what is happening in the GNU world to change Jonathan Schwartz mind
It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks.
Give me one example of a well known basic java gui application that is as responsive as any give kde/gnome app, takes a modest amount of memory and is bug free enough to use basic features, and I will change my opinion about java from "Memory hungry, bug ridden, slow, incompatible with itself, bloated piece of shit" to some thing maybe a point or two higher. No piece of java software I've ever run has impressed me. From proprietary java software I use at work to applets on the web, azureus, eclipse, limewire, oracle's applications, and the hundreds of apache tomcat/ant/jboss environments I used to setup and host for customers, I have never seen any java application where I've just said "Wow, that just worked.".
Those benchmarks are next to useless. I'm not saying they're wrong, I just don't see java performing better or even on par with other applications I use.
If you cannot space the cycles, simply use assertions. They do not cost anything at runtime.
Perl, Python, Ruby, and so on. All are Open Source yet not fragmented. Look at TCL, though it lacks a "dictator" like the others above, it still has not fragmented.
Me too; When did this come about; Could not do it before.
I prefer the "u" in honour as it seems to be missing these days.
It's just TOO LATE!
Look at SWT and eclipse and you'll see just how much they have accomplished without the source code.
Eclipse is OK, but SWT is now a largely discredited waste of time.
Compiling has trade-offs. You must target the end environment (CPU, OS), and also try to optimize code (for the target CPU). But you can only do static optimization.
Modern JVMs optimize on the fly. So the more you use a particular path through the code, the more it will be optimized (obviously only so far...).
Don't forget runtime optimization like that has trade-offs, namely that you have data-code confusion. Data is not code. The stack, heap, and writable shared and anonymous memory are data; when these are executed, we usually see nasty things like security holes (Code Red, Slammer, Blaster, Zytob/Mytob...). Preferred solution is to make sure the only stuff we execute came with the program-- i.e. an image and shared libraries.
Any bug in the JRE-- and we love assuming it's perfect-- can be exploited. We can't deploy proactive protections against it unless we use slower disk-based solutions-- write the generated code to a file, mmap() the file executable. From a security standpoint, we can't make "guarantees" mathematically; we can only speculate on the language's design and the hope that it is implemented properly. (By contrast, we are otherwise hoping that the program is implemented properly; and if that fails, that the OS implemented its prot properly; failing that we're finally screwed).
I really don't like runtime code generation, because it requires runtime code execution.
Support my political activism on Patreon.
Well, that is exactly what I said when I found oXygenXML.
It's a damn fine XML editor (and a bunch of other things handy for working with XML). I use it every single day in my job, which involves lots of writing, updating, validating, and transforming monstro-DocBook XML files. A couple of my teammates and I went into absolute hysterics when we found it, because it Does What We Need It To Do, does it fairly quickly and painlessly, and it does it on *nix, Windows, and OS X.
I still can't believe it's a Java app sometimes.
Il n'y a pas de Planet B.
While I make my living programming Java, I think it is a stretch to say Java performs on par with C. Perhaps good implementations in Java are better than bad implementations in ... whatever, but in the general case an interpreted language is one order of magnitude slower than a natively compiled one. For the record, XML Spy is a piece of shit, and I question whether its implmentation is even "natively compiled." Granting it is for the sake of argument, it's still a piece of shit and it's no surprise an enterprise XSLT engine written in Java outperformed it.
Check the great language shootout . I certainly don't believe these benchmarks are perfectly fair, but I do think that Java and C are well represented languages. The results speak for themselves. Java isn't even close to C in memory or runtime efficiency.
I can speak from experience that garbage collection IS a serious issue in corporate IT. Many enterprise applications that are loose with object creation can quickly create objects faster than they are collected and crash the container. This is under heavy load. Of course, a C application with a memory leak does not even have the benefit of garbage collection to save it. But C applications are generally FAR more memory efficient (just look at the shootout!). It is no secret that Java also has severe memory footprint issues (Hello 2 gb Websphere instance). In C you can malloc a chunk of memory and continually repurpose it where in Java you must continually create and throw away objects. Yes, the whole operation is optimized, but the differences are like night and day. They say Java 1.6 "Mustang" will address the footprint issues, but there is no way it will be nearly as efficient as C.
Java is many wonderful things. It is a highly productive language thanks to the best libraries and components. No other language can boast that kind of consistency and interoperability.
But do stop fooling yourself. The Sun JVM is slower than GCC compiled code. Compiler researchers have known for years there is an order of magnitude difference between native and interpreted code across the board. Don't use bogus benchmarks and ignore the fact that different language implementations have real performance characteristics to match their capabilities.
Patently false. It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks. (More recent benchmarks here.)
It is provably true. The proof is trivial, in fact. Java is non-native bytecode. Therefore, at some point in time, that bytecode must be translated. This takes time. Therefore, unless that translation generates dramatically better-optimized code than the compiler toolchain, performance is, by definition, slower, and even if the code -is- dramatically better-optimized code, for a short execution, execution will generally take longer. Now you can either take that translation hit up front or during execution. You can cache the native code so you only have to translate it once. Regardless, you still pay that penalty, which is still provably a loss of time. No amount of benchmarking can disprove that.
For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support,
Is there something wrong with the javax.sound packages? I'm REALLY thinking that you haven't tried Java since 1.1.
Audio input wasn't added until 1.3. We're only talking about five years for something I could do on an Apple II in the mid 1980s. That's a pretty basic feature which has been common in the computer world as long as I can remember. At that rate, by the time there's a way to interface with (Mac OS X) spotlight searching or (Linux) Xrender transparency in Java, I'll probably be retired.
They don't integrate well with other apps, don't do a good job of supporting OS services, etc.
Psst!
Care to elaborate on that? Even if the specific example of audio was a bit out of date, the point still remains that it is a separate development environment, which means that it is always trailing way behind the state of the art. Since few OS services are bridged except those that are fully cross-platform, a Java app cannot fully take advantage of the latest technologies in any OS. Jack of all trades, master of none.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Good point! The assert facility slipped my mind. (Not something I use often.) :-)
Javascript + Nintendo DSi = DSiCade
Sun owns the Java name right ? so people can fork the source code as they want if Sun refuses this forked "thing" to bear the Java name, then it can't be called this way, it's as simple as that. Only the Sun blessed version will be allowed to use the Java name. I don't see any risk of forking here.
Unfortunately for Sun, Java will be Open Source with or without them. GNU Classpath is already mostly Java 1.4 compliant.
They basically have a choice. They can either make the Sun JVM the defacto JVM now by complying with open source demands, or they can be the stodgy corporate-only JVM while everyone else uses GNU Classpath. Even by fixing the Sun JVM license the people working on GNU Classpath aren't going to stop. They want a GNU, true open source alternative. Do we need any reminder on how the UNIX / Linux battle played out?
So like the Sun execs have said, it is not whether the JVM will be open source. It is HOW it will be. Will it be Sun or GNU Classpath in 5 years? Clearly, Sun realized this and is scrambling to make it happen before it is too late and a thriving community leaves them in the dust like with Solaris v Linux.
Azureus. http://azureus.sf.net/link
If patriotism is racist, is racism patriotic?
JAVA source code has been freely avaible for many years now. If that wasn't that case, you wouldn't be able to for example, build the native FreeBSD JDK...
"It is provably true. The proof is trivial, in fact. Java is non-native bytecode. Therefore, at some point in time, that bytecode must be translated. This takes time."
That may be, but if you acquire information while the code is running, then you may be able to speed things up a bit. Normally, natively compiled code does not do that. Besides that, this is all theoratically speaking. The same argument was used against C: anything you did should be slower than assembly, no? It turned out that compilers won from assembly most of the time: computers are much better in following guidelines and testing for optimum performance than users are.
Besides that, I would not mind spending a bit of time for added reliability and security on 90% of my applications.
"Since few OS services are bridged except those that are fully cross-platform, a Java app cannot fully take advantage of the latest technologies in any OS."
That depends. Some things are enabled automatically. But one of the main points is write-once, run-anywhere. Sure, you can get out of that using JNI, but you may have to rewrite certain bits. On the other hand, how do you know that an application that you write runs smoothly on another machine if you used C++? What if it is an older machine?
In my opinion, the main advantages of Java are the simplicity of the language, the well-documented and largely very understandable API, the availability of a very large repository of usefull components (check out Apache!), the inherent security architecture...the list goes on. Even if you were 100% right on the previous two points, there is enough merit in Java to take it seriously. And if you look at the penetration rate of Java, well, it's HUGE. Mobile phones, smart cards, TIVO's, blu-ray will use Java, embedded devices and of course many businesses that take security and reliability seriously.
Even better: The Eclipse plugin for OxygenXML ... :-)
As far as IBM goes they still own a lions share of the server market and could easily fork J2EE. That would also suck.
Why? IBM is committed to open computing and standards. IBM will/do drive standards, but as for forking - that would hinder the IBM strategy.
You want a signature? You can't handle a signature!!
It is provably true. The proof is trivial, in fact. Java is non-native bytecode.
Ok, sounds good so far...
Therefore, at some point in time, that bytecode must be translated. This takes time.
Uh huh, uh huh... Sounds reasonable
Therefore, unless that translation generates dramatically better-optimized code than the compiler toolchain, performance is, by definition, slower, and even if the code -is- dramatically better-optimized code, for a short execution, execution will generally take longer.
This is a true argument. For short programs, startup time is a factor with the Java Virtual Machine. However, you also need to mention that, if your program's that short, does it really make a difference if it takes .01 or .21 seconds to complete?
Furthermore, you seem to have completely written off the fact that the code is not going to have better optimizations than the machine code produced by a C compiler. Java actually has the advantage here, because some optimizations cannot be performed statically (as a C compiler would have to do).
Now you can either take that translation hit up front or during execution. You can cache the native code so you only have to translate it once. Regardless, you still pay that penalty, which is still provably a loss of time. No amount of benchmarking can disprove that.
Sorry, but it's not Q.E.D. Besides, if a fair benchmark is showing Java as faster... Wouldn't you want to question your interpretation, instead of holding your fingers in your ears and repeating "My theory says Java can't be faster!"?
There have been very few problems with the JVM so far. The good thing is that the JVM is a very small target to hit, and it's pretty easy to test it and make sure it works correctly. Everything that runs inside the Java JVM, including all libraries that do not directly call native code, is bounds checked. Many of the examples you have pointed out would never have worked inside a Java VM, where buffer overruns are *very* unlikely. I believe up till now one has been found.
The VM does make a very clear distinction between data and code. If you want to create code, you will have to pass the byte verifier. And if that is using a security scheme for e.g. applets, you cannot even write to disk. Maybe the underlying system cannot see that it is data or code, but who cares? Of course any bug in the JRE (that is visible to a Java program, pretty unlikely) can be exploited. But the JRE has proven to be a very stable environment. Much more so than any other runtime environment I've encountered so far.
You are also trying to make a distinction between native code environment and the Java environment. There really isn't too much difference. But while normal, native, platforms are horrendously complex, use pointer arithmetic, huge numbers of instructions etc. etc. Java runs in a pretty well understood and much less complex environment, where most of the risks of a native platform have been rooted out. All in all, Java is pretty well suited for security and stability.
If you don't like runtime code execution, I would advise you to stay as far away from your computer as possible.
I can't keep track of the dates of each benchmark being run at the kano.net site, but you should visit: http://www.freewebs.com/godaves/javabench_revisite d/. They say some of the Java benchmarks are flawed, and once they are made more fair to C++ (i.e., not being unfair in major ways), then C++ does much better. As in, C++ almost always beats Java.
Benchmarking is easy to do wrong, and if you're getting unusual results, you may want to look into it closely.
The "problem", if you will, is that no distribution comes with a Sun standard JVM. Why? Not allowed to distribute it. Licensing issues.
... they would be HAPPY to build, maintain, and bundle JVMs and JREs for Sun for all their supported platforms and have it installed by default.
That is unacceptable. If Sun can just change the license a little then Red Hat, Novell, FreeBSD ports
Instead we have to do stupid shit like the jpackage-sun-jre SRPM which essentially downloads a file from the Sun website, makes you look at a EULA, expands it, and repackages it as a binary RPM. Utter useless horseshit. Projects like blackdown java and jpackage (which exist primarily as technological measures to circumvent/handle issues due to Sun's licensing) are proof that there's something wrong with the One True Release model that Sun has been pushing.
The ramblings of a few OSS advocates who have never coded a bit of java in their lives is not the issue here. That's just noise that distracts from the real issues.
In fact, the only reason why they rant is because they look at their Fedora box and say: "Hey, where's the java package?" They go on the forum and ask, "WTF?". The response they get back is "Lol Sun suxors java isn't open sauce looool". Which isn't really true, its just Sun is being assisine about groups like Fedora distributing it.
It's everyone else who hates having to jump through hoops to standardize on java on whatever platform they want to play with who are complaining. Sun is finally listening to them. Hopefully someday soon my RHEL 5.0 extras CD will come with official Sun RPMS and SRPMS for all my platforms. One can dream.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Have a look at Rick Moen's essay Fear of forking to see in more detail what causes successful forking.
Sure they can - there are other ways to pevent forking than in the license. Look at most of the major OSS projects around and you'll see that there is very little in the way of forking - sure minor forks exist but they quickly die.
Ultimately, the only way to prevent forking is to do such a good job at managing the project and on the technical side that few people will want to use a fork.
I don't think that Sun is up to that standard, and it's pretty clear that Sun themselves doesn't think that, otherwise they wouldn't be so worried about forking.
Sun's press release
Offical Sun JDK Distros Project
Like a lot of people are already saying, you've been able to get the JDK source code for a long time now. The goal here is to fix the things that keep most Linux distro from including a JRE/JDK.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Microsoft says "Great Sun open sourced Java". We will take it bundle it with windows, change all the underlying code so that it actually uses windows API's, remove anything that competes against our stuff like SWING, EJB's, Servlets, messaging API's et al, and make it so that our Java only runs on Windows, and even if you try to run a "normal" Java application , it will not work unless you change it to support com.microsoft.xxx libraries, and jump through a ton of hoops.
.NET. It's an open standard and there are open source implementations. It provides excellent desktop integration on Windows and Linux. It gives you a choice of native toolkits or cross platform toolkits. It's technically superior to Java and the implementations are better than Sun Java. Recent Linux distributions include a dozen or so Mono applications as part of the Gnome desktop, and they work so well that most people won't even know it. Even Gnome's desktop search is based on it. And both Microsoft and Mono provide backwards compatibility with Java (you can even run Eclipse on top of Mono).
The already did this. It's called
By giving the finger to both Microsoft and the open source world, Sun really screwed themselves.
The fact that Sun has made it easy to obtain Java source code under license by merely clicking through is a trap; it lulls people into the belief that they can download the source code without consequences. It is cynical and deceptive to say that the source code is available without being clear how seriously encumbered it is. Windows source code is available under restrictive licenses as well, but frankly, I consider the fact that you have to do more than click through a license a bit more honest than what Sun is doing.
Let me say it again: do not donwload Sun's Java source code unless you are absolutely clear of what the legal implications are. Sun is serious about their licenses and they have enforced them in the past when it suited them. Neither the JRL nor the SCSL are open source licenses and violate many of the implicit assumptions you may make about downloadable source code. In addition, keep in mind that significant aspects of the Java platform are patented by Sun, so that it's not clear that merely having source code, even if you could use it, would help you.
Well, we could always contribute them. But hopefully now they'll actually get applied.
Eclipse is OK, but SWT is now a largely discredited waste of time.
That would be true if Swing didn't look like shit. And no, Mustang isn't out yet.
I'm confident, it is only the Sun's restrictive licensing, that prevented them from bundling Java as well. Not any more...
Of course, you will still be able to use the already installed Java using the --with-system-java switch, but it will subtly break various things, because the OO.o's automated builds would never use it themselves.
In Soviet Washington the swamp drains you.
The java community is many orders of magnitudes bigger than that of any other product. Also the members of the community themselves are, next to individual developers, the largest software companies in the world. Sun could never be 'responsive' to this community in general, since a lot of its members have conflicts of interest and widely different opinions. I think Sun does quite a good job of reconciliating these interests. But still, forking, when so much money is at stake, remains a very big risk and cannot be prevented by being responsive.
Considering JRockit compiles all code into machine code before running it, that's a non-argument.
Everybody knows that going by car is faster than walking. That doesn't imply that some car is necessarily faster than some other.
Likewise, everybody knows that native code is faster than interpreted. That doesn't mean that gcc's native code is necessarily faster than JRockit's. Yet, that's the argument you're making above if I understand you correctly.
Installed the Bubblemon yet?
By no means it is worse having .NET competition than the effective overtaking of Java under Windows by MS, then an induced crackdown in compatibility among platforms.
.NET goes where MS wants it to go, and it's an understatement Windows is the preferred platform and support for the rest relies partly in "volunteers" in the long term. I wouldn't lock myself into .NET at any cost.
Java still has the upper hand, by a long shot. Every same individual knows
If preventing forks (as in forks made by proprietory interests), then GPL is the way to go. The GPL makes it stupid for anybody to make a fork unless they think that the present leadership is not doing its job properly. So Microsoft or IBM will not make a fork because it will be better to just contribute to the base. Proprietory forks are disallowed by GPL and OSS forks cannot survive because there is an inherent bias in merging the forks, because it improves the code base faster. As past has shown us before (GCC fork, X11 fork), they only happen when the current leadership is not working well. These kinds of fork are a good thing.
BTW no non-viral license can do the job of preventing forks effectively, and that includes BSD and others. Not to flame BSD users but BSD license is great in instances where you want a particular protocol to be used everywhere including proprietory implementation. I would think it would be good if there is an ODF implementation in BSD License then everybody except MS would use it. And we will have a similarly working ODF readers. BSD TCP/IP stack is a reason why TCP/IP is so popular. But preventing forks is not one of its features.
Does your linux distribution come with Sun's Java? No? Well once Java is open-sourced, it will.
Java out of the box, that's a big change.
Java is just too far behind. It's the new COBOL.
Hey, quit insulting COBOL! COBOL is lean & mean compared to that bloated Virtual Machine. While the OOPs paradigm is useful for GUI interfaces, it can cripple data access. BTW, have the Java GUIs stopped sucking yet?
need a free COBOL editor for Windows?
How nice to read your post the same day we decided to use a native lib for image manipulation, effects and display for one of our apps! because Java's libs were VERY SLOW...
Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks.
lets take a look at his results then.
in the non infinite life ones the best C result beats the best java result every time.
In the infinite life one C does a lot worse.
In the fibonachi numbers test java clearly wins.
In the fft test the results are all over the place.
So the answer is for tight number crunching work java and C are comparable. For retarded use of reccursion (the fibbonachi test) java clearly wins.
For memory allocation java is by default better than C (especially GCC) BUT a good coder has far more chance to optimise in C. I bet if "set = (int*)malloc(4*sizeof(int));" was replaced by a custom cache of fixed size blocks things would speed up big time. In java every object gets its own block on the heap and theres nothing you can do about it. It gets even worse if you wan't an array of structures (i didn't notice any of theese in his tests) as java forces you to put every element of the array in a seperate block on the heap.
He also didn't make much use of the standard libraries many of which suck, though they are admittedly getting better nowadays. There are also a lot of gotchas from the way the JVM optimises (for example the performance of direct bytebuffers will plummet if non direct bytebuffers are used in the same VM).
So to summerise: In terms of actual execution of code its a toss up, In terms of memory allocation it depends if the coder can be bothered to optimise. In terms of standard libraries its pretty damn poor and in terms of startup time its barely acceptable especially the first time you start a java app after boot. I'd say java loses in the overall performace stakes even though its certainly possible to make benchmarks that it wins.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I wouldn't consider your average Java developer to be part of the Java community (as far as the source code for the VM and compiler is concerned). The vast majority of Java developers don't give a crap about the source code to the JDK. To say that all Java developers are part of the JDK community is like saying all open source C programmers are part of the gcc community.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
The company is asking developers to provide feedback on how to best get there and prevent forking and fragmentation.
Well essentially, they want to stay in business - and don't want to give away code for free to competitiors. What if IBM/MS/any_other_company takes their code, repackages it and calls it "Their-Own-Kawa(TM)"? Their lead in the business as the premier Java would be lost.
I think they're thinking at it, purely from a business point of view. And it wouldn't help if the Chinese get a whiff of it (no offence intended).
yeah theres been some more tweaking but overall the same problems still persist. In mustang for example they are planning to "fix" the bytebuffer issue by adding special optimisations for bimorphic classes. but afaict it will still slow to a crawl if unrelated code decides to create its own bytebuffer descendents.
Once code is written i don't expect changing another part of the app to radically effect its performance like that.
And to take one of the articles examples why isn't the vector class marked as deprecated so people know its a performance killer?
Also the pointers issue is way overblown. An array will never point to anything other than the array so thats a non-issue from an optimisers point of view and a pointer can only (legitimately) modify a local variable if a pointer has been taken from that local variable (this is an issue with reference perameters but then java forces you to use objects for those which isn't the pinnicle of efficiancy either).
Java can perform as well as or even better than C provided:
1: The app is fairly long running and/or something else on the system has already brought the VM into disk cache.
2: The C app follows the same stupid design patterns (such as overuse of the allocator) that java forces you into (this is one big issue with comparative benchmarks, the C code seems to have been written by someone who either wasn't bothering about performance or was trying to make the code as close to the java version as possible).
3: The C app doesn't use inline assembler for critical sections or the inline assembler is done badly.
4: The Java app either avoids the standard libraries completely in anything remotely critical or uses only those bits that were written by someone with a clue about performance.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Yeah, you're right. I wasn't comparing languages. I was thinking of the perception in corporations.
"Piter, too, is dead."
Get ready for the fragmentations! Here comes FreeJava, NetJava, OpenJava, JavaOne, FreeJavaOne, NetJavaOne, OpenJavaOne.. JavaFree, JavaOpen, JavaOpenFree, JavaFreeOpen..
Java is fighting a rear-guard action. The language is 10 years old.
.NET. Go with Python. It has features that .NET doesn't support yet.
.NET and Mono are persuasive: between IronPython and Boo, it is a great and productive programming environment that, unlike either Java or Python, covers everything from low-level systems programming, to application programming, numerical programming, and scripting.
Actually, except for the new-fangled C-like syntax, the language is really more than 30 years old.
Forget
Python is a lovely and productive scripting language, and I think it's great for many of the things people use Java for. But nice as it is, some features (e.g., the use of hash tables to represent objects) just aren't heavy-duty enough for me. Overall, when it comes to dynamic languages, I think Smalltalk is still the overall best design, 25 years after its creation.
However,
Don't release the source code.
We've already got Sun java, MS java, IBM java, Apache java, and GNU java -- most of them created because of sun's restrictive licensing.
Compare similarly sized open source projects -- the linux kernel, the mozilla suite, openoffice, X, etc. All those put together have had fewer forks and fragments than java, and in all cases it wasn't so much a fork as a new path, leaving the old to die, returning us to the state of a single good branch.
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment