Java limitations

[Joe Yvarra]

I'm new to java and I was wondering if there are any limitations to what Java can do?

Thanks

[L Foster]

Hi, @Joe,
I am very experienced with Java. This question of 'limitations' is always tricky. People who are strongly motivated can make any language do a lot of things the designers never thought of.

That being said, I work with a mix of people. Some are avid Java fans, and others have had (this greatness) thrust upon them. From them, I frequently hear about what they miss about other languages. And, I have used other languages in the past. Some of these limitations I'll list were put there on purpose, to make it more difficult to make mistakes. Java's original drives were something like Productivity plus Internet.
* There is no unsigned. There are only signed byte, int, short, and long values. This can be impactful if you have to interface with other languages via JNI (including the use of OpenGL).
* There is no multiple inheritance. This was deemed a bad idea by the originators, because they felt it got people into a lot of messes. Truly advanced programmers (of C++, etc.) dislike this. Java has a workaround: you can implement multiple interfaces. Since nowadays we like to delegate before borrowing functionality through inheritance, you might consider this a blessing (or not, depending on previous background).
* There are no direct-memory pointers. This was a big cause for errors in the C/C++ - only days. It made buffer overlfow problems more likely, or overwriting your own code, etc. Working directly with hardware (memory-mapped IO and such) would require using JNI (anyone: please correct if you know another way).
* Java uses garbage collection, rather than allowing/forcing you to allocate memory. Hence you give up some control. Earlier iterations of JVMs had problems with the whole system seizing up while this took place (a bit like someone telling you to stop work so they can empty the trash cans). Later JVMs seem to handle this better, and unless you are doing Real-Time, it probably won't be a problem.
* There used to be a warning issued about not using Java for Nuclear Reactors, etc. (it's the Garbage Collection issue).
* If you like to assign stuff to variables, and interpret the contents as an integer one minute, a string the next, too bad. That's Python, or maybe Perl. Java is strongly typed. That is intended to ward off some of the more common errors, like mis-interpreting what you had placed into a variable earlier.
* On smaller devices, you may not have enough memory. A Raspberry Pi with a tiny SD card might not run a lot of Java programs. These small devices, however, seem to get bigger and bigger--rather like small Japanese cars. To install a JVM requires quite a bit of storage space. The Java folks are aware of this and plan to make more targeted deployments possible. Probably Java 9??? I have been programming Java since 1999. Back then, I had a 512Mb (same as the previous generation RPI) desktop computer, which ran Java fine.
* Limitation or not: Java does not have the same byte-order in its integers as a lot of the world. They call it "Network Byte Order". Some of my friends call it "Sun Server Byte Order".

My disclaimer: I may have made these look a bit like Persian Flaws. That is because I have dedicated a lot of my life to studying and working with the language. The biggest pain I have seen has been with byte-order and lack of unsigned ints. I have programmed Java on things as diverse as massive servers, ancient desktops, Android, a Raspberry Pi, and a Palm IIIe (KVM). Nothing has stopped me yet. But then, I never tried using Java on an Arduino.

[Paul Clapham]

Let's look at it from a different point of view: you can't really use Java to hack your Windows operating system. If you wanted to write a keystroke logger, for example, you can't do that in Java. You can't easily use Java to make a duplicate image of your hard drive. In general, low-level messing around with hardware and other software isn't Java's thing.

[Jason Bullers]

Not really limitations on what the language can do, per se, but they are points of annoyance that I've run into regularly working with the language. They're more about philosophy and language design than what you can accomplish by coding in Java.

The first touches on the multiple inheritance point that L Foster made. There are definitely many places where delegation is the better solution over inheritance. How I wish the language made it easier for me to take that approach than to take the inheritance approach! There's no direct support in the language for delegation like there is for inheritance, so that means it's up to you to write all the delegating methods. And then if the interface changes, you get to go and do it all over again.

The second is with regard to mutable versus immutable objects. There are many cases where I think mutable objects are overused in Java programming, and where immutable objects would both simplify program design and understanding, as well as reduce the likelihood of certain categories of bugs. Unfortunately, Java makes it easier to create mutable objects than it does to create immutable ones.

Which brings me to my third point: vanilla Java tends to be on the verbose side. New language features like the diamond operator in Java 7 and especially lambdas in Java 8 are helping to combat this problem, but there's still a lot of fluff sometimes. One nice thing is that the Java ecosystem is quite large and mature, and there are some powerful tools (like annotations) at the disposal of a Java dev. This means that there are libraries out there that help make up for at least some of these warty parts of the core language and APIs.

[Stevens Miller]

L Foster wrote:* There is no unsigned. There are only signed byte, int, short, and long values. This can be impactful if you have to interface with other languages via JNI (including the use of OpenGL).

This is my biggest sense of a limitation in Java, because I do image processing. The (endless, it sometimes seems) justifications for the absence of unsigned native types all appear to come from (surprise!) people who don't need them for whatever it is they do. They tend to write off the need for unsigneds as being confined to people who do network programming or file system work (as though neither of those things really matters, but just try to use your computer without a network or a file system). Those of us who fiddle with pixels at an intimate level really feel the impact of not having unsigned bytes, but I have yet to see even one Java apologist indicate awareness of image processing. They always mention networks and file systems, and then jump to arrogant speeches about how unsigned types are too confusing for programmers to really understand, so the benevolent Java overlords decided to save us from our ignorance and not let us play with toys that we would only use to hurt ourselves. It's a crock and a truly bad move, but we're stuck with it.

L also mentioned the lack of direct pointers. Again, if you do image processing, that's kind of annoying. Now, L also mentioned JNI, which I use a lot. If you need to manipulate an image, using unsigned bytes and real pointers, one way is to write your image processing code in C, and simply "jump" the bridge from Java into C, do your image work there, and jump back. Alas, the JNI is a bit complicated. Once you master it, you can almost ignore it, but it is a bit hard to master. Maybe that's because not a lot of programmers use it (because it is hard to master ), so good guidance on using it is hard to find.

I bring up the JNI in particular, and in connection with image processing, for another reason, though: If your image originates in Java, and you want C to process it, you don't avoid the problem of copying the image buffer just because you used C. The Java standard library includes methods for passing big buffers to C (or whatever language you use to do your JNI work), and, allegedly, you can pin down that buffer so it won't move while your C code expects it to stay in one place. That part works fine, but the library also lets you at least ask to have the buffer passed directly, not as a copy. Alas, you can only ask, not compel. When you pass a big buffer and ask that it not be copied, you can also query to see if you got the actual, original buffer, or a copy of it. Every single program I have written indicates that I always get copies. This means that, if I want to pass a 1280x720 image, with four bytes per pixel, I incur the needless overhead of copying about 3.7 megabytes from Java to C, then copying another 3.7 megabytes from C back to Java, for every image. If you do real-time video work (like I do), that's not trivial. It takes about a millisecond, each way, and I only have 33-1/3 milliseconds before the next frame arrives. Losing 6% of my time to pointless copying is maddening, especially when the library writers knew enough to let me at least ask to avoid it (implying they understood there were reasons a person would want to), but apparently didn't plan on ever honoring my request (because, you know, I'm probably ignorant and will only hurt myself if allowed to do what I want).

The lack of pointers comes from the fact that Java is a "managed" language, meaning that it deallocates its own buffers, relieving you of the obligation to do so. I have written thousands and thousands of lines of C code, and can confirm that pointer and buffer issues can be difficult to solve. Having Java mop that stuff up for me is nice. Until it's not, which it isn't when you need to work directly on a lot of data (like in an image).

In sum: I agree with the others here who say Java's limitations are felt when you need unsigned native types, want to do pointer arithmetic, or work directly with hardware. Most of those limitations can be overcome with the JNI, though that just means that maybe you should be working in another language to begin with. If those things don't impede you, Java is a great language. It's free, there are a lot of good IDEs that are also free, the library is fulsome and amazing, there is a vibrant community of users who will help you, and it is the most popular language of our era. If you are sloppy with pointers and buffers, Java will save you from yourself, most of the time. It's support for multi-threaded code is (particularly as of Java 8) mature and fairly easy to use.

What kind of stuff are you doing?

[Winston Gutkowski]

Joe Yvarra wrote:I'm new to java and I was wondering if there are any limitations to what Java can do?

A few things missed out by my esteemed colleagues:

A standard decimal type. Java does have BigDecimal, but it's incredibly clunky. And SLOW.

A data retrieval syntax - cf. Progress.

Fully typed arrays.

MultiMaps.

An ordered List (eg, a Skiplist), as opposed to a Set.

Typed inheritance.

They're all non-essential, apart from possibly the last, which is my own "term" for something which I think the language really could do with - the ability to implemented a typed interface for more than one type. Unfortunately, I don't think we'll get it any time soon.

My 2¢.

Winston

[Stevens Miller]

As ever, Winston is correct. I'd add, though, that most of his observations relate to omissions not so much of Java, as of the standard library. To that extent, those omissions are both limitations and opportunities, since, although they don't exist, you can write your own classes to add them. In fact, despite the snide treatment given to unsigned native integer types in the past, the latest release of the standard library provides more support for unsigned bytes than ever before, which means that this glaring omission in the language itself is being (somewhat) addressed by extensions to the library.

A conceptual challenge for new Java programmers, I think, is in distinguishing between the language (which is moderately complex) and the library (which is typically at least rococo, and often baroque).

So, we now have, in the library the Byte.toUnsignedInt method, which "supports" treating bytes as unsigned values. Thus, this code:

        byte b = -3;
        int i;
        
        i = Byte.toUnsignedInt(b);
        System.out.println(i);

prints "253," which is what you would want if b were an unsigned byte.

However, before the celebrations begin, this code:

        byte b = -3;
        int i;
        
        i = b & 0xFF;
        System.out.println(i);

prints the same thing, and has been the standard trick used by those of us who are foolhardy enough to enter the serpent's lair where the unsigned bytes run wild, fire in their nostrils, talons of steel ready to shred us simpletons into gobbets at the 128th opportunity.

And here's the rub: that "& 0xFF" trick is all the Byte.toUnsignedInt method does. It merely installs into the standard library an ugly workaround for dealing with unsigned bytes that never should have been necessary in the first place, which, to me, makes law of the fact that people do use unsigned bytes and that the language needs this crutch to get around the omission.

Now, I say that's "all" the method does, but that's not quite true. Here's the actual source:

    public static int toUnsignedInt(byte x) {
        return ((int) x) & 0xff;
    }

As you can see, it uses the standard work-around, but now you are calling a subroutine to do it, instead of putting it into your code in-line with everything else. I don't know if the compiler can optimize that away, but I don't think I want to even worry about it. (Can anyone think of a reason why that integer cast is there?)

So, a lot of what people call "Java" is really not the language, but the library. For me, at least, learning what's available to me there has been a bigger task than learning the language itself. I suppose one could even say that, in a way, a "limitation" of Java is the need to study the library for a while, in order to avoid writing something you don't need to write, and to avoid using the "wrong" library classes (as many still exist, are not deprecated, but have been superseded by better alternatives). To some extent, this problem exists for all mature, current languages, but I never felt quite so intimidated (and, at the same time, exhilirated) by a standard library as I have been by Java's.

[Campbell Ritchie]

Winston Gutkowski wrote:. . . Java does have BigDecimal, but it's . . . SLOW.[/list]. . .

It might be clunky but it isn't slow. It is simply slower than double arithmetic, which we all know sacrifices precision for speed.

[Winston Gutkowski]

Campbell Ritchie wrote:It might be clunky but it isn't slow. It is simply slower than double arithmetic, which we all know sacrifices precision for speed.

I was actually thinking of something more on the lines of an SQL Decimal that allows us to define an object like a Decimal(10, 3) with limited precision. I assume there are already many existing implementations out there, and it seems to me they would probably be quicker than BigDecimal.

Winston

[Campbell Ritchie]

I know there is an IBM decimal arithmetic project, and C# has a decimal “primitive” (or more precisely had it ten years ago), so yes, there would be all sorts of other ways to implement decimal arithmetic. I am sure the SQL type is quicker, but you have all the overhead of database connectivity.

[Winston Gutkowski]

Campbell Ritchie wrote:I am sure the SQL type is quicker, but you have all the overhead of database connectivity.

Erm, I was thinking of something more on the lines of a java.lang.Decimal class with an (int, int) constructor rather than doing a jdbc connection to use SQL's.

Winston

[Campbell Ritchie]

That would be quicker. But would you want that class to be immutable?

[Winston Gutkowski]

Campbell Ritchie wrote:That would be quicker. But would you want that class to be immutable?

Or maybe have mutable and immutable variants. I prefer immutables, but not everybody agrees with me (as you know ).

If it was up to me, I'd probably have it implement Number as well - ie, make it like another "numeric wrapper".

Winston

[Paul Clapham]

Campbell Ritchie wrote:It might be clunky but it isn't slow. It is simply slower than double arithmetic, which we all know sacrifices precision for speed.

No, that isn't really the tradeoff. It's more like "Floating point is to Decimal as Engineering is to Accounting". If you need a moderate number of significant figures in a large range of values, then floating point is a better choice. Whereas if you need exact values in a relatively small range, then decimal is a better choice.

[Campbell Ritchie]

Engineering? Now that is a good analogy. In my undergraduate days they told the story about the mathematician who was put 6 foot from his girlfriend and told they can halve the separation between each other every 30 seconds, and do whatever he likes when they reach each other. He collapses in tears of frustration. They did the same to an engineer, who halved the distance about 12 times and said, “Well, that's touching, near enough!”.

In those days the definition of an engineer was somebody whose response to,
“What's 2×2?”
… is to get out a slide rule (that dates me) slide 2 and 2 together and … “2×2? 2×2? That's 3.99, well that's 4, near as makes no difference.”

[Stevens Miller]

Campbell Ritchie wrote:In my undergraduate days they told the story about the mathematician who was put 6 foot from his girlfriend and told they can halve the separation between each other every 30 seconds...

I was a physics major. In our department, we told this version:

An engineer, a mathematician, and a physicist (all males interested in females) are put at one end of a hallway. A beautiful woman (interested in males) who is really into academic types is placed at the other end. The master of ceremonies states, "I will ring this bell every ten seconds. Each time I do, you may cross half of the distance then remaining."

The engineer shouts, "Wahoo!"

The mathematician wails, "But we'll never reach her!"

The physicist growls, "No, but we'll get close enough..."

[Joe Yvarra]

Thanks everyone the jokes were to funny, all the information that each one of you have given me has been really helpful.

[Campbell Ritchie]

Stevens Miller wrote:. . . The physicist growls, "No, but we'll get close enough..."

Maybe he was a quantum physicist; after about 3 or 3½ minutes he will be so close that quantum tunnelling can occur. And I am sure such tunnelling would be quite pleasant!

Careful I don't send myself to MD for these jokes.