“Sun Microsystems’ Java software and Solaris operating system haven’t always gotten along, an internal memo indicates, but Sun says it has fixed the problems in the two years since the memo was written. The version of Java for Solaris is a poor choice for many types of programs, is slow to load, isn’t well-supported within Sun and requires too much memory to run, several Sun engineers said in the memo.” Read the rest at ZDNet.
I mean it would speed Java up a lot
Sun sells hardware. Obviously by making Java the incredible resource pig that it is, Sun can force people to upgrade to higher capacity, more expensive hardware. Sun also makes a lot of money selling special memory for their servers. If you don’t use Sun-approved memory, you risk your warranty and service contract. Sun wields major fear mojo over their customers. The engineers at Sun who work on Java are probably advised to figure out how to make Java use as much memory as possible.
It is that simple. Sun has no business upside in making Java small, speedy, lean, etc. The slower and fatter Java is, the more money Sun makes on hardware. And because Java is buggy as well as fat and slow, Sun’s consulting division is very happy.
–ms
Then why have they bothered to make Java work better? Seems a bit of a contradictory thing to make Java trim if it’s going to sacrifice their hardware revenue…
Have they made Java better? They’ve added tons and tons of features, expanded RAM usage, and generally slowed the whole thing down.
Sure the VM has been improved. Sun has to do something for their customers, show them they are “listening”, otherwise the customers would get very upset.
So Sun makes MINOR improvements in the VM and then adds 5000 more classes with all sorts of bizarre runtime graphs that hose the VM and require more hardware RAM and CPU’s to work well.
The memo said that to run 150 Java terminals, a modern Sun server needed 24GB of RAM. Is that Java working better?
I honestly think Java is worse than when they started with it.
Sun’s marketing hype says all these good things about Java, but you still need the massive hardware to run even simple server apps.
–ms
It has never ceased to amaze me how slow any Java program loads and runs on Solaris – even the ones written by Sun.
I don’t like what Microsoft has done with Java on windows but at least their JVM performs well.
Kennedy was killed by the CIA!!
No, I meant the improvements on making Java leaner and less memory intensive.
This is from Sun´s website: http://java.sun.com/j2se/1.4.1/index.html
¨Bug Fixes
As the first maintenance release to J2SE 1.4.0, over 2000 bug fixes were integrated in J2SE 1.4.1. ¨
Looking good, now only 98,000 bugs to go. 🙂
Perhaps for 1.4.2 we could get something that compiles with gcc 3.2.2?
I don’t know what experiences some of you guys had with Java on Solaris, mine seems to be the exact opposite: it loads very quickly, much quicker than on comparable Wintel hardware. Java 1.3.1 on Solaris 8.
As for the memo, I think osnews.com already had a run of it, recently. The memo seems to be a fake.
Sun already acknowledged that the memo was indeed authentic. The official position is that the memo is over two years old. However, the media is investigating this statement as the memo seems to be written post-ship of Solaris 9.
–ms
>>>The memo seems to be a fake.
Sun confirmed the memo’s authenticity.
http://news.com.com/2100-1001-984529.html?tag=lh
Using the latest Sun JRE (downloaded yesterday) and Eclipse 2.1 M5, I find that it uses much more memory than comparable editors SlickEdit and MultiEdit.
To load the same set of 80 Ruby files, a total of 697K:
Multi-Edit 9 ………… 10,796K
SlickEdit 7 …………. 16,828K
(and)
Eclipse 2.1 M5 ………. 41,848K
This is with no additions to Eclipse.
From all the apps I’ve seen, of every kind, everything written in Java is a memory hog, plain and simple.
As for performance, Eclipse took over 5 times as long to open the 80 files. And the Eclipse UI is still sluggish compared to a native Windows app, SWT or not. Adjusting the preferences inside Eclipse is far slower than in either of the two native Windows apps.
It’s a shame that Sun is in charge of Java. Had it been an open standard, the memory usage problems, speed problems, stability problems, design problems, etc., would have been better addressed.
–ms
…just a matter of time. Python is way more efficient and memory lean. It is faster, more flexible and more powerful than Java. Yes, Java has a big lead so far, but with Python development being so fast, I don’t think it’ll be that long before Python catches up. The momentum has definitely shifted from Java to Python. Sure, in some situations Java is (and will be) superior, but overall… Python is the way to go.
Java has a big advantage in that there is a large company – SUN – behind it, whereas Python has nobody. And now for a brain twister – it is also Java’s big DISadvantage to have SUN in charge of it.
But Python is winning over developers, and that is what counts in the end. Give it 5 years, and Python will be on top.
Som now java programs _do_ have fast starup time , and doesn’t use alot of memory ?
Seems backwards my dear Sun, the thing that chandet is faster computers with more memory, Java still sucks in this matter.
My experience with Java programs on my 400Hz Ultra Sparc 10 at work has been good. Java programs seem to run faster on it than my 800Mhz eMac, that is for sure. I don’t understand what all the fuss is about.
Chad
“It is that simple. Sun has no business upside in making Java small, speedy, lean, etc. The slower and fatter Java is, the more money Sun makes on hardware. And because Java is buggy as well as fat and slow, Sun’s consulting division is very happy.”
Bwaaaaa ha ha ha ha haaaa! Thanks for posting this historical, the most idiotic comment ever written in OSNews. : ))))
Oh, so you have compared Multiedit/Slickedit with Eclipse huh? : )))) Great idea for comparison indeed. Here is why the thing that you did is fabulously stupid:
1. Java programs offers WORA. Eclipse is running on VM. The VM based programs of course will be more hungry in terms of memory and slower than native apps. .NET programs are the same. They also need more memory and they are also slower than native executables. Can you run SlickEdit/MultiEdit etc. on MacOSX? Linux? BSD? Solaris? NO! Lets say you port them to these OSs. Do you think maintaining future versions will be easy for 10 different platforms? Of course not! Look, OpenOffice.org’s (SUN sponsored open sourced Office-like group of programs.) MacOSX Cocoa version will be released in 1.5 years. But Java based Think Free Office’s MacOSX version is ready to be used for a year.
Do you think .NET programs will be better than Java in terms of being memory hungry or slow? Of course not. .NET is just another VM based framework.
2. So, you made your wonderful comparison “This is with no additions to Eclipse.” : )))) Oh, your idiocy astounds me. While you are writing something in Eclipse, there are many threads checking what you are writing unlike the other programs that you have compared. Unlike MultiEdit or Slick edit, it does not only perform syntax coloring. For instance, it compiles your code at the same time in the background, keeps tables for dependencies to other parts of the code etc. Please be a little bit logical next time.
3. If you really want to make a comparison that makes sense, go and download Excelsior Jet Java to Windows native compiler: http://www.xlsoft.com/en/products/development/jet/ then download JEdit ( http://www.jedit.org ) or Jext ( http://www.jext.org ) then compile them into Windows executables and compare them with Slick Edit or Multi Edit. That makes much more sense, and something like 1000 times more ampirical than your comparison.
In the end, I am using lots of Java programs every day without any problems. They were slow and sluggish in the past, but Sun’s Java 1.4.1 simply ROCKS. Maybe this is why all the big IT companies apart from Microsoft are backing Java and Eclipse. Maybe this is why all the high level server side frameworks are being built on top of Java apart from the ones from MS and low level ones that are written in C/C++ usually. (For instance, all the web application servers (Sun’s, IBM’s, Oracle’s, HP’s, Macromedia’s, Sony’s, etc.) apart from MS’s are Java based. Maybe this is why all the mobile phone producers (Nokia, Motorola, Siemens etc.) are are backing Java. Maybe that is why 98 percent of the smart card industry now, is based on JavaCard technology.
Face it Michael, Java is not going anywhere. It is just getting more and more stronger.
It was nice to read your comments though. Laughing is a good way of starting a new day anyway. : ))))
First of all, I am not a fan of .NET. I don’t like it any more than Java. Well, it does support more languages and does have a better design, but it is still bloatware. Microsoft has a long way to go before .NET can be considered solid and efficient code.
My text editor comparison is to show one simple point — that a popular Java text editor touted for having good performance is a giant memory hog compared to the big gun native code editors. And also the comparison showed that Java is still slow at simple things like loading files.
As a user, I shouldn’t have to worry if my application is Java/.NET or native. It should work fast. It should respect my system and not hog up lots of memory. I am buying a programming tool to get a job done, not to worship at the altar of heap fragmentation.
No code coloring, compiling, etc was running on any of the editors. Just file loading. Eclipse needs extensions to handle Ruby files as do the native code editors (which do lexing, tagging, coloring, etc., just as Eclipse does).
MultiEdit is Windows only. However, SlickEdit is available on many platforms. Experienced developers have been doing multi-platform work for many years before Java. In many ways, Java has made cross-platform work WORSE. I say this because with Java programs, you are less able to take advantage of the neat features of the various platforms. You are less able to tune your app for the platform.
If your cross-platform goal is mediocrity, Java always has an excellent way to get there. If your goal is excellence, Java has no roads that go there.
Face it, the vast majority of Java apps are not compiled to native code with some non-standard tool. Sun does not include any sort of native code compiler. Sun relies on HotSpot (which they bought from some other company). Sun is not interested in real performance otherwise they’d buy/build a native code compiler and include it as part of Java, at least for the popular platforms.
For client software, there is NOTHING written in Java that is any sort of mainstream application. This is because Java is totally inappropriate for client software. Even in Eclipse all the widgets had to be written in real code (vs. byte code) and IBM had to reinvent J/Direct which Microsoft had made years ago to get good performance on Windows. And even with all this effort, Eclipse is still hefty and slow.
For server software, Java’s problems are legendary as Sun’s own memos tell you. And as every big Java shop can tell you. When the apps get big, the whole thing shudders and shakes. Java’s design is flawed and there are tons and tons of bugs. An out of control socket can bring down the whole VM. It is a joke.
I really do wish Java weren’t run by Sun. I think all the problems with the language, VM, tests, etc., are because one poorly managed company is controlling everything.
If Sun came out with a lean and mean Java, I think it would be great for computing. But I’m not holding my breath waiting for a HARDWARE company to produce fast and efficient software.
–ms
Eclipse vs. MultiEdit & SlickEdit?????
What’s next, a comparison between Notepad and VS Studio.NET??
Moron!
supports more languages ? well: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
And I’m not sure about the “better design” either. Java is a great server sideways, but for the desktop, I’m not that sure.
We “ported” an ISDN protocol monitor from C++ to java, it _runs_ fast enough, but takes 6-8 times startup time compared to the C++ version. And uses between 40 and 50Mb ram. C++ version runs at 15Mb. Not good unless one runs Big Boxes.
There were some studies, which show that you can can run FFT, linear algebra stuff as fast in java as in C.
I was very usuprised myself. But then, I looked for other bench like these ones, and most of them said the same : C is not better than Java ( striclty efficients issues ), thanks to heavy byte code optimisation, etc…
http://www.ukhec.ac.uk/events/javahec/pozo.pdf
.Net is not solid and efficient??? Have you actually coded with it? C# is an excellent language, with the .Net frameworks it’s also extremely powerful…it’s kinda like C that ‘just works’. I’m very pleased with it (pity only C++.Net creates Win32 compatible code as well as .NET IL).
First of all, I am not a fan of .NET. I don’t like it any more than Java. Well, it does support more languages and does have a better design, but it is still bloatware. Microsoft has a long way to go before .NET can be considered solid and efficient code.”
Good, at least you are wise guy, not amoung the losers who think that .NET is a wonderful MS innovation that will end the hunger in Etiopia and file your food nails among etc.
“My text editor comparison is to show one simple point — that a popular Java text editor touted for having good performance is a giant memory hog compared to the big gun native code editors. And also the comparison showed that Java is still slow at simple things like loading files.”
No, Eclipse is not a popular text editor. It is a complicated IDE. “J”, “JText” are more comparable with Slick Edit and Multi Edit. Even JEdit is very advanced for such a comparation. If you want to compare Eclipse with something, compare it with Visual Studio.NET calamity. That crap redefines the word “bloated”.
“As a user, I shouldn’t have to worry if my application is Java/.NET or native. It should work fast. It should respect my system and not hog up lots of memory. I am buying a programming tool to get a job done, not to worship at the altar of heap fragmentation.”
Yes, thats why Sun is optimizing it for years. I find Java 1.4’s speed and memory usage ok. The thing to consider is that on the hw camp, the computers are getting faster and 1GB is going to be a standard mem in a year or two. So, You will not be able to differentiate Java programs from native ones at all. Actually, I cannot differentiate Eclipse from native Windows applications on the Windows computer that I am working right now anyway.
“In many ways, Java has made cross-platform work WORSE. I say this because with Java programs, you are less able to take advantage of the neat features of the various platforms. You are less able to tune your app for the platform.”
Again, no sense at all. You say “Java has made cross-platform work WORSE”, then you say, with Java, “you are less able to tune your app for the platform.” So, are you able to tune your app for the platform at hand with the other cross platform supporting frameworks? : )))) (By the way, Java is ONLY framework that supports WORA. Even .NET is NOT WORA.)
The thing you say is completely wrong. Of course there are ways to tailor your application to the specific platform with Java. I wonder how much do you know about Java programming. For instance, MIDP is a Java API for Mobile programming. All the mobile firms, such as Nokia, Motorola etc. has extension APIs on top of MIDP, enabling to reach the device specific properties from Java. MacOSX has extensions to the standard Java classes to deal with MacOSX specific things etc. So, please investigate some before you write rather than making up.
“Face it, the vast majority of Java apps are not compiled to native code with some non-standard tool.”
This is because, there is no need for many of them. They are fast enough etc. : )) Being non-standard is not a bad thing in this case. Indeed, it is a good thing, since there are many 3rd party Java to Native compiler producers competing with each other on many platforms.
“For client software, there is NOTHING written in Java that is any sort of mainstream application. This is because Java is totally inappropriate for client software. Even in Eclipse all the widgets had to be written in real code (vs. byte code) and IBM had to reinvent J/Direct which Microsoft had made years ago to get good performance on Windows. And even with all this effort, Eclipse is still hefty and slow.”
Oh yeah? The reason is many applications that you use are already available written in other languages. But newly written applications now, are largely based on Java if they require WORA. For instance, Morpheus 2, Limewire, JEdit, Eclipse? There are many client side applications written with Java serving the very different businesses and they are indeed booming nowadays. Check out Swing Connection to see some great Swing app examples:
http://java.sun.com/products/jfc/tsc/sightings/S13.html
“For server software, Java’s problems are legendary as Sun’s own memos tell you. And as every big Java shop can tell you. When the apps get big, the whole thing shudders and shakes.”
Oh really? Then why the MOST successful open source effords in terms of server works such as Apache, JBoss etc are using Java? (I am not talking about Apache web server, but 30 or so Apache projects based Java). Then why all the web application frameworks apart from the MSs are based on Java? Check here to see the list of J2EE web application servers. It is ASTOUNDING:
http://www.javaskyline.com/serv.html
Then why there are so many Web Services implementations based on Java?
http://www.javaskyline.com/webservices/
“Java’s design is flawed and there are tons and tons of bugs. An out of control socket can bring down the whole VM. It is a joke. ”
Then why all these people and the biggest companies are pouring millions of dollars to Java? Michael, whatever you say, Java is working very well, and booming. : )
I have to wonder how come it’s now the number 1 language in CS courses. Must be good for teaching, at least,
If Java is so bad I wonder how come it’s the number 1 language in job requirements for programming, must be good for something more than teaching.
Of course it’s not the be-all end-all, there’s no such thing.
Can you people, who probably never even programmed in Java, stop bitching about how Java is slow and a memory hog? It’s not, not anymore.
If you think it is don’t use Java programs, but please stop saying silly things and comparing IDE’s written in Java to native text editors. That makes you look dumb, believe me.
Michael said: “It is that simple. Sun has no business upside in making Java small, speedy, lean, etc. The slower and fatter Java is, the more money Sun makes on hardware. And because Java is buggy as well as fat and slow, Sun’s consulting division is very happy.”
To which CroanoN replied: “Bwaaaaa ha ha ha ha haaaa! Thanks for posting this historical, the most idiotic comment ever written in OSNews. : ))))”
I don’t think what Michael posted is idiotic. Would you believe that a company as big as Sun could not develop a lean mean VM and nicer language, if it wanted to? [In fact, the Sun’s R&D lab used to develop a pretty nice high level scripting language called Self with a reasonable memory footprint and speed, IIRC].
Sun _is_, first and foremost, a hardware company. Java _is_ to some extent engineered to be the bloatware it is now, so it can create demands for better hardware (which Sun also sells). Microsoft does this too, you know (by plotting with Intel and now AMD).
Do you think that a big company like Sun would do such cheap tricks to earn small amount more money from selling memory and faster CPUs?
For Sun, the fame of Java and Solaris is much more important than couple of thousand of dollars that they would earn more by selling bigger memory a piece.
Thus, I still think that it is a very, very idiotic comment.
But it’s true, Sun could build a leaner and meaner Java engine. And I completely agree why they don’t, they sell big boxes, and so sell software that needs big boxes. You claim that the fame of Java and Solaris is more important, and I agree with you, but why would that fame be affected whether Sun can or can’t build a leaner VM? It doesn’t, Java would still have been as hyped up as it was before, only it probably would have lived up to some of the hype.
About WORA: the types of companies that Java solutions appeal to usually do a lot of in-house development anyway, so they have access to their own code. At least where I work, a trading firm, 99% of what we use we built, and we have migrated the same code (C++, mostly) from Solaris to Linux to Windows with not much effort. If you encapsulate correctly all the parts that are dependent on the platform, and keep using standards like IEEE or network byte order in cross-platform communication, then you can have the best of both worlds. You need to code right, but you need to code right in Java to get decent performance anyway, so what’s the difference?
Oh, and with regards to memory management, which seems to be one of the biggest selling points of Java after WORA. In my opinion at least, when dealing with both natively compiled and interpreted languages, is that having control of memory is one of the best features of C/C++, etc. My biggest gripe about this, actually, is poorly documented API’s that never make it clear whose responsibilty it is to free allocations, but besides that, I find it very comforting to be in total control (well, not total when using libraries, but pretty close) of my apps resource consumption. Buffer over/underruns, memory mangling, memory leaks, etc., just as with all other coding, can be almost eliminated with good practice. Might seem like a pipe dream, but we’ve managed it, which means anyone can. Also, nothing stops VM’s from having these problems, but at least with non-VM languages, you can do something about it. With VM languages, you got to wait until someone else gets their shit together for things to work.
After rereading my post, I noticed I come off as a but anti-Java. Let me clarify, I think Java has many benefits, but huge costs as well. If a company depends very much on developer time, and needs things done quickly, then Java’s very rich API and easy syntax makes it very attractive. Also, I’ve heard good and bad things about EJB, but I have had no experience with it, so I won’t comment.
I don’t doubt there are many more benefits besides development time. True WORA, I believe, is misleading, since as it has been correctly pointed out, when you go for the least common denominator (which you have to for true WORA), you lose a lot of the development goodies individual platforms provide ( I know I’ll get flamed, but Windows’ API, for example, is as powerful as it is messy ). I’m just saying that Java isn’t the only way to do WORA, it’s a quick way, but an individual’s or company’s cost/benefit analysis for using Java is usually based on more than just development speed (especially when you have developers on fixed salaries, and they go home to spend time with their families when they could be coding, for god’s sake
).
First of all, I thank you for your great replies. It is nice to come across with somebody here who is able to understand the issues, see the big picture, thus can create logical replies. : )
“About WORA: the types of companies that Java solutions appeal to usually do a lot of in-house development anyway, so they have access to their own code.”
I cannot understand whats the relation between WORA and owning the code. Can you please open it up a bit?
“If you encapsulate correctly all the parts that are dependent on the platform, and keep using standards like IEEE or network byte order in cross-platform communication, then you can have the best of both worlds. You need to code right, but you need to code right in Java to get decent performance anyway, so what’s the difference?”
The difference is that the things that you have to be careful is 1000 times more in C++. You cannot compare Java’s WORA degree, the speed of development, average bug count, and maintainability of the product (in a WORA manner) with C++. Java clearly wins.
Java also offers many other advantages over C++, if you consider that it contains many APIs related with networking, threading, Internet, GUI, etc, as standard part of the language. The developers do not need to learn these things for different libraries on the same platform (or on different platforms in case of WORA) for instance. There is no need for porting from one GUI to another, or from one threading framework to another etc.
C++ is more suitable for the jobs that really require critical speed and seriously low memory usage.
“In my opinion at least, when dealing with both natively compiled and interpreted languages, is that having control of memory is one of the best features of C/C++, etc.”
In the past, it was true, since you had to manage memory manually (pointer arithmatic etc.) to increase the speed, since HW was slow. I think, although they are obviously a must in some projects still, they are not really needed for 90 percent of the high level projects, since HW is fast enough, and they are number one source for hard to find bugs. Better not to have them at all. With Java, you cannot create a dangling pointer or memory leak. Hence, much less bugs.
“True WORA, I believe, is misleading, since as it has been correctly pointed out, when you go for the least common denominator (which you have to for true WORA), you lose a lot of the development goodies individual platforms provide ( I know I’ll get flamed, but Windows’ API, for example, is as powerful as it is messy ).”
I do not get that. I think, as Eclipse shows very well, the least common denominator is enough. If you need more, you can still use the additions to the Java framework for reaching the functionality offered by the specific platform at hand. For instance, Apple has extension classes to deal with the Mac OSX specific features over standard Java, as Microsoft had.
It isn’t Sun, thats for sure.
“I cannot understand whats the relation between WORA and owning the code. Can you please open it up a bit? ”
I can only speak from our experience, but having gone through two large migrations (and sun to linux is not as easy as it would seem, especially when you’re using a completely outdated GUI toolkit, OI, on one box), I can say that the biggest issues we had were unavailabilty of some core third party libraries on the new platform, which required rewriting from scratch, and the most insidious of all, when third party libraries were available on different platforms, they had completely new bugs in new places, and fixed bugs in places we had already worked around. That is a BITCH to find. Ownership doesn’t really save you from the first, since you’ll need to rewrite it anyway, but the second can take longer to work-out than rewriting the code yourself. It also takes a larger initial investment, but it’s definitely worth it in the long run. At least ( I don’t want to assume I know the answer to everyone’s problems) for us
.
Now, while I agree that Java wins in the WORA department, what I tried to say was that it is possible to make C/C++ portable. Not completely, of course, but maybe enough to decrease the cost side of that solution in your analysis. It’s up to each individual manager to analyze the problem set, the requirements, and the quality of the people he has available (INCREDIBLY important when dealing with C/C++, bad programmers and those languages are a horrible, disastrous mix).
Java, right now, is persona-nongrata in my company. A large part of the problem is that they wanted to use Java on the client side, on apps tha contain a ton of business logic, and SWT was too recent for it to be picked up, so everything was in Swing. We still have some EJB servers, but right now we’re in the process of redesigning our entire structure into a multi-tiered, service-based framework. Everything done in house, very exciting stuff. And we have managed to do it in a fairly short period of time, although that probably has to do with the outstanding coders we have.
Oh, a quick remark:
“With Java, you cannot create a dangling pointer or memory leak. Hence, much less bugs.”
Yes, but you can have dangling references which never get cleaned up by the garbage collector. And, accessing an invalid reference on a “destroyed” object (e.g., a closed database connection) is a form of accessing a dangling pointer. You can’t be completely rid of reference counting in Java
Well, I already agreed that you can make C/C++ portable. But it is, in general, 1000 times more difficult than Java, from both technical perspective, and difficulties related with finding capable coders. It also takes much more time. But as you said, it may be the right choice in rare situations. (Abundance of fantastic coders, time, availability of the required libraries on different platforms that are compatible (It is possible to implement some feature with some 3rd party library available on platform 1 and some library available on platform 2.), the unsuitability of the problem domain to the VM based environments etc.
“Yes, but you can have dangling references which never get cleaned up by the garbage collector. And, accessing an invalid reference on a “destroyed” object (e.g., a closed database connection) is a form of accessing a dangling pointer. You can’t be completely rid of reference counting in Java
”
You are right about possibility of creating objects that cannot be garbage collected, but those are not created by the user, but exists because of the uncompatibility between some problem domains and garbage collector based environments. There is no concrete solution to those. For instance, hash map developments in all the GC based environments suffers from the same thing. In general, your program is not effected as usual, they just waste space in the memory space of the JVM. Java 1.4 includes phantom reference, weak reference and soft reference classes, targetted to fight with those, and as far as I remember, the new garbage collectors provided in Java 1.4.1 fights with this issues to some degree.
“Yes, but you can have dangling references which never get cleaned up by the garbage collector. And, accessing an invalid reference on a “destroyed” object (e.g., a closed database connection) is a form of accessing a dangling pointer. You can’t be completely rid of reference counting in Java
”
Yes, I agree that null pointer is a form of dangling pointer, but there is a very important difference between dangling pointers which are not null pointers and dangling references of Java, that is, null pointers. In the former, your program may keep running assuming that the data it is reaching is correct. This leads to incredibly hard to determine bugs, and wrong calculations. You may not aware of them even for a long time. In case of Java, the program crashes. : )