JavaRanch Home    
 
This page:         last edited 16 February 2014         What's Changed?         Edit

Dont Sweat It   

(Level: beginner)

Every day on the the Java forums, we get asked lots of questions about things that really don't matter. Unfortunately, it can be a lot harder to explain why they don't matter than it is to ask the question, because:

  • It involves explanations that the poster is not yet ready for.
  • The rules are not well-defined (and sometimes not defined at all) by the language or virtual machine specficiations - very often, for good reason.

So this page is for all those frustrated posters who've been told "Don't worry about it". Be assured that when we do so, we're not trying to avoid the question, or sound 'superior'; in most cases it comes from bitter experience. There are some subjects that really aren't worth your time, or are simply a distraction.

It's highly likely that it will always be a "work-in-progress", and new topics may well be added from time to time; so feel free to revisit it if you're not getting the answer you want about something.

We can't promise to give you a satisfactory explanation for every topic, but we will try to explain why it's not worth worrying about - or, more specifically, why it's not worth worrying about yet.

We will also try to provide links to pages you can read for further information if you really feel you must. There's nothing wrong with intellectual curiosity; just be sure it doesn't distract you from what we assume is your primary goal - to be a good Java programmer.


TOPICS  



How big is an Object?  

The simple answer is: You don't know.

Some sites claim to show you how to calculate the size of objects, but these can only be used as a guideline. For one thing, the size will be different depending on whether you're on a 32- or 64-bit JVM, and may well differ between JVMs themselves.

Specifically, Item 2.7 of the JVM specification clearly states:

The Java Virtual Machine does not mandate any particular internal structure for objects.

so the only way to really know how much space an object takes is to create one and see how much memory is used before and after creation (this site shows you how). Unfortunately, even that can produce odd results, since it's quite possible for the garbage collector to run while your object is being created.

Furthermore, most modern computers have vast amounts of memory available to them. Even the average smartphone these days has around 256 megabytes, so worrying about whether a particular object takes 40, 50, or even a thousand bytes of space comes under the heading of "micro-managing". If your application is affected by considerations like this, the chances are that you (or it) has far more serious issues than simply how many bytes an object takes up.

The only thing I know of that often catches newbies out is that a Java character (ie, a char) is NOT the same thing as a byte. Specifically, it is a 16-bit value, so if you read a 1 megabyte text file into a Java program, the likelihood is that it will take up at least TWO megabytes of memory - still a drop in the ocean for most machines.

And again, if you find yourself worrying about things like this, the question you should probably be asking yourself is not "how much space does it take?", but "do I really need to read an entire file into my program?". Programs are not databases, and you shouldn't treat them as such.


Where is my Object?  

As soon as many newbies hear about the Java heap and stack, they start worrying about things like where are are, how they're used, and - worst of all - which is faster.

The fact is that memory - ANY memory - in a Java program is blisteringly fast. My clunky 7-year old Dell can create anywhere between 10 and 20 million objects a second, and creation is one of the slowest actions there is. On a modern machine, access time difference is likely to be measured in picoseconds - that's 10^-12, folks - so if you're trying to put values in the "right place" for speed, you're obsessing about something that simply doesn't matter.

Furthermore, in normal use, you have no control over where Java puts its values. The JVM will put them where it sees fit, and may well even move them around without telling you. To my mind, it's unfortunate that things like the OCJP exam make such a meal about this sort of stuff because, once you've passed it, the chances are you will never need it again. In 12 years of using Java, I have never once worried about whether an object or value is on the heap or the stack; and neither should you.

Create objects; use them; let the garbage collector clean them up. It really is as simple as that.

StackOrHeap is a page I wrote earlier that expands on this theme a little (and repeats some of what you've just read); but the simple fact is that this stuff is NOT important to most Java programmers. Concentrate on writing good, clear code, because that will solve more problems than you ever will by knowing exactly what the JVM does with your bits and bytes.


Why does Java do it this way?  

The bane of every JavaRanch contributor: The "why" question.

  • Why doesn't Java allow multiple inheritance?
  • Why are Java interface methods all public?
  • Why doesn't Java support operator overloading?

Questions like this usually fall into three categories:

  1. Why does Java do [something] a particular way?
  2. Why doesn't Java do [something] I think would be really useful?
  3. Why was [something] added to Java?

And in most cases (certainly the first two), the answer usually is: We don't know.

We might be able to guess - and in some cases we may well be right - but, without getting inside the minds of the people who designed the language, we can't be certain.

Let's deal with each of them in turn:

.

Why does Java do [something] a particular way?

This is probably the most difficult of all to answer because we're not mind-readers. In many cases, it will have been dictated by basic Object-Oriented principles, but in cases where the designers took one particular path when there were many to choose from, we're really in the realm of guesswork.

The only thing we can really offer are some possibilities:

  • Simplicity - this was a very important guideline for the designers, at least in the early days of Java development.

  • Familiarity - the style is easily recognisable for people coming to Java from other languages. This is almost certainly one of the reasons that a C-style syntax was chosen.

  • Safety - another important guideline for the early designers. One of the things we do know about Java development was that the decision to remove pointers (and in particular, pointer arithmetic) was a conscious one, designed to eliminate many of the errors that resulted from it in languages like C and C++.

.

Why doesn't Java do [something] I think would be really useful?

In many cases, these decisions were probably motivated by a desire to keep things simple. If you can give programmers a 98% solution without introducing a lot of extra complexity, why not? Yes, that means that some - usually obscure - things may be more difficult to implement but, in many cases, the alternative(s) may well be worse. I'm pretty sure, for example, that Java's decision to only allow single inheritance was made for exactly that reason (you might want to read up on the diamond problem) but, as I said above, I can't be certain.

And even if you can get definitive answers to questions like these: How does it help you?

The fact is that you can't do anything about it, so your only recourse if you don't like it is to lobby for change; and that might take time. In the interim, you're stuck with Java as it is, so my advice is to spend your time learning what it does do, rather than agonising about what it doesn't.

I also suggest that you examine the motives behind questions like these. If they're simply a gripe about why Java is different from C++, or C#, or some other language you're familiar with, then I suspect you're doomed to frustration. On the other hand, if you're genuinely interested in Java's development history, the best place to start is probably here - particularly, the first two chapters.

The page also includes some illuminating links, in particular this one, written in 1995, which suggest that the development of the language wasn't some "golden path" laid out by visionaries, but actually a very organic (some might even say chaotic) growth process. It therefore seems perfectly possible that some of these "why" decisions weren't actually the result of lofty ideals or lengthy consideration at all, but rather made for practical reasons like meeting target dates.

Even if so, it hasn't stopped the language from being a market leader for nearly 20 years, so perhaps the reality is that it does enough for the majority that use it.

Don't get me wrong, I'm not saying that these questions shouldn't be asked; just don't expect absolute answers. And don't spend all your energy barking at the moon - and I say that as someone who barks a lot myself.

.

Why was [something] added to Java?

Java has changed a LOT since its introduction: Swing, Generics, the Collections Framework, and Annotations being just a few of the major things that have been added.

Unlike the categories above though, pretty much all of them have been through a very thorough (and public) vetting process, so there is lots of information about the reasons for their introduction, including proposals and justifications.

However, in order to know why something was introduced, you first need to understand what it does; and for that, the tutorials are probably your best place to start. Indeed, it's highly likely that once you know what a particular addition offers, the "why" question will answer itself.

And if it doesn't? Find out when (ie, in what release of Java) it was introduced, and read the release notes - in particular the "new features" section. Both Generics and Annotations, for example, were introduced in release 5, and it's "features" page is here. You may still have a bit of hunting to do, but that's what Google was made for ... right?



CategoryWinston

JavaRanchContact us — Copyright © 1998-2014 Paul Wheaton