Slashdot Mirror
James Gosling on Java
prostoalex writes "It's been ten years since the official introduction of Java - a programming language combined with virtual machine and a class library. ZDNet published an interview with James Gosling, the creator of Java, who talks about the project's past, present and future."
If anyone is interested in conversing with James Gosling one-on-one, he (amazingly) hangs out at DevShed.com in the forums, likes to aswer questions, and my guess is he knows what he's talking about when it comes to Java. Even more amazing is that as smart a guy as he is, his social skills leave a lot to be desired (read some of his posts in the Lounge).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Why the hell did the interviewer decide to turn it into a "how did/does/will Java work with MS technologies" diatribe?
I mean, theyre so disparate in ideaology, while I can understand some of the relationships, why on earth bring them up with the creator of a language that MS has deliberately shunned when they couldnt get it to work "their way"?
Very puzzling. Poor journalism in my opinion.
...both interiorlly, and exteriorlly.
Also, why does Sun waste all the effort on NetBeans? I'm sure it's a very capable IDE, but isn't nearly everyone else using Eclipse? Where would Java or Eclipse be if Sun put all the engineering time from NetBeans into a more useful project? I guess here I don't see the value of the competition as much...
Agile Artisans
> (Sun CEO) McNealy: We absolutely underhyped [Java].
Uh, Scott; that's not the way the rest of us remember it.
Yep, it's been 10 years since Java was officially introduced. It should come as no surprise that I was being turned down for jobs 2 years ago because the jobs in question required 10 years of Java experience. (And 5 years of C#/.NET experience as well. And I think at least one required post-doctoral work in Physics, Astrology, and Film.)
FYi, parent is trolling. There's no such quote in the article.
1. Kudos to the Groovy authors. They've even garnered James Gosling's attention. If you write Java code and consider yourself even a little bit of a forward thinker, look up Groovy. It's a very important JSR (JSR-241 specifically).
2. He talks about Javascript solely from the point of view of the browser. Yes, I agree that Javascript is predominently implemented in a browser, but it's reach can be felt everywhere. Javascript == ActionScript (Flash scripting language). Javascript == CFScript (ColdFusion scripting language). Javascript object notation == Python object notation.
But what about Javascript and Rhino's inclusion in Java 6? I've been using Rhino as a server side language for a while now because Struts is way too verbose for my taste. I just want a thin glue layer between the web interface and my java components. I'm sick and tired of endless xml configuration (that means you, too, EJB!). A Rhino script on the server (with embedded Request, Response, Application, and Session objects) is the perfect glue that does not need xml configuration. (See also Groovy's Groovlets for a thin glue layer).
3. Javascript has been called Lisp in C's clothing. Javascript (via Rhino) will be included in Java 6. I also read that Java 6 will allow access to the parse trees created by the javac compiler (same link as Java 6 above).
Java is now Lisp? Paul Graham writes about 9 features that made Lisp unique when it debuted in the 50s. Access to the parse trees is one of the most advanced features of Lisp. He argues that when a language has all 9 features (and Java today is at about #5), you've not created a new language but a dialect of Lisp.
I am a Very Big Fan of dynamic languages that can flex like a pretzel to fit my problem domain. Is Java evolving to be that pretzel?
Netbeans is so cool. It has completely shed its molassas past, and is now an example of what can be great about Swing applications.
FYI, grandparent should have been modded informative and parent modded funny.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
"I knew it was slow, but I figured computer power would eventually catch-up and run things at a reasonable speed. It appears I was wrong."
On the 10th anniversary of Java - a joke that was out of date 5 years ago. (And, I remember the same thing being said about C++ 20 years ago).
Psssst.... "James", not "Josh".
tard.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
From TFA:
This is nit-picking, I know, but I was under the impression that scripting languages were actually defined by the presence of an actively-running interpreter during execution, making it possible to, e.g., construct and execute statements at runtime with things like PHP's exec() or Lua's do(file|string) functions (see: http://www.lua.org/pil/8.html for discussion on dofile and Lua's status as a scripting language). I wasn't aware that capability for rapid prototyping or language speed had anything to do with it.
Taking that into consideration, then, would Java with JIT qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts?
That aside, a solid interview. Java looks to be pretty interesting; though in its current form it does bug the hell out of me (System.out.println()? Yeah, yeah, OO, but come on, three nested levels of scope just to get to a command line?), its progress has been impressive, and it's an innovative idea.
Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment.
As Java is now used in real-time control applications, that is certainly avoidable.
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
Not really. Java can be installed as a single rpm or tgz. Its over 10 mb, but given the size of a CD-ROM, or broadband download speeds, that is hardly a 'huge undertaking'.
and who would seriously wan't to release thier software as java bytecode when jad is arround?
There are plenty of bytecode obfuscators around.
He might forget stuff just like anyone else.
His java books are probably being used as doorstops.
Jython has been stable for years now, and is a much better-designed language than groovy appears likely to become. Where'sthe love?
It's been ten years since the official introduction of Java
And the damn thing still hasn't finished loading.
So in 15 years Java will be fast? w00t!
Nobody writes Java with Vim or even Emacs JDE for very long. The productivity increase a real IDE like Eclipse provides is phenomenal. System.out.println is 6 or so characters of typing with code completion. (But the real win is being able to do things like say "show me all the places my constructor is invoked." Text searching isn't good enough when you have a million-line project.)
So you're executing script in a JVM?
Gosling: Yeah. All the Java libraries are available to things written in Groovy. And Java applications can use Groovy. They can incorporate Groovy scriptlets.
Scriptable Java! Why wasn't I informed?!? 0__0
Does anybody have any practical experience/advice using Groovy in a production environment?
>>the fact that languages like java allow poor coders to produce code that kind of works rather than total failures probablly doesn't help the languages reputation either.>> As opposed to C++, which really separates the men from the boys when it fails totally transparently due to a pointer error several years after the product has shipped, resulting in 100,000 boxes getting owned. Good thing seg faults have long since chased all of the non-serious developers away from the language, so we have only our l33t hackers creating buffer overruns for our other l33t hackers to patch. >>and who would seriously wan't to release thier software as java bytecode when jad is arround?[sic]>> I'd imagine anyone who is big enough on open software to winge about not having a free-as-in-speech runtime environment (despite having free-as-in-beer ones readily available) wouldn't be too worried about the possibility of someone seeing, gasp, their source code.
Help poke pirates in the eyepatch, arr.
If you're a typical corporate CTO, you know that you will have no shortage of either Java or .NET developers for the next 10 years or so, which means those are going to be the most important candidates for just about any project you're considering.
Yes, Java is slower to run than C++. However Java is faster to write than C++; and I think that's the real issue.
In terms of power of expressivity, I think they're about the same, but I find Java easier to read than C++, and I find that mid-level programmers make far fewer subtle "shoot yourself in the foot" mistakes in Java than they do in C++. The run-time array bounds checking, lack of pointers, checked exceptions, and the lovely NullPointerException serve to keep a lot of people out of trouble. The embarrassing wealth of pre-written, tested, free, source-available modules Java has, over the reinvent-the-wheel approach of C++ goes a long way in improved programmer productivity. Here's a test for you: have one of your middle-skilled programmers do some network communication in Java and C++ and see which program takes less time to write and works better.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
So in 15 years Java will be fast? w00t!
You seem to have either misunderstood the term 'out of date', or have got your sense of time mixed up after reading the earlier '100 Years of Special Relativity' topic.
More likely driven by competition against MS.
.net "framework", their IDE and tools, their database, their webserver, their OS, etc. etc. and managers say you can't go wrong with that.
.net stuff seems less because something like JEE (J2EE) has a lot of little bits that are highly more configurable than in the MS world.
MS is a one stop shop. You get their
On the other hand, the complexity of some of the
I'm sure that's it because that's the type of feedback they've received from a lot of big companies (including the one I work in) and they are trying to make things easier.
That's why they have been working some much on Netbeans and EJB 3.0.
- sigs are for wimps.
Don't worry. Binary XML will soak up far more compute cycles that CPU developers can possibly invent over the next 10 years.
Why does this poor excuse for an interview get on slashdot, when my submitted story on Java Penis Pumps got rejected?
Maybe its the competetion from C#/ Open java (jcg), or the fact that the java programmers seem to be listening to developers http://www.java.net/ . Or maybe its eclipse which is a great ide. It seems java development is picking up steam of late. More people I know are now doing java than c , and thats a good change (&*&*&**&&*&!!!).
Uh, are you serious?
Yes.
You're proably stretching the meaning of the word "real time". Components are probably written in Java, but the interrupt control or tight loop governing the "real time" aspects are probably written in another language.
Nice try, though.
A flippant and ignorant attempt to rubbish Java.
Why not do some actual research before posting?
Java has been used in embedded and real-time control systems for years.
Oh, if only 1/16 of the people here got that joke.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
There is a slight problem with your logic. 20 years ago C++ was barely a toddler. Nobody used it and it was not generally known to the public.
Nonsense. I was using C++ for development in 1985, as were many others. The c-front translator for C to C++ was released in 1983.
Since when has widespread use of a language been any measure of its performance?
Java on the other hand is 14 years old and people are still talking about its slowness.
Yes, because those who object to it not being open-source have a political agenda to rubbish it. Those of us who actually use it realise this talk is meaningless.
C++ was 14 around 1997 and was widely used and known for its high performance.
Doesn't that say something to you?
Yes, it shows that a lot of developers have a reactionary attitude, and it takes them a long time to adopt new technologies.
It took a long time before developers realised that this 'new-fangled' object oriented C++ could match the speed of C. Meanwhile, some of us had been using it for years.
C++ was 14 around 1997 and was widely used and known for its high performance.
That's not how I remember it. I remember in 1996-1997 people were scoffing at C++ because it was "slower than C".
My bad, I was thinking you said that joke was starting to be told 5 years ago, not out of date at that point. Anyway, smite me oh mighty smiter for such a lame attempt at a joke.
It doesn't have to be that way, but it's not the holy grail that Sun made it out to be, either.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Most of my experiences with Java is that programs either barf runtime exceptions like crazy or exceptions get silently caught and not handled at all.
Think of the horror of C or C++ programs that had the same bugs but did not throw the exceptions. (I remember developing with C++ in the 80s on MSDOS, and in place of runtime exceptions we got random graphics on the screen, or software jams). Give me Java any day.
There are other attacks, but most of the "exploits" are due to a buffer overflow (90% of all exploits? 95%?). Heck, if I'm am not mistaken it was a buffer overflow that put an end to the "x years without a hole in the default OpenBSD install" slogan :(
Now how many buffer overflow did happen in the JVM in the last 10 years?
I think the answer is zero. And if it's not zero, it's only some implementation of the JVM that was at fault.
For me it's all about the sandbox. Java, Jython, Groovy, you-name-it... I don't care. As long as it targets the JVM. It's tried, lean, mean, rock solid technology. You just ain't escaping it.
In TFA (yup, I did read it), Gosling says that "The only serious divide is they (C# / .Net) have this unsafe mode which they use a lot. One of the principles I believe in is there shouldn't be an unsafe mode."
That's a good principle to believe in.
The fact that he/she is posting as AC is reason enough to know it's Java bashing for the sake of Java bashing.
I was quoted out of context in my autobiography...
Do you have any sources to back up your assertions? I know very little about real-time java, but a quick google search turns up articles like this one (dated 2 days ago), which suggest that Java's real time support is fairly immature.
Don't you hate meta-sigs?
Bullshit! Eclipse does more than Visual Studio and is takes no longer to do anything.
What a complete and utter lie.
How long were /. types calling OpenSolaris vaporware? :P You of all people should know that lack of public release does not equate lack of progress.
At least with Jython you can check the cvs log and see that commits are indeed happening.
Eclipse has 2,425,709 lines of Java code and runs on any J2SE 1.4 (or newer) compliant JRE from any vendor on many platforms (the essential parts of it will run even on PDAs). I don't think any scripting language would have been up to this task.
My opinion is that Java is the best thing that could have possibly happened in the software development field in the last 20 years. The fact that it is an openly specified object-oriented runtime suitable for a *huge* variety of configurations (desktop, middleware, embedded, etc) is a blessing. Developers have been able to learn one language and develop any kind of applications on any platforms (while reusing many of the skills). Also, vendors can target a much wider market when they do not have to focus on a single platform. Not mentioning that Linux owes a lot of its success to Java.
slow: slow to start definately, slow in actual code speed no. Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment
Sure its slow to start because ther is a 2nd process. But Java 1.5 addresses this to some degree. As for inconvient GC cycles, that is the programmers fault. You have to do your own GC when you think you have time. The JVM will only GC when its full...
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
False.
NOT FREE: well there are free jvms but there is still catching up to do and as they get better they will undoubtablly suffer the same issue as wine, most stuff will work but there will be slight differences that fuck over some apps.
You mean like Microsoft tried?
the fact that languages like java allow poor coders to produce code that kind of works rather than total failures probablly doesn't help the languages reputation either.
Troll.
Unfortunately, it's like trying to run C++ programs through an interpreter on a machine at 3/4 of the power of the one you're using instead of actually compiling and tweaking it for maximum speed and efficiency.
If you ran some actual benchmarks (with modern Java) you will find you are mistaken. Modern Java VMs include an optimiser that tweaks the machine code for speed and efficiency just as you describe. Last year, a set of benchmarks for numerical computation showed Java within 4-5% of optimised C code.
I use Java apps at work and they are often slow and ponderous compared to similar apps written the normal way in C++
The reason for this is usually that some organisations are very slow at upgrading their Java. Java 1.5 was released last year and is generally acknowledged to be fast, both in terms of general performance and GUI speed. Many companies are still using Java 1.3, which is very old.
I can write java software that has a GUI, networking, database connectivity and port it between different OS's with ease. I know this because I have done it with several products.
Your post is FUD.
Everytime java is discussed on slashdot, I'm amazed at how some junior leaguers try to dismiss it because they can point out one application where java is a poor choice.
There are some applications where it does not make sense to implement in java. However, I say that java is a great choice for the top layer of a web application server stack. There are a lot of web apps that take the form of:
1. Gather data from one or more databases.
2. Perform some consolidation and express the output in html.
In this example, java is a consolidator of data from disparate data sources. It needs to hang on to several network connections and do some simple IO but it does not need to burn the CPU at 100% because it spends most of it's time blocked on IO. Java is a great choice for applications like this because there is a very large and active community working to make java dynamic web serving better and better. Every year your organization can, for free, upgrade to a new version of java and simple app server like Tomcat and reap the rewards of the communities improvements. Also, in my experience with server applications, the promise of portability is real. I've ported from windows to solaris and then to linux without changing the java application.
Java's catching up on the type safety, but I swear that the language should forbid empty catch blocks. At least force the programmer to output something FFS!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
1983 is nothing -- a pretty good C to C++ translator has been included with every Unix since the 70's. They call it "cat".
I don't care if it's 90,000 hectares. That lake was not my doing.
The "barfing runtime exceptions" was exactly my point. It's not only a red flag for badly written code, it's a built-in QC test. I'm TIRED of reading other people's code and having to go back to them and say "O.K., this (really arcane thing that you never will understand) might/probably will happen, and so therefore I can't put you code into production". All them "barfed runtime exceptions" make my argument for me. I can simply fiat "no unhandled exceptions" and leave it at that.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Hell, in 2005 people still scoff at C++ for being "bloated" or "slow", just like people scoff at Java for being "slow".
In reality, C++ is often faster than C, and Java is plenty capable of handling 90% or more of what until recently has been C's exclusive purview.
That said, I still prefer LISP.
"Java on the other hand is 14 years old and people are still talking about its slowness.
C++ was 14 around 1997 and was widely used and known for its high performance.
Doesn't that say something to you?"
Yes, it says that there are plenty of ill informed bigots out there who say such things because they just dont like Java.
In terms of power of expressivity, I think they're about the same, but I find Java easier to read than C++
Sure, new Matrix(A.negate().multipliedBy(C)).addedTo(D) is so much clearer than -A*C + B...
My website
The better IDEs will at least bitch about this, if you tell them to, but I agree with you in principle. I like checked exceptions, and I think it's one of C#'s biggest failings. I know this puts me in the minority. I don't care.
From your parent: > ......"Give me Java any day."
Yeah. I think it's today's best "Old Man's Language". For those of us old enough to have "been there, done that, got the T-shirt", I think Java is the best for keeping the Too Clever Kids (and yes, of course I was one, too) out of trouble.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Java is very important in the research community. I have been a grad student for past 3-4-5 yrs (..have lost count by now :) but I have never used any language other than Java for my projects/experiments . Be it simulation requiring a Knowledgebase of million RDF triples or be it a Medical Imaging Software to be used by Physicians.. it does it all.
Somehow 'application researchers' like me are fascinated by the extent of its use.. (drawing nice GUIs or plotting graph with existing Jars)
With regards to question of scaling..lately companies like IBM have been working towards creating optimized JIT compilers for Java.. I had benchmarked one during my internship at IBM Research.. and it gave nearly similar performance to native C/C++ apps.
I don't think so. Sun mistakenly named the exception NullPointerException instead of NullReferenceException (which MS corrected in .NET).
Java uses references -- not pointers. Hell, even the implementation of references in some VMs is handle rather than pointer based.
As I was searching for some info about JBuilder, I stumbled across this juicy bit that I had not seen before.
a d_id=34246
Borland announces JBuilder Roadmap; future will be Eclipse-based
The jist of the story is that in the first half of 2006, JBuilder will ship a new version, code-named "Peloton", which will be completely Eclipse-based !!!
http://www.theserverside.com/news/thread.tss?thre
below is much of the article text in case it gets swamped.
Borland has announced their technical roadmap for JBuilder. Later this year Borland will ship JBuilder 2006 which will add shared code and shared debugging features. In the first half of 2006, JBuilder will ship a new version, code-named "Peloton", which will be completely Eclipse-based and add better dependency analysis features.
The shared code and debugging will allow developers in different locations to participate in shared coding and debugging, as though they were sitting down together in the same room.
The Eclipse news follows up from their February announcement of joining the Eclipse board and their intention to re-build their entire application life cycle management product suite on top of Eclipse. Borland sees Eclipse as an integration framework upon which they will be building JBuilder as well as their other products. By leveraging Eclipse, they can realize the cost savings of not having to worry about maintaining IDE functionality, and integration with other Borland tools, as well as gaining a larger audiece via Eclipse and benefitting from the large ecosystem of Eclipse tools.
According to Rob Cheng, director of developer solutions at Borland, the major new addition planned for Peloton will be a dependency analysis feature. It will be able to understand the dependencies between different artifacts in the project, such as the link between JSP's and struts controllers, EJB's and the persistence tier, without the user needing to configure these explicitly or switch views. Debugging will be improved - stepping into different tiers will be easier without end users needing to manually set additional breakpoints.
Code-name Peloton comes from a cycling metaphor, which is used to describe a group of cyclists who can ride faster together than they could individually, reflecting Borland's emphasis on team collabortation features in JBuilder.
Borland has not announced any pricing information, but they are looking into offering a separate 'distribution' of JBuilder on Eclipse all integrated to make it easy for corporate clients to deploy.
Borland chose Eclipse over Netbeans after watching industry momentum and listening to customers who think Eclipse will be their next major platform.
When asked about what their differentiators for JBuilder-Eclipse over Websphere Studio will be, Borland responded that WS Studio is focused on Websphere, whereas JBuilder supports multiple application server platforms.
Luis De La Rosa in his 2005 predictions suggested that Eclipse will become the Java community's answer to Visual Studio.NET, as a de facto IDE; this being a good thing for the Java community, as Eclipse will help build a market/ecosystem for development tools much like Visual Basic, which is the real goal that Sun wants to reach: 10 million developers using Java.
Borland's decision to join IBM in basing their IDE on Eclipse is certainly bringing us closer to that prediction! What do you think?
where do you get those numbers?
/ ide_marketshare.html
A quick search I did came up with very different numbers.
Eclipse - 45%
JBuilder - 16%
IDEA IntelliJ - 10%
netbeans was well below, at around 6-8%, hard to tell from the graph.
all others combined (including netbeans) make up less than 30%
In the light of the recent news that JBuilder is merging code with eclipse, I think netbeans is quite doomed !
here is the survey:
http://www.qa-systems.com/products/qstudioforjava
Free-as-in-beer for Mac OS X, Windows, and Linux. Some of us like to have long uptimes. Once Sun sanctions and offers for download on its web site JVMs for FreeBSD, OpenBSD, and NetBSD, THEN you can claim they're "readily available".
I disagree. You can't just write an inefficient program and hope that advances in hardware make up for it.
I think Java's biggest problem is the lack of a good garbage collector. I saw a program where the programmers had put a tiny memory display in the bottom left corner of the screen. At first it was OK, hovering around 100 megs, but as we kept using it, the memory usage would increase as needed, but it would never free it after it was done with it. Within 10 minutes, the thing had occupied all 512 megabytes of that computer's RAM and nearly crashed the system.
There is also a non-Java alternative to this program which has less features, and a CLI instead of a fancy GUI, but at least it doesn't need two Gigs of RAM to run. Personally, I prefer the non-Java one.
Or maybe a bunch of us still complain about Java's slowness because it _is_ slow if you don't happen to be running it on a Windows box.
What's the point of a "platform-independent platform" if it's really only meant to run well on one platform?
My last name is Goslinga....
What does embedded have to do with realtime? My phone is embedded, doesn't mean I play Java(tm) bowling games in realtime. Throwing extra unrelated stuff in to obscure the point is not the mark of an organized, rational, correct mind. This almost borders on a Straw Man fallacy.
Secondly, Java being used IN real time and Java being used FOR real time are two very different things.
Unless you have a physical Java Machine, then your Java code will always always always get JITted or be emulated. If it is emulated, it by definition cannot be as resource-efficient and fast as native code, because the emulation itself takes CPU time and RAM. It's like throwing a football toward the cabin in an airplane approaching the speed of light: as hard as you try, you can't break basic laws of reality. (Sorry for the weird analogy, but I thought it appropriate considering the Relativity piece).
Sure, once the emulator (JVM) is loaded, it may have close to the same speeds. Hell, if the JVM and compiler writers are smarter than the compiler writers for C or whatever, the Java may even run faster. But that's purely incidental.
*bashes it into your head* Native code is faster than emulated code!
They entirely overhyped it in areas where it's relatively useless (the desktop) and entirely underhyped it in areas where it's extremely useful (backend and embedded areas).
Now ten years later you talk about "java" and all anyone remembers are those horrible, sluggish AWT applets, running on netscape 4.0's broken JVM, which they used during the initial Java hype push. But almost nobody these days knows about the success Java met in unglamorous areas after the hype push had died off.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Well you have to stop thinking for about one minute and 97 seconds before you fire up the command to start the JVM...
Ahem, I once delivered a program for an RS6000 and got the first access to that architecture at deployment time. It ran instantly, all I did before was to develop the program on windows with a Sun JDK, test it on a IBM JDK on Linux which caused me to alter one line of code in about half a million LOCs this program had including all the libs I used and them Deploy it on a Power based multiprocessor RS6000 which I could not get access to.
Use C++ like it knows what it's doing instead of fighting the language.
Use smart reference-counted pointers, const correctness, exception safety guarantees, the STL, and proper object-oriented programming to make it all possible, and it's fairly difficult or next to impossible to run into buffer overflows, double-free errors, memory leaks, and other traditional C errors.
Try to program in C like a petulant child because your boss is forcing you to use C++, and yeah, everything you said is true.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Throwing extra unrelated stuff in to obscure the point is not the mark of an organized, rational, correct mind. This almost borders on a Straw Man fallacy.
Please don't be so silly. Attempting to classify someone who mentions 'embedded' along with 'real time' as irrational does not help your argument.
Much real-time processing is done by embedded systems. This is where software is included effectively as part of the 'hardware' of the device.
*bashes it into your head* Native code is faster than emulated code
When did anybody mention emulated code?
[Yes, because those who object to it not being open-source have a political agenda to rubbish it.]
Really? You think that's why it is?
Yes. I have been following this for years, and that is the only reason I have been able to come up with.
Odd, I wouldn't have expected those with a political agenda for open-source to be so enthusiastic about
Me neither.
Or maybe a bunch of us still complain about Java's slowness because it _is_ slow if you don't happen to be running it on a Windows box.
What's the point of a "platform-independent platform" if it's really only meant to run well on one platform?
Interesting. None of the current benchmarks of Java performance show that it is slow on Linux, for example, as compared with Windows. Indeed, IBM's Linux VMs routinely rate as some of the fastest Java implementations.
Perhaps you could provide some code and benchmarks to illustrate the supposed slowness on Linux as compared to Windows?
Thanks for grabbing more accurate numbers, I'm not sure where I got the Netbeans numbers from, I might have mixed them up with another IDE :) Regardless, JBuilder is crap, Eclipse is good but when compared to Netbeans, Eclipse looks like crap. My company was kind of standardized on Eclipse for god knows how long, but they always have let developers choose any IDE they want (just most used to choose Eclipse). In the past 3 or 4 months I've seen a lot of developers switching to NetBeans. I used to be an eclipse fan boy, but NetBeans really made a huge turn around from its old crappy self. It is literally years past Eclipse now. If word spreads enough about it, I can be pretty sure it'll beat any competition. If you've never used NetBeans please go give it a shot. I still use eclipse all the time in a mixed envrionment with NetBeans, simply because our dev environment has some custom eclipse stuff that we wrote that makes certain things easier. Eclipse is crap unless you just want basic editing capabilites with code completion, etc.. I know lots of folks who write java code using vim or jedit, I do myself sometimes. If you like writing java code in tools like vim, then you probably like the grunt work stuff and eclipse will be great for you. However, an IDE can be much more then what Eclipse provides and I didn't really realize that until recently when I started finding out all this great functionality that NetBeans has.
Regards,
Steve
If you knew anything about real-time systems, you'd be aware that real-time isn't about speed, but about predictability. The system must be provably "fast enough" on certain criteria, which certainly doesn't imply that it has to be "fast".
Yes you can... both the unary (*A - that's how smart pointers usually work) and the binary (that's how complex numbers usually work) versions.
My website
Six characters long? It's three in Emacs (sop) with abbrevations.
Code completion, I have found, is slower than knowing what the hell you are typing. And if you DO know what the hell you are typing, then code completion actually sucks quite hard because it interrupts you while you are typing something.
Eclipse is nice for some things, I like the auto-fixes and sometimes load code into Eclipse after I've spent a while actually writing in Emacs. But for actual code creation I still find Emacs to be a lot quicker because of its overall flexibility in a task at hand, between macros and abbreviations and user-defined functions.
As for that cool trick of "show me all the places my constructor is invoked" - well that's what the JDE Cross Referencer is for:
JDE includes a facility for creating and utilizing a cross-referencing database to enable you to quickly locate all the callers of any particular function. This functionality is very useful for quickly figuring how unfamiliar code works, and useful for doing certain tasks such as renaming functions. Be advised that this only finds direct callers, and cannot detect calls via Java's reflection mechanism. The cross-reference database must be kept in sync with the project code, however the database generation is generally quick. The remainder of this section explains how to configure and use the cross-referencer.
(from the JDE Users Guide)
Of course Eclipse has the same liability about not finding callers that are really invoking a constructor dynmically which is why people don't end up using such features all that much.
Eclipse is the way of the future though, it's nice to see a really strong generic IDE platform develop. I have no doubt someday some clever person will embed a fully functional Java version of the Emacs editor (no the keybindings alone are not enough) in Eclipse and then I'll be all set.
People who use IntelliJ seem to like it a lot better though, I have to say.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
C++ was 14 around 1997 and was widely used and known for its high performance.
Doesn't that say something to you?
Yes, that does say something to me. It tells me that people very much like to stick to first impressions. Granted, those horrible applets from the dark ages of Java haven't done the language much good, but I would definitely not consider a decent, well-written piece of Java software to be slow.
Show me a recently written piece of slow Java code, and I'll show you a programmer who should be looking for a new job. Think Burger King.
http://jcsnippets.atspace.com/ - a collection of Java & C# snippets
No, that's not the way modern JVMs work. The whole "out-of-memory, stop the world for a GC" way of thinking was archaic before Java was even a gleam in Gosling's eye.
Granted, the programmer can do silly things that cause the system to perform badly, but this is not the fault of the garbage collector.
Am I part of the core demographic for Swedish Fish?
Perhaps you'd care to explain how that's 'pure Java' any more?
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Java should be great, but it isn't. For all the 'writeonce, run anywhere' gumpf that the marketing department came up with it failed in the most important test: usability. I can code pretty well in most languages, but as I work with Java, and was trained in Java at Uni, its the language I think most clearly in... unfortunately.
The fact is I can code a quick app in Java on my Mac, compile and send it my Dad on his Wintel and he won't have a clue what to do with it. I then have to spend 5 minutes on the phone explaining either how to install the JRE, or how to run it from the CLI. Whats worse is that once its running, it looks like I can't code, as Java, by default runs noticably slower as you wait for the JRE to bootstrap and then for the JIT to get all the important bits compiled. Why would I do that to myself?
Java is a great concept. But it has systematically failed on the desktop. What I want is a write once, compile anywhere. Same scenario, I want to have a compiler that I can target a Wintel platform from my mac and just send my dad the executable or installer, so all he has to do is double click - like he would any other app, and it run as well as a VB app (ie a little slower than native is fine). I would keep a few things from Java. I love GC for quick hack apps, fine grained memeory management has its place, but you can often feel like you reinventing the wheel, and its a gapping whole for the script kiddies to drive their payload through. I also love the central API. I can see the purists arguing against exceptions, but they do make debugging very easy, and they're not that expensive really. I also like the ease you can do threads. I don't like the GUI performance or the end user experience.
If MS isn't going to play ball, and support various runtime environments from a fresh install, or if Java continue on insisting on a 20MB JRE download I can't see anyway around the byte code problem except to distribute binaries. Qt is a good start. Mono and C# are good candidates, but to be honest I'd be tempted to take Java, bolt Qt onto it, and use GCC to create targeted binaries. Is that out of the question?
Scared of flying, pointy things snce 1979!
Of course, it really depends what you're trying to do and who wrote the code.
Throw java at a large numerical problem and watch it suck really really badly compared to C or Fortran. And don't get me started on trying to hook it up to numerical libraries.
However on most application like problems rather than scientific applications it doesn't do badly.
Now factor in the fact that java si being taught to everybody and his dog and is starting to suffer from VBisms as a result, and you may find that while its possible to write good java code which is competetive with C, the average java code is probably beaten by the average C code for a task.
Googling for real time java should come up with RT Java VM vendors.
> ...articles [...] which suggest that
> Java's real time support is fairly
> immature.
And keep in mind that there are companies (well, the one anyway) with competing technologies. Between their FUD spinning departments, employees, shareholders, and fanboys, a steady stream of non-factual Java-bashing is inevitable.
Java is being used, and has been used, for RT programming for years.
Nah, unless you run Windows on a Cray, it still sucks ass.
need a free COBOL editor for Windows?
Do you suppose, then, that this is the reason why modern Java virtual machines are based on JIT compilation or dynamic compilation?
On my computer at least, Java is compiled using a highly optimizing dynamic compiler. Java uses the same machine instruction set as C.
Huh? The terms "reference" and "pointer" mean the same thing in Java. It is the address of an object.
On, say, a 32-bit machine, the reference to an object is the exact same 4-byte value - the same size, shape, and numerical value as a pointer in C.
If you disassemble the machine code produced by Sun's JVM, object references go in registers and are dereferenced using the exact same instructions as what a C compiler produces.
Indeed a problem for garbage collectors, luckily Java ships with several different algorithms. The one used by default (full halt for a step in generational GC) has the best throughput.
If you are more worried about short pauses you have two other alternatives however. The concurrent low pause pause collector will halt the application threads only in some phases of the collection, it is activated with the -XX:+UseConcMarkSweepGC flag (or system property). It does work in a different thread, so it is a good bet if you have multiple processors especially. The other option is the incremenetal collector, -Xincgc, which will do minor collections in parts with application threads getting to run between the steps (causing the pause to be spread out).
Another notable option in these multicore days is -XX:+UseParallelGC, which will launch several GC threads and do some of the work in parallel.
Overall there is a lot of opportunity to tune the Java garbage collector, google about on it a bit, it has been shown quite feasible to make nice interactive experience with Java (Jake2 anyone?). If even better guarantees are needed however it is probably best to look at one of the realtime JVM's. There are a variety available.
Huh? The terms "reference" and "pointer" mean the same thing in Java. It is the address of an object.
On, say, a 32-bit machine, the reference to an object is the exact same 4-byte value - the same size, shape, and numerical value as a pointer in C.
If you disassemble the machine code produced by Sun's JVM, object references go in registers and are dereferenced using the exact same instructions as what a C compiler produces.
Nope. Java spec doesn't dictate the implementation of references and they in fact don't have to be implemented as pointers -- like I said, some VMs use handles. Hell, an interpretor could use a hashtable even. There is no restriction because references can't be treated like pointers (used as to access object memory by address).
Comparing JNI to C#'s unsafe mode is a red herring. Unsafe mode was added to C# to allow the grandfathering of massive volumes of ill-behaved code into .NET systems. Microsoft does not like giving up old code bases. As a result, new C# applications will be peppered with security holes as developers of applications and libraries resort to unsafe mode. Even if you choose not to use it yourself, what large scale application can be developed without using off-the-shelf libraries? In practice, you'll have no way to reliably avoid buffer overflows with C#. In contrast, there is no unsafe Java code (JNI is used to run non-Java code. If you port the involved code to Java, you get "safe" code.). As your system moves towards 100% Java, the potential for pointer errors goes to zero. Not so for C#.
Microsoft's claim that sprinkling "unmanaged code" everywhere in your system is superior to linking to external libraries is very strange. What does the phrase "tightly limit unsafe code to just the statements where it is needed, often just a single statement" mean? How can you limit something that can be everywhere? 10 years ago, Microsoft was claiming it didn't need a security sandbox for Active X because it had digital signatures. Now they're claiming it's okay to put buffer overflow vulnerabilities in your code because it's convenient for the programmer. They just don't seem to understand security.
Java is good, but why it totally ignores the Lambda calculus and other important concepts of the theory of programming languages? it could have been much better, in my opinion.
Nothing in the C standard prevents an implementation from implementing pointers with handles, either.
Everything about C prevents pointers from being implemented as handles.
A pointer is expected to be just that, a pointer (not a reference to an abstract idea like an object).
A C program expects (char pointer + 1) to be the next byte in memory. (char handle + 1) will not be the next byte in memory.
Please explain how an implementation of C using handles instead of pointers could work with this valid C program:
char c;
char *cp = strstr("abc");
int x;
x = (int)cp;
x++;
c = (*(char *cp)x);
slow garbage collection? the demo at Java One on the real time jvm that is used to control the airplane made by Boeing shows that even garbage collection can be tightly controlled.
.net equivalent I gather.
Bloated? the windows international 5.0 jvm is a 15MB down only. For something that powerful this is really incredibly small. And it is much smaller than the
Not free? There are many implementations of the jvm from many vendors. BEA for examples has its own JVM that runs on multiple OSes. Their latest one will even run on Intel directly on the metal. IBM has its jvm. Many other do. And all of these are compatible. The only problem to date has been having a gnu jvm. There are a few, and they are a little behind: not surprising given the speed at which things have been moving in java, and the amount of investment it has received. But recently sun has backed one open source jvm at apache. Also I think Sun is open sourcing their own jvm...
Native code is faster than emulated code!
Funnily enough, not always. Scroll about halfway down and look at the benchmarks. Bear in mind that this paper is about running native code through a JIT compiler-like system and comparing that with running the exact same native code directly on the OS.
Don't you hate meta-sigs?
Hmm, your link times out; I'll have to do a bit more googling. I found a bunch of places selling RT Java products but I don't know if I could be bothered wading through all that marketing speak to find out what they're actually selling. I'd be interested to know how they do GC, though. All the fast approaches seem to involve unpredictable lags when it's time to do a GC run. Say what you like about JIT compilers versus compiled binaries, but I would feel more secure running RT code if it was non-GC.
Don't you hate meta-sigs?
Perhaps you'd care to explain how that's 'pure Java' any more?
.so file, and load it in. So, you can write pure Java code that does something impure; Gosling's assertion that the Java language prevents you from doing this is therefore bogus.
The code is pure Java. That pure Java code happens to open a file, write a
GrandGrandparent: troll, there's not the word 'slow' in the article.
GrandParent: informative
Parent: troll
"I think this line is mostly filler"
Unsafe mode was added to C# to allow the grandfathering of massive volumes of ill-behaved code into .NET systems. Microsoft does not like giving up old code bases.
And Sun, instead, creates millions of lines of untested, immature C code and adds it to their Sun Java implementation (just look at the Java2D code). Frankly, I trust even Microsoft's libraries more than that.
Microsoft's claim that sprinkling "unmanaged code" everywhere in your system is superior to linking to external libraries is very strange.
Unsafe statements are explicitly marked in C#, and they are limited to unsafe modules. C# is exactly the same as JNI in that regard, but C# provides you with a much better language to write JNI-like modules in, a language that is far safer than C/C++ even in unsafe mode, and a language that actually works across systems.
What does the phrase "tightly limit unsafe code to just the statements where it is needed, often just a single statement" mean? How can you limit something that can be everywhere?
It means that as a programmer developing a piece of code that needs to do something unsafe, it's better for me if I can compile almost all of my code in safe mode and only have a single line of unsafe code, than being forced to write an entire JNI module in C/C++.
Now they're claiming it's okay to put buffer overflow vulnerabilities in your code because it's convenient for the programmer. They just don't seem to understand security.
You keep confusing safety and security; safety is neither necessary nor sufficient for security. Most Java applications are, in fact, not secure at all.
C# supports runtime safety in a well-designed and time-tested framework, which is helpful for building secure systems. But forcing people to use only safe constructs does not improve security any further, it actually makes it worse.
Eclipse - the slowest machine I'm running it on is a Pentium III - 500 Mhz (Windows 2000, 512Mb ram), indeed not the fastest machine around, but the application is definitely not slow when working on my projects (large projects, I might add, no helloworld 1 classamathingies).
Azureus - I'm running Azureus at home on my old Pentium 1 - 133Mhz (Windows 2000, 48Mb ram) and it works like a charm. If it runs visually fast on THAT machine, it's FAST.
I never use jEdit, so I cannot comment on that.
Java applications can be slow (think JDeveloper by Oracle for example), but that's not the fault of the language. Repeat after me: if a Java application seems slow, it's almost always the fault of the programmer's lack of knowledge of the language.
http://jcsnippets.atspace.com/ - a collection of Java & C# snippets
Throw java at a large numerical problem and watch it suck really really badly compared to C or Fortran.
On the contrary; I have found that the IBM Linux VM can actually out-perform optimised gcc-compiled C on numerical work.
A major study last year showed that Sun's latest JDK (5.0) was within 4-5% of good optimising C++ compilers running the Linpack benchmark.
There is no reason why a JVM couldn't release memory that isn't needed anymore to the OS. However, since memory resources are always in a state of flux with Java, the likelihood that hitting such a high water mark again will occur is high, so it generally isn't worth doing. Java only claims extra memory from the OS IF the programmer was dumb enough to hang on to too much memory.. This is a notorious problem with Java programmers.. They think it's too expensive to construct new objects, so they cache them ALL. Even the stupidest little ones like lists of data. So each of the thousands of classes each holds on to little caches of data, which point to other caches of data, bla bla bla. The end result is that the GC winds up doing 2 or three full sweeps and doesn't recover enough memory, so it asks the OS for more..
The way it's supposed to work is that object allocation is embarrasingly fast (compared to most other architectures), so you allocate what you need and release it as soon as you don't need it. You have thousands of very fast mini-garbage collections this way, and never get above a 32Meg foot-print. (Yes, I know 32Meg is large compared to say perl). I often run full web applications that never grow to more than 32Meg.. However, when doing full caching DB's I grow to over a gig in size. But the performance is worth it in that case. It's only when some thread-locals dont' release their wears that I find memory "leaks", which aren't really leaks, since the next time that thread is re-used, that memory will be freed and thereby recovered.. In the mean time slow (2 second) full GCs need to be performed. But it's still bad programmer design, not the VM itself. A c program written in the same way would leak just as badly, and lets not forget the propensity of c++ programs to never even free objects it's not done with.
-Michael
I never really bought the "social skills" bunk. I think chitchat and small talk is useless and stupid so I usually don't engage in it. Does this mean I don't have "social skills"? As long as you are articulate, and unless you are in public relations, fuck "social skills".
Stereotypical pseudo-rational geek attitude.
The inconsequential "chitchat and small talk" are the manner in which we find out more about the person we're dealing with before things get more serious, allowing us to "feel our way round" when we are unsure. This may apply to both strangers and people we're currently unsure of; don't bring on the heavy stuff first. They're the manner in which we show respect by asking questions about the other person that may not *directly* involve the business we have with them; of course, this may open up opportunities we hadn't considered, possibly leading to friendship and/or greater business involvement.
Not everyone is equally good at this. Not everyone places equal importance on it. That's part of the healthy mix of personalities that push some people to work in public-facing jobs, and others to work in more "human-phobic" areas (such as the more technical aspects of computer hardware). It's okay to not be a "small talk" person, as you are.
On the other hand, to criticise it for being "useless" (because it doesn't serve any obvious purpose) smacks of blinkered short-sightedness and the kind of (phoney) rationalisation of their own behaviour that geeks like to indulge in.
Frankly, the kind of people who come out with this kind of stuff probably consider themselves "rational". Actually, that displays a laughable (and verging-on-the-autistic) lack of self-awareness. Geeks are no more "rational" than a lot of other people; they have their own neuroses and obsessions that are obvious when you take a step back. For example, to use the same surface "rationalisation", what purpose does being fanatical about "Star Trek", an entirely fictitious TV show serve? None. Surely it's more rational or logical (*) to live in the real world.
Of course, the fan will explain how it represents the problems of today's world in a semi-abstract manner, blah blah... the more insightful will mention that it provides an outlet for the geek personality type. Point is; if they are forced to explain it in depth, they'll put the effort into considering their own behaviour that they won't even waste considering anyone else's. (Although they won't explain it as an excuse to escape the real world or dress in fantasy costumes; that would be too close to the bone).
So, to get back to the point, your failure to even recognise the purpose of small talk (whether you like it or not) smacks of the most arrogant and deluded abuse of rationality to justify your own shortcomings and behaviour.
(*) Reminds me of a friend I had in my early teens who was into sci-fi, had a crap geeky sense-of-humour and an obsession with Spock and "logic". He was no more logical than anyone else; in fact, sometimes he was downright weird. In retrospect, I reckon he was (slightly) autistic in some form.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
I would like to know, why is the parent modded "-1, Flamebait", when all it says is the f*cking _true_?
Because many of us have found it not to be true.
I'm a developer and I can say that almost every Java development tool is shipped with its own JVM.
The most popular Java development tool, Eclipse, isn't. Neither is NetBeans.
And why are those products shipped separately for each platform, when Java is called "cross-platform"?
Because different platforms have different ways of packaging software.
IMO, Java portability is a myth a it will stay so.
Eclipse, NetBeans, JBoss and thousands of substantial applications show that you are wrong.
Decent language - a few things could be better. However my company has been shipping production scientific software in JAVA in 21st century and making lots of money. It reduces the cost supporting different computer platfrms and has good GUI tools compared to C++ based products.
I was actually thinking about my Mac. I generally avoid Java on Linux for anything other than applets because I can get native programs that integrate better with my desktop and don't suck up all my RAM (my Linux box is aging).
JimmyGosling Then I think you are a little confused. I am going camping with this guy in a couple weeks and he is Absolutely not James Gosling. Maybe you mean someone else, but i doubt it. Anyway, good gor a laugh.
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
I was actually thinking about my Mac.
Apple has always been rather behind in releasing Java versions.
However, I don't think 'Java is slow on the Mac' is the same as 'Java is slow on anything but Windows'....
Measuring lines of code isn't a very good metric when comparing different languages.
Badass Resumes
1 and 3 are related. I agree that not having a decent integrated JSP editor bundled or available for free is a detriment. Then again, not everyone needs JSP editors.
;) I doubt 90+% of the java devs out there do either.
2. I don't see this as a negative.
5. Eclipse has had this since at least 3.0.
6. I prefer to pick and choose my Tomcat server version, thank you.
So, I see 2 items not freely available for Eclipse, and 1 of those is undesired by a large number of java devs.
The cesspool just got a check and balance.
As for inconvient GC cycles, that is the programmers fault. You have to do your own GC when you think you have time.
Programmers are not supposed to manage garbage collection themselves :- Calling System.gc() explicitly can actually decrease performance and is not recommended.
JVMs even have a -XX:+DisableExplicitGC flag to allow system administrators to workaround code that mistakenly assumes calling System.gc will help performance.
- Setting all references to null after they are not used is also not necessary in many cases. For temporary objects, or local variables, setting unused reference to null won't improve GC at all, because memory is freed when the garbage collector is running, not as soon as the reference is set to null. It is only in long lived objects that it is important to set a reference to null when it is not useful anymore (otherwise it causes a leak)
- For caching data, a cache could manage memory itself, for example by clearing automatically the least recently used entries. Or it could let the garbage collector manage it itself entirely, by storing soft or weak references to the cached data.
A JVM is highly optimized, and therefore it is often better to let it decide when to do garbage collector than to try to manage it in the code. However, if the JVM makes the wrong decisions (for example if it causes unacceptable application freezes), it can be tuned to make better decisions in the future. Several startup flags exist to control the garbage collector's behavior (for example change the frequency of collections, use parallel or concurrent GC algorithms, tune the memory reserved for the different GC generations). These startup options allows the programmers (or system administrator) much more control over performance than optimization they can do in their code.The JVM will only GC when its full...
Not exactly true, the JVM will separate memory in different GC generations and collect each of these generations when it is full. Objects that survive collection in a generation will be moved to the next generation. Objects that survive up to the last generation (old) are likely be permanent objects that are required for the application to run. Therefore, garbage collection on the old generation runs much less frequently than on younger generation, but takes longer to run. If too many objects survive up to this generation, it can also be an indication of a memory leak or a need for optimizing memory usage. The visualgc tool can be used to monitor the different generation's memory usages on Sun JVMs.
Jython's competition is Groovy. Groovy doesn't even have a stable DESIGN, let alone implementation.
No, the code isn't pure Java. As soon as you load that .so file you're not running pure Java any more, and it's that non-Java library that 'does something impure'. Makes no difference where that file comes from - a standard filesystem or an array of bytes defined in a Java file, it isn't Java code.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
The Java libraries range from mediocre to terrible, but that's a separate issue.
Are you on crack? Slam Java for whatever reason you want, but the libraries are widely agreed to be it's greatest strength. Even the libraries that aren't provided in the standard JDK tend to be standardized and very easy to use, javadoced to the hilt. Java's not my favorite, Smalltalk will always have me there, but just which language do you consider to have better built-in library support? C may have more options, but it's a dependency nightmare and libraries aren't nearly as clean, consistent and forward/backward compatible as the Java ones are. I can find easily find a free, well-implemented libary to do whatever I want in Java.
I use it, and I'm happy using high level languages, I'm a big fan of python for example. Nevertheless, I still say java is slow. Why? Because I'm actually trying to use it for actual programs on sub-ghz machines.
I am trolling
Comparisons to C++ are a red herring, languages have moved on since then. Python is both far faster to write (5-10x) and faster in actual use (since the performance-critical extensions are C/C++, wheras all but the very basics of the Java class library are done in Java.
I am trolling
Why not? For a start, using a scripting language would have probably resulted in a factor of 10 reduction in the number of lines needed. And perl or python run on as many platforms, possibly more (java didn't work on beos last time I checked). Java may have open specs but it isn't open, wheras almost every other language has a truly free implementation available. And why do you claim linux owes its success to Java? There's no J in LAMP.
I am trolling
Nevertheless, I still say java is slow. Why? Because I'm actually trying to use it for actual programs on sub-ghz machines.
Modern JVMs produce optimised machine code that can approach that of C++. This process is not dependent on the processor speed. If Java comes close to C++ speed on multi-GHZ machines, it will also come close to C++ speed on sub-GHZ machines.
What might be slow is the Swing GUI, especially with older Java versions.
The fact that MS tried doesn't mean it isn't a problem. It is a problem, the language has no free implementation, I can't recall anyone ever trying to exert as much control over a whole language as Sun does with Java.
I am trolling
Can you explain why most Java applications aren't secure? Can you give examples?
I can't remember any security problems in Java applications, altough they are possible...
Why do you say that using safe constructs makes security worst?
What's next? Array bounds checks in runtime makes more buffer overflows?
I think I perhaps failed to communicate my point clearly. I should have stressed the "If it's emulated..." part, as I really haven't paid much attention to the internal workings of the JRE recently. Wikipedia makes me think that it JITs everything. In which case the "If it's emulated" part is inapplicable; I was still under the impression that we were actually emulating the JVM in the JRE. My mistake.
(Side note: Some of you thought my entire point was about whether or not Java(tm) can be used in realtime applications. It was not. This thread is about whether or not "Java is slow.")
When using a JIT compiler then the Java code is converted to native code. As such, execution time isn't pertinent to the discussion in and of itself, because it's comparing native assembly to native assembly. Only the quality of the compilers can change this, and as there exist a plethora of compilers for C, C++, ObjectPascal, BrainFuck, and SNOBOL (bizarre enumeration meant to signify "everything else under the sun"), it's not really possible to use a compiler comparison to compare the speed of two languages.
"Java is slow" is an oversimplification. As Mr. Lector would say "That's incidental!". There's nothing in the language which inherently requires that the resulting native code be slower than any other native code (except perhaps for some paradigms which it encourages which may not result in optimal code). What people mean when they say this is that the majority of runs involving Java are slower than the majority of runs involving another language; the run-times of two equivalent programs are different, disfavoring Java.
This is because of the design of the Java environment. The vast majority of people do not run pre-compiled native-code versions of Java programs. The Java apps in use my most people is JITted. This results in a delay (often significant) before code execution. In addition, the JRE remains loaded, handling all sorts of who-knows-what instead of compiling to a complete executable and running that. This takes up memory and CPU power.
Compiled C program run:
Start up slow-downs: None
Run-time slow-downs: None
JIT Java program run:
Start up slow-downs: Compiling JVM code 2 native
Run-time slow-downs: (potential) RAM overhead of JRE
Please note that I marked the RAM overhead as a potential factor in speed reduction because it isn't guaranteed that less available RAM = reduced speed (a user could have a gig or more of RAM and/or nothing else running and virtual memory turned off or be in any of the other myriad circumstances which would render the RAM usage irrelevant).
Compiler design and algorithm use being equal, it's impossible for a Java program run in the de facto environment to be have a run-time equal to or less than the equivalent C program. The only way for Java apps not to be 'slow' compared to other apps is to have fully-fledged native executable versions of Java apps (including allowing static linking).
If I'm significantly off-base, I appreciate any friendly corrections.
Friendly auto-correction:
s/run in the de facto/that is run in the de facto/
s/be have/have/
Sorry. I should have used Preview.
a.crossProd(b), or a.dotProd(b).. But if you're looking at a * b in c++ for the first time, which is it?
Hmmm, you're right about that. I was thinking about matrices in my example so there was no ambiguity. In any case I think it's better to be able to at least overload the operators that don't cause ambiguity. In Java I'm forced to write ugly code!
It comes down once again to whether you prefer a powerful language that lets you shoot yourself in the foot, or a less powerful language that lets you write code orders of magnitude faster. I think C++ is in the first category, but Java isn't in the second - give me Python any day.
My website
JBuilder, JDeveloper, Java Studio Creator are. So is Oracle Installer (which was even shipped with 2 JVMs in 9i). My college told me that he currently has 5 or 6 JVMs on his machine. Don't try to tell me that this is not bloat.
These are shipped with VMs because they are intended to be complete products and they don't assume that anyone else has installed a VM. You can configure all these programs to use the same single JVM, providing those JVMs are above a certain specification; they should all work fine with a 5.0 JDK.
You don't need to keep those 5 or 6 VMs on the machine one you have set things up.
I would agree that Oracle is bloat; but Oracle has always been bloated!
What is the problem with zip archive and *.sh and *.bat install scripts?
Because users expect more professional InstallShield-type systems.
I would like to know all those "thousands of substantial applications" written in Java. I can name you tens of real killer OSS applications, but neither of them is written in Java.
I'm sorry, but I don't consider applications which start in minutes and eat all available memory as substantial, but people criteria may be different.
Substantial applications are large applications that do a lot. Almost every large or medium commercial company has important applications written in Java. These almost never rely on a particular VM version (you don't get them requiring, say 'JDK 1.3.1, but not JDK 1.4.2').
As for the 'start in minutes and eat all available memory' - that is just silly. Even a large application like tomcat can start in a few tens of seconds (and considering all it has to load, that is not bad). Before version 5.0 all Java VMs had a default maximum memory use of 64MB. Even a large IDE like NetBeans runs in 96MB. so, to say 'eat all available memory' is a wild exaggeration.
Java does have a lot of class libraries, but inactuality, they're about the same size as a graphics toolkit like GTK, Glib, and a C library. Having them bundled with all Java distributions helps with compatibility with all applications and prevents users and developers from having to download/install extra libraries.
Isn't this the point of all programming languages? Making it easier for programmers to program? With your logic all C programmers should be coding in x86 assembly because "[C] allow[s] poor coders to produce code that kind of works rather than total failures[, and it] probably [doesn't] help the language's reputation[,] either." Even though I consider myself a competent C programmer, occasionally I use Java for certain programming tasks. With Java, I find that doing certain tasks are much easier with Java than under C. For example, Java has many helpful libraries, and the base classes are full of many helpful methods. In C, you find yourself having to either search for ready-made libraries that you'll have to learn how to use, or having to code certain helpful tasks by yourself.
I personally find Java to be a pretty nice environment to work in. No, it isn't "free," it's not as fast as C (exasperated by the fact that my fastest machine is a 475MHz K6-2 with 64MB RAM), and sometimes Java can be quite verbose. However, Java provides a lot of helpful classes and packages to choose from that makes development a lot easier. Plus, I don't have to worry about pointers, memory management, and all of that other stuff that I have to keep in mind when programming in C.
That's your answer to the question that blows a big hole in your "pet theory" -- that it's all about people hating Java for political "non-free" reasons. Wow, you really are an idiot, aren't you?
I hope not.
It couldn't be as simple as the fact that most peoples' experience of Java is slow, ugly, bloated and sucky applications. Could it? Nah... it's got to be political reasons.
Yes it has, because any anyone who has actually used Java and developed with Java over the past few years knows, this is a wildly out of date view.
An example of how out of date this is is that the Java IDE NetBeans recently won the developer.com award for best open source IDE. Hardly an indication of 'bloated and sucky'.
Most people use Java daily without knowing it, when they use their banking websites, or chatrooms or sites like E-Bay. Millions of people use Java games on their mobile phones. I hear no complaints about E-bay being slow, bloated and sucky!
I would have said that your point of view would have been correct about 4-5 years ago.
There is no doubt that there is huge 'geek' resistance to Java because it is not open source. Perhaps because of this many such people have not used it for years, and so have a widly out-of-date idea of what it is like.
All I can say to this is: Wahhh!
Apple has always been rather behind in releasing Java versions.
Apple does not develop Java. Sun does.
But they don't. E.g. Java Sun Creator 2 EA doesn't work correctly with 5.0 JDK. They (Sun) said: "JDK 1.5 is definitely in the plans for Creator." Really funny...
I'll admit that is pretty bad! I am not impressed, as Sun's NetBeans (which includes an app server and visual design tools) runs on just about any JVM.
Ugh? These are targeted to advanced users or developers, who probably know how to download JVM.
But when you buy a package, you expect everything there.
Almost ever development tool I've downloaded had a Java GUI installer invoked by a script, so I really don't see any reason for providing separate packages for different platforms.
Many applications don't provide different packages for different platforms - Tomcat and JBoss for example. NetBeans does because it is provided as an EXE.
[As for the 'start in minutes and eat all available memory' - that is just silly.]
No, it's reality. Have you ever seen something like BEA WebLogic?
WebLogic is not a typical Java application. It is an application server, and a large complex beast.
[Even a large application like tomcat can start in a few tens of seconds]
Tomcat being a large application? Maybe if you count lines of code or XML config files... I consider Apache being much more complex application and it starts almost instantly.
Apache serves web pages. Tomcat serves web pages and provides significant parts of J2EE as well.
[Even a large IDE like NetBeans runs in 96MB.]
You are kidding, right? Maybe version 1.0 or older...?
96MB was the default setting for version 3.6, which was up-to-date until last year.
[to say 'eat all available memory' is a wild exaggeration.]
Unfortunately not, look at WebLogic or Sun App Server. All those beasts start minutes even on recent hardware and after a few hours eat all the memory you throw at them. I can point you at discussion forums, where several people complained about Sun App Server, when their OS started to swap after less than half a day of development.
Again, these are not typical Java applications. They are application servers - equivalent to operating systems to run Java applications. They grab memory for a specific purpose - to provide cacheing of data and classes to give high performance.
To extrapolate from those to a typical Java program is like comparing Linux to a typical C program.
Apple does not develop Java. Sun does.
No. Sun provides Java implementations for Solaris, Windows and Linux. Companies can license Sun's source code to produce ports of Java for their operating systems. This is what IBM and Apple do. Other companies produce Java independently, such as HP.
This is why the Java versions produced by IBM, Apple and others lags behind the Sun version - it is the time taken to produce ports.
Bzzt. Factually incorrect. You could write a simple 5-line Java program and compile it to prove whether or not this works. I could cite the Java specification where it defines what variable names are considered valid, but instead I just took an existing short piece of junk code and changed a variable name to start with the underscore. Guess what? It compiles fine.
import java.util.TimeZone;
public class TimeZoneDumper {
public static void main(String [] args) {
String [] _zoneIDs = TimeZone.getAvailableIDs();
for (int i = 0; i < _zoneIDs.length; i++) {
TimeZone zone = TimeZone.getTimeZone(_zoneIDs[i]);
System.out.println(_zoneIDs[i] + " - offset = " + zone.getRawOffset());
}
}
}
Can you explain why most Java applications aren't secure?
They aren't secure because nobody has worried about making them secure.
I can't remember any security problems in Java applications, altough they are possible...
That's because the question of security isn't relevant to most applications.
Why do you say that using safe constructs makes security worst?
Using safe constructs improves the likelihood that a program will be secure. That's why it's good when programming languages offer safe programming constructs, like both C# and Java do. Limiting the programmer to safe constructs, like Java does, makes security worse, however, because the need for unsafe constructs doesn't go away, but you force the programmer to use more error-prone and less portable JNI modules.
What's next? Array bounds checks in runtime makes more buffer overflows?
What's next is that I think you should be kept away from writing any security relevant software. People like you, who don't even know the difference between safety and security, are a menace. You are worse than the C hacks who think they can do completely without runtime safety; the C hacks are wrong, but at least they know that they need to be careful.
A Java identifier (variable name) must start with a letter, true, but the specification goes on to say:
No, the code isn't pure Java.
.class file or the .jar file contain any construct that corresponds to C# "unsafe" code. All it does contain is a little bit of file I/O.
.so file you're not running pure Java any more, and it's that non-Java library that 'does something impure'.
Of course, it is: neither the source code nor the
As soon as you load that
Indeed, at that point it becomes impure. So, what you have is that code that does completely harmless things--a little bit of file I/O--all of a sudden executes code that manipulates memory unsafely.
That's why the notion that you can keep programmers from doing unsafe things in Java is a myth. The lack of an explicit "unsafe" construct in Java is a nuisance for programmers, but it doesn't guarantee anything.
It's not even worth debunking all the technical nonsense on that page; but two points should be mentioned because your lies and misinformation are actually dangerous.
.NET apis are proprietary and can open the door to a law suit.
.NET APIs is available from ECMA and not covered by such restrictions.
Public Domain APIs - Any Java public apis are part of the public domain,
In order to download the Sun Java API specs you have to agree to a license agreement that severely limits how you can implement the APIs. In contrast, a large chunk of
Standard Library Source Code Availability - Java source code for the core libraries are available in every J2SDK distribution,
Yes, and by looking at it, you agree to a license agreement with Sun that means that Sun owns your brain until you die. Since it sounds like you have looked at Sun source code, please do us all a favor: don't contribute to any open source Java project, because in doing so, you would endanger it.
In both cases, you don't have to believe me, just actually bother to read the license agreements that cover the specifications and Sun Java code. While Sun marketing likes to misrepresent the intellectual property issues surrounding Java, Sun's lawyers have made sure that their license agreements are clear enough. Unfortunately, morons like you click through those license agreements without bothering to read them.
No, the bit of code that does 'a little bit of file I/O' is completely safe. It's the bit of code that loads an external native library that's unsafe, and that's still not Java code that you're loading. You're just using Java as a glorified loader for your unsafe C/C++/assembler code. Which is all very well if that's what you want to do, but it still doesn't make Java capable of the misbehaviour you'd like it to be.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Can you explain why most Java applications aren't secure?
They aren't secure because nobody has worried about making them secure.
And C# is more secure? Why?
C# programmers are more worried about security? Because it's easier to call unsafe code?
I've been programming in Java for the last 5 years in various types of applications and I've never ever need to use JNI.
99% of the java programmers don't use JNI.
Does that mean that they are more secure that some C# code that calls unsafe constructs?
No, that dependends on the programmer.
But it means that the probability of I making a mistake and introducing a security bug is smaller.
I can't remember any security problems in Java applications, altough they are possible...
That's because the question of security isn't relevant to most applications.
Java is used in lots of applications where security is vital.
Why do you say that using safe constructs makes security worst?
Using safe constructs improves the likelihood that a program will be secure. That's why it's good when programming languages offer safe programming constructs, like both C# and Java do. Limiting the programmer to safe constructs, like Java does, makes security worse, however, because the need for unsafe constructs doesn't go away, but you force the programmer to use more error-prone and less portable JNI modules.
That could problematic if Java programmers needed to use JNI in every application. That's not real.
As I said 99% of java programmers never used JNI.
Do C# programmers use unsafe constructs in every application? That's a little bit scary...
What's next? Array bounds checks in runtime makes more buffer overflows?
What's next is that I think you should be kept away from writing any security relevant software. People like you, who don't even know the difference between safety and security, are a menace. You are worse than the C hacks who think they can do completely without runtime safety; the C hacks are wrong, but at least they know that they need to be careful.
I've never said that safety = security. But using safe constructs helps, but not solves, security. That's why having array bound checks helps making Java and C# more secure applications that C.
And don't worry I try my best to make secure applications. Using safe constructs is just part of the process...
But that doesn't justify it for starting more than 5 minutes and consuming more than 2 GB of memory for moderately complex app.
It doesn't. From the WebLogic website:
"Efficient Weblogic installations typically use between 128-384MB heap size per processor."
I don't mean bare Apache, but Apache with its impressive list of modules. IMO Apache has much broader range of functionality than Tomcat. And even in serving of simple pages is Apache 5-10x faster than Tomcat.
Actually, it isn't. Tomcat 5.5 benchmarks pretty much the same as the latest Apache for most web serving purposes.
I don't have direct experience with NB, but Java Studio Creator is built upon it and it takes around 300 MB only for opening an empty IDE.
Java Studio Creator is a lot more than NetBeans. It includes an active database and a substantial application server.
No, they grab memory because of bloat, as I wrote above about WebLogic. And as for "high performance", excuse me, but I am LOL. This beast serves pages as fast as would Apache on ten times less powerful HW, even without caching.
No, they grab memory because of cacheing.
I don't know where you come up with these 'ten times' figures, but this is obviously not true, as WebLogic is used in some of the fastest websites.
Linux scales, because it is efficiently written, those Java monsters are not!
Well, I am afraid this is just not true either. Java application servers are used because they scale. This is how very high-performance sites such as E-Bay, and various stock markets work. They can hit thousands of transactions per second.
I think it's time to end this discussion, because it could be neverending. You are a Java fan, I respect it. I'm a fan of efficient and elegant programs, so my short experience with Java, in which I'm currently forced to develop, is a bit disgusting (and I was trying to like it really hard).
I'm a fan of lots of technologies. But most of all I am a fan of accuracy. What I object to is arbitrary and incorrect statements such as 'Tomcat is 5x-10x slower than Apache' or 'Java doesn't scale'.
I would even argue with someone who said 'Windows 2000 Server is slow', even though I dislike Windows.
Yes, it may well be swing (but it's not an old version, I'm using the 1.5.0.04 and it's still slow) but that's the only java gui you can use without losing the whole point of using java. So the effect is that java programs are slow.
I am trolling
Can you explain why most Java applications aren't secure? / They aren't secure because nobody has worried about making them secure. / And C# is more secure? Why?
Your question has nothing to do with my point.
C# code is unsafe only if you explicitly choose to make it unsafe. That's exactly the same way it is in Java. Unlike Java, however, if you choose to use unsafe features in C#, C# supports you a lot better than Java does. That's all there is to it.
The point is and remains that Gosling's assertion about unsafe features in C# is wrong (probably deliberate FUD--even Gosling isn't that stupid).
You're just using Java as a glorified loader for your unsafe C/C++/assembler code. Which is all very well if that's what you want to do, but it still doesn't make Java capable of the misbehaviour you'd like it to be.
That's pointless semantics. The fact is that I can write a piece of Java code that contains no reference to JNI or anything else unsafe and yet it can do the same kind of damage as a C# "unsafe" construct. Therefore, any argument that Java keeps programmers from doing unsafe things is bogus.
You're still missing the point. That code does contain reference to JNI: at some point in order to get that unsafe code to execute you need to load it as native code in exactly the same way as you would do if it were in a separate file. Try to obfuscate that as much as you like by claiming that there's some magical difference in that code based on where it comes from, but at the end of the day you are using JNI, and you do have explicit reference to that fact in the Java code.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Agreed about development speed and libraries. I'm porting some Java to C for a small memory legacy project and it's painful: the lack of a GC, exceptions, persistance, boundary and null protection make it like going back to the dark ages, using C++ would make little difference. I'm having to write my own C code because so many of the C database libraries are poorly written (e.g. SQLite and GNU db) e.g. use too much memory, use the wrong data types, too many #defines, are not easily portable, have no caching and fail to pass 'lint' compiler checks. People my complain about minor Java portability issues, but they forget just how bad C and C++ were!
Try to obfuscate that as much as you like by claiming that there's some magical difference in that code based on where it comes from, but at the end of the day you are using JNI, and you do have explicit reference to that fact in the Java code.
.class file containing a class definition with JNI methods, and a corresponding .so file. You convert both into Java strings or byte arrays, and that's what gets put into the actual Java code. The Java code writes them both in the right place for them to be picked up by the loader. Then you call a method in the class you defined. The class gets loaded, the .so gets called, and the unsafe operation takes place. All your Java source code ever contains is a bunch of harmless file I/O operations and constant data.
/proc/self/mem and change any location you like through read/write operations. You can just spawn a debugger process on your own process and use it to change arbitrary memory locations. All of those can be done with standard Java, with either just java.io, or at most the Process class (of course, they are not cross platform but, then, neither is JNI).
No, you don't have to have an explicit reference in the Java code. You start with a
And there are plenty of other ways of wreaking havoc. You can just open
Java cannot prevent any of those unsafe operations; the mechanisms that can prevent Java from doing such things are careful code reviews and the use of operating system security features. The only thing that Java's lack of a built-in "unsafe" construct achieves is that it makes error prone, inefficient, and unportable things that ought to be simple and portable.