Weblogs Forum - What Are Your Java Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 2 3 4 5 6 7 8 9 10 ... 18 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 11:26 AM

> Interesting topic
>
> My biggest, easily, is that there are lots of resources
> (database connections in JDBC and files are the two most
> common which you have to close explicitly (typically via
> try/finally). Its unnecessary and ugly and I've lost
> count of the number of projects I've gone in to debug for
> clients and found one of these is the root cause of the
> bug.

There's a solution to this. You just have to stop assuming RAII is the only way to manage resources. Using a functional-style design actually allows for better control than RAII.

> Enums: Why don' they operate properly with less than or
> equal to and greater than or greater than or equal to? I
> find this very odd and can see no reason why it can't be
> fixed.

1. Enums are not just numbers like they are in C. They are full blown Objects. The operators you mention only work with primitives in Java. You can make the enum implement Comparable but that probably doesn't solve your problem.

> Can the clonable interface have a clone method? Probably
> too big to change now but it is annoying.

I agree. This is dumb. It would be nice to have a new class that would have a generic return type too.

> Case statements not working on string – this baffles me.
> I can think of no good reason for it.

Case statements only work on primitives (except boolean) in Java. I believe the reason is that case statements are optimized and provide no benefit (in terms of optimization) for Objects. I agree that case statements are often useful for certain types of constructs and should be allowed to work with Object types. Maybe it's because the language designers don't want operators to map to the equals() method.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 1:48 PM

> Can the clonable interface have a clone method? Probably
> too big to change now but it is annoying.

Presumably it doesn't have a clone method so that a Cloneable class can define a protected or package private clone method. A common suggestion, that would still be feasible, is to add a Copyable interface which extends Cloneable and has a clone method.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 1:49 PM

> Case statements only work on primitives (except boolean)

And enums which are objects.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Why I don't like Java

Posted: Feb 13, 2007 2:33 PM

/* A lot of people complain that Java isn't really OO. Where do you get the idea that 'everything' must be OO in Java. You can write a program in Java without ever creating an Object if you like.
*/

But you cannot create a program without classes. You can't create a function outside of a class. You can't write a program without creating a class with a public static method named Main(). I don't know of any technical reason for this; it's just what Gosling says good programmers must do, and all Java programmers take him at his word.

Thing is, if I want to read in a comma-separated file, transform it, and put the result into a database, I want to write "open file; read each line; connect to database; foreach line, split on commas and insert into database XXX." I don't want to spend extra time encapsulating all those methods into classes, as if I'm so dumb I'll say "connect to database, Oh no! I forgot what I should do with a database!"

/* I don't know why people persist in claiming that Java doesn't have pointers. It does. It just doesn't have pointer arithmetic. ...

Are you saying you want pointer arithmetic? I've never heard a convincing argument for having it.
*/

I don't want pointer arithmetic so much as I want access to raw pointers or references. I don't want to have to remember the details about when the implementation will pass things by value and when it will pass things by reference. Instead I want to be able to control that.

/* [me] (3) Willingness to claim C++'s heritage, but failure to learn from C++. For instance, Java did not start with namespaces (called packages),

[response] This clearly isn't a pain point as Java has packages.
*/

Well, you shot me down there.

C++ made a conscious decision to use different syntax for static methods and run-time methods (that is, classname::static_method() vs. obj_name.method()). Java uses the same syntax. I realize Java may well have listened to C++ on this and decided against things, but I find beginning programmers get confused between when you can call static methods and when you can call regular methods.

My point isn't that Java's not like C++. My point is that Java made a lot of boneheaded mistakes (like not having namespaces from the beginning, or Java's original threading interface, or putting in finalizers which you don't have control of when they are called) that could have been avoided by reading the "Design & Evolution of C++." It's what I would do if I were making the successor to C++.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Why I don't like Java

Posted: Feb 13, 2007 2:35 PM

To clarify:

/* C++ made a conscious decision to use different syntax for static methods and run-time methods (that is, classname::static_method() vs. obj_name.method()). Java uses the same syntax.
*/

sould read "uses the same syntax for each, that is, Classname.static_method() vs. obj_name.method()".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 2:39 PM

> > Case statements only work on primitives (except
> boolean)
>
> And enums which are objects.

Yes, that's the one exception. But it's really switching on the enum's ordinal value or at least that was what Neil Gafter said was his plan at one point.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Why I don't like Java

Posted: Feb 13, 2007 2:48 PM

> But you cannot create a program without classes.

Oh my God, that takes 1 line of code.

> You can't
> write a program without creating a class with a public
> static method named Main(). I don't know of any technical
> reason for this;

Well, where else does the program start???

I hereby release the following into the public domain since it will make you so much more efficient.


public class WorksLikeFortran {
 
  // TODO - put all your variables here as public statics
 
   public static void main(String[] args) {
     // TODO - put your code here
   }

}

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Why I don't like Java

Posted: Feb 13, 2007 3:09 PM

> /* A lot of people complain that Java isn't really OO.
> Where do you get the idea that 'everything' must be OO in
> Java. You can write a program in Java without ever
> creating an Object if you like.
> */

BTW, this above basically BS. You can't really write a useful Java application without creating an instance of something or other. What I really meant was that you don't have to create custom Objects.

> But you cannot create a program without classes. You
> can't create a function outside of a class. You can't
> write a program without creating a class with a public
> static method named Main(). I don't know of any technical
> reason for this; it's just what Gosling says good
> programmers must do, and all Java programmers take him at
> his word.

Is there something specific about this that causes problems? It's just the way the language is structured. I can't create python code outside of a module. It's not clear why this is a pain-point to me. Classes aren't Objects and static methods in Java have basically nothing to do with OO. Where do you want to write your code? The main method thing, maybe it's not appealing to you but what makes it a problem?

In any event this seems more like a complaint that you would aim at SmallTalk or other language where everything is truly an Object.

> Thing is, if I want to read in a comma-separated file,
> transform it, and put the result into a database, I want
> to write "open file; read each line; connect to database;
> foreach line, split on commas and insert into database
> XXX." I don't want to spend extra time encapsulating all
> those methods into classes, as if I'm so dumb I'll say
> "connect to database, Oh no! I forgot what I should do
> with a database!"

I'm still not following. You can do this all in a main method. You can argue that this requires a lot of verbose boilerplate but that really has nothing to do with OO.

I would say that no matter what you think about Java, you are basically talking about a script above and Java is a terrible scripting language. I would use Python for something like that and I use Jython to take advantage of the many Java libraries at my fingertips (written by me or otherwise.) If you are saying that Java is not a good choice for things like that, I whole-heartedly agree.

> /* I don't know why people persist in claiming that Java
> doesn't have pointers. It does. It just doesn't have
> pointer arithmetic. ...
>
> Are you saying you want pointer arithmetic? I've never
> heard a convincing argument for having it.
> */
>
> I don't want pointer arithmetic so much as I want access
> to raw pointers or references. I don't want to have to
> remember the details about when the implementation will
> pass things by value and when it will pass things by
> reference. Instead I want to be able to control that.

There's not much to remember. Everything is passed by value. I can't think of how it could be any less complex than that.

> /* [me] (3) Willingness to claim C++'s heritage, but
> failure to learn from C++. For instance, Java did not
> start with namespaces (called packages),
>
> [response] This clearly isn't a pain point as Java has
> packages.
> */
>
> Well, you shot me down there.
>
> C++ made a conscious decision to use different syntax for
> static methods and run-time methods (that is,
> classname::static_method() vs. obj_name.method()). Java
> uses the same syntax. I realize Java may well have
> listened to C++ on this and decided against things, but I
> find beginning programmers get confused between when you
> can call static methods and when you can call regular
> methods.

This is a valid complaint. The Eclipse IDE will warn you when you are calling a static method as if it were an Object method for this reason. As long as you don't do that it's pretty simple to know when a method is static and when it is not. On the other hand it's not a problem that I've seen come up much. I can't recall any bug that I ever seen being caused by this.

> My point isn't that Java's not like C++. My point is that
> Java made a lot of boneheaded mistakes (like not having
> namespaces from the beginning, or Java's original
> threading interface, or putting in finalizers which you
> don't have control of when they are called)

I'm going to assume this is back to RAII. Personally I think RAII is overrated. I also think that the downsides of RAII are understated by it's proponents.

> that could
> have been avoided by reading the "Design & Evolution of
> C++." It's what I would do if I were making the successor
> to C++.

I agree that Java has had some boneheaded things done to it. I would argue that the lack of generics from the beginning and the lack of closures are the two biggest. The semantics of arrays is dumb. I think the whole JavaBean paradigm is fundamentally flawed. If they had just listened to Bill Joy, it would have been a lot better from the start.

But this thread is about the current pain-points. It's not about the mistakes that were made in Java 1.0.

Andreas Mross

Posts: 12
Nickname: amross
Registered: Apr, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 8:51 PM

To answer the original question:

1. Deploying applications to the desktop. It's amazing that ten years on there is still no standard / official/ well known way to create a "install.exe" / "install.rpm" / whatever Macs use. It can be done, just look at popular client apps like Azureus, Freemind or IDEA. I installed Azureus and only later realised it was a Java app. Nice. Why can't Sun make the same functionality part of the JDK so we can all use it?

2. Crufty / badly designed / buggy / incomplete libraries.
There is a general cruftiness with the Java libraries that has increased with each release. This is a big pain point, and I'm not sure if there is a solution to this. I would prefer an environment where deprecated features are removed and you are expected to update your application code if you want to use a new release. I like working with clean, sleek libraries where everything is useful. The Java philosophy on the other hand has been to support backward compatibility at all costs and leave the cruft around to steadily accumulate with each release. Over time, you end up with a nasty, messy room that needs a good cleanup.
Many of the Java libraries make it possible to do hard stuff, but hard to do common tasks (e.g. the sound and image libraries). I think this is mostly a result of lack of usability testing. The addition of a few well chosen constructors / factory methods / utility classes could go a long way in some of these libraries. How many times have you heard people complain about how hard it is to read a text file in Java? This can be fixed with a ten line utility method, so why doesn't Sun just add it?
The Java libraries were amazingly feature filled at version 1.2, but they don't seem to have grown much since then. Things like no usable Date library (in an "Enterprise" platform of all things) are puzzling. A little imagination as to what could be included in a standard library could go a long way. How about a Metric Units library? That would be cool. Or an Address class (internationalised, of course)? These are just examples of course, but it seems there has been too much focus on low level functionality(e.g. implement yet another XML parsing library) rather than on domain level abstractions. I would imagine there is a lot of reinventing the wheel out there in the real world.

3. It's painful to create event driven Objects. The Swing library uses this neat "addXYZListener" paradigm all over the place, but it requires a fair bit of boilerplate to implement similar features in your own code. Perhaps generics make this easier, but there is no well known, standard way to implement event driven Objects without boilerplate code (please, someone correct me if I'm wrong!). From what I gather, this may be one area where C# does things better?

Apart from these few gripes, Java is and always has been a solid, pleasurable environment in which to develop software. It's few shortcomings are frustrating, and I have a a general feeling that perhaps Java hasn't lived up to it's original potential. Like most things I guess!

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Why I don't like Java

Posted: Feb 13, 2007 8:59 PM

Let me try again.

/* [Me] But you cannot create a program without classes. You can't create a function outside of a class. You can't write a program without creating a class with a public static method named Main(). I don't know of any technical reason for this; it's just what Gosling says good programmers must do, and all Java programmers take him at his word.

[Response] Is there something specific about this that causes problems? It's just the way the language is structured. I can't create python code outside of a module. It's not clear why this is a pain-point to me.
*/

Today I wrote a ten-line Perl script that reads a comma-separated file and, after massaging the data, puts that info into a database. Most of those ten lines had to do with ODBC.

If I wanted to write a similar Java program, I'd need to create a scanner class to read the file, a transformer class to take the string from the scanner and massage the data, and then I'd cry because I'd need to write JDBC code. I suspect it would take fifty lines of code to do that, and fifteen of those lines would be needless infrastructure (class declarations, opening and closing braces).

The problem I was solving was an imperative, or at the least declarative problem. And Java lets me write imperative and declarative solutions, so long as I filter them through OOP first.

Of course, Perl lets me write OOP code when I want to; but doesn't force me to write that code when I don't want to.

Anyhow, writing fifty lines of code to do a ten-line job is a pain point similar to water torture. You slowly burn out typing the same thing over and over.

The issue about "public static void main" is that it must be in a magically-named file (named after the class). I can't name a file try.java, because "try" is a keyword and can't be a class name. I can't name a file 1.java, or 1goodTest.java because those aren't valid classnames. There's no technical reason for this restriction, it's just how things are.

/* Classes aren't Objects and static methods in Java have basically nothing to do with OO.
*/

That detour was my attempt to understand what you meant by "you don't need to create Objects." I misunderstod you, and so we can disregard that.

Although.

I want to transform data from my scanner before putting it in the database. I don't think those methods "belong" in the scanner class because the scanner's job is to read in data, not process it. So I create a class, and give it some forgetable name. I then realize that I don't need to create objects of type "transformer," so I make every method static. I don't see why this is better than simply having free functions like every other language has. Java programmers I know can never figure out why I would want methods not attached to classes: "the almighty Gosling says that this is the One True Way and Any Other Way would Confuse Programmers."

/* In any event this seems more like a complaint that you would aim at SmallTalk or other language where everything is truly an Object.
*/

I don't have any experience with Smalltalk. I plan on getting some after I really feel comfortable with Lisp and Felix ( http://felix.sourceforge.net/ ).

/* You can argue that this requires a lot of verbose boilerplate but that really has nothing to do with OO.
*/

Yes, water tortue style verbosity. No, it's not OO per se. But it's the "Java is an OOP language *only*" problem. Want to write something in another style? Tough luck. you can only do that if you can convert it to OOP.

/* [me] I don't want pointer arithmetic so much as I want access to raw pointers or references. I don't want to have to remember the details about when the implementation will pass things by value and when it will pass things by reference. Instead I want to be able to control that.

[Response] There's not much to remember. Everything is passed by value. I can't think of how it could be any less complex than that.
*/

My mistake. I run into issues trying to remember if Java does deep copy of objects and shallow copy of primitives or vice versa (that is, when can I say x = y, and when do I have to say x.member = y.member; x.otherMember = y.otherMember; ...). The rules seem to be based on the implementation. That is, Java 1.0 did it this way because of how Java 1.0 was implemented, therefore all versions of Java shall forever do it this way.

/* [Me] I realize Java may well have listened to C++ on [having different syntax for static and regular methods] and decided against [doing so], but I find beginning programmers get confused between when you can call static methods and when you can call regular methods.

[Response] This is a valid complaint. The Eclipse IDE will warn you when you are calling a static method as if it were an Object method for this reason. ... On the other hand it's not a problem that I've seen come up much. I can't recall any bug that I ever seen being caused by this.
*/

It doesn't lead to bugs, per se, but compile time errors. And then the programmer comes to me saying "I'm writing this static method, and I want to call this non-static method, and the compiler won't let me." Then I've got to explain things. It's a pain point to me to have to teach other programmers to distinguish between two different thing that look identical (called through the dot operator).

/* [other gripes I have about Java]
[Response] I'm going to assume this is back to RAII. Personally I think RAII is overrated. I also think that the downsides of RAII are understated by it's proponents.
*/

Not RAII, per se. It's about the language designer putting in finalizers, selling them as being useful for RAII, and not realizing the garbage collector would muck up any attempt to use finalizers for their intended purpose. Finalizers were not thought out, and I have never seen a good use of them in Java.

Finalizers should be pulled from modern releases of the language. You can't guarantee when they'll run, or if they will ever run. So they are nothing more than a function the system may or may not call automatically. And they have the special case that they can resurrect the object, and the system promises not to call the finalizer the next time it collects the object. That's a lot like Javascript (as a dynamic language) sometimes doing type coercion on numbers to make them strings behind your back.

And since finalizers don't do the job for you, yes, another pain point is remembering to write the needed try { ... } finally { ... } blocks.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 9:34 PM

> The thing to remember is that ultimately Java development
> is not that slow.

So you are saying that the language is such a drag that it only *seems* like everything takes forever?

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 11:14 PM

> 1. Deploying applications to the desktop. It's amazing
> that ten years on there is still no standard / official/
> well known way to create a "install.exe" / "install.rpm" /
> whatever Macs use.

Yup. Unbelievable. And as I mentioned in my earlier post, support for visually developing applications is barely there (and that too only recently with NetBeans and Matisse). This makes Java/Swing nearly hopeless for quick prototyping. Not only can you not get a simple data-bound GUI protyope running quickly, there's no nice way to package and deliver it to the customer.

> Many of the Java libraries make it possible to do hard
> stuff, but hard to do common tasks (e.g. the sound and
> image libraries). I think this is mostly a result of lack
> of usability testing.

Unfortunately, somewhere along the line, the fact that developers are end-users of a language seems to have been lost in the quest for abstractions. For example, consider the IO stream libraries: Its design is great when you need to manipulate individual characters or decorate several streams, but for something as simple as reading a whole file into memory in one go, do we really have to care about writing our own read loop, checking for EOF markers and closing the stream? .NET does this very nicely: by providing convenience methods for reading complete files.

To me, all of this indicates a failure in black-box abstraction. Too many of the patterns and abstractions used in the implementation of a library are exposed to the developer, who most often don't require that level of detail or complexity. It appears that the libraries should instead provide higher-level facades, with the ability to reach their innards when necessary.

Secondly, there is a failure, as Joel Spolsky says, to provide "reasonable defaults" and the designers have deferred certain decisions to end-users. A good example is the JVM memory heap issue. As far as I'm concerned, the JVM ought to use as much memory as required by my program, not ask me to guesstimate how much I might need. Again, this is a scenario that the .NET VM deals with beautifully. It doesn't ask at all.

All of this boils down to a single problem IMHO. The Java camp is too engrossed in design abstractions and idealism, but fail to perceive usability aspects, which is where Microsoft/.NET (always) succeeds. How else can one explain the success of a boatload of crap like VB? It's ugly and illogical, but very easy to use.

A few more examples for this:
1. First class support for component based programming is missing, something that C# deals with very well. Stuff like annotations, properties and partial classes were all added to C# to provide visual development and tool support. Java's support for this has been awful (JavaBeans anyone?).

2. Data binding support for Swing controls: The MVC design in Swing is all very nice and cool, but if you have to jump through hoops trying to create the necessary data models for each type of control, when you know that one can press next to get this done in C#/Windows Forms, hardly gives you any incentive to use the technically superior Swing libraries. Again an example of not dealing with end-user issues despite having a superior design.

My examples maybe somewhat Swing/desktop-centered, but I think it's indicative of the general problem. I'd like to know what others feel about this stuff.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 13, 2007 11:24 PM

Excellent analysis. I couldn't agree more.

Especially the OS integration part hasn't been mentioned. It starts with simple things like finding out the free disk size and ends with things like using a system scheduler or scheduling a program to run after a reboot - those are all things you need to do when you write a non-trivial software update mechanism.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Why I don't like Java

Posted: Feb 14, 2007 2:57 AM

> can't be a class name. I can't name a file 1.java, or
> 1goodTest.java because those aren't valid classnames.
> There's no technical reason for this restriction, it's
> s just how things are.

This rule makes it trivial to locate the source for class. Something which can be quite tedious in C++, where the programmer can scatter the methods of a class all over the place.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Why I don't like Java

Posted: Feb 14, 2007 6:06 AM

/* [Me] I can't name a file 1.java, or 1goodTest.java because those aren't valid classnames. There's no technical reason for this restriction, it's just how things are.

[Response] This rule makes it trivial to locate the source for class. Something which can be quite tedious in C++, where the programmer can scatter the methods of a class all over the place.
*/

So it's not a technical reason, simply a "I think it's best to do it this way, therefore Everyone Must Do It This Way." I don't usually want to name a file 1.java (unless it's in a directory, of say, tests; where I then need to name it test1.java), but I don't see why Gosling should *force* me to name my files according to his rules.

As for finding methods in C++; cscope was developed for that, but I've always found grep to do the job. Additionally, in code that I write, I simply don't scatter things around because that's annoying (any more than I overload operators with nonsensical uses). I gather things together in ways that make sense logically, regardless of the class hierarchy. In fact, my complaint is that Java's rules make it just a little harder to gather things together in one file. Java's rules encourage organizing your source according to your class hierarchy regardless of whether that makes sense for any particular project.

Flat View: This topic has 264 replies on 18 pages [ « | 2 3 4 5 6 7 8 9 10 | » ]

Previous Topic

Next Topic