> I have to reiterate a gripe here- people are naming> feature requests, NOT gripes, without anything to back> them up! > > It doesn't seem like people are really getting into the> heart of working with Java or the JVM - instead most of> this thread is playing armchair language designer.

Well, I think a lot of that is because the main problems with Java are what it lacks, not what it has. And a lot of other people just want to point out why they think Java sucks. Not that that isn't a valid way to feel but it's not really the intent of the thread, I believe.

> > I have to reiterate a gripe here- people are naming> > feature requests, NOT gripes, without anything to back> > them up! > > > > It doesn't seem like people are really getting into the> > heart of working with Java or the JVM - instead most> of> > this thread is playing armchair language designer.> > Well, I think a lot of that is because the main problems> with Java are what it lacks, not what it has. And a lot> of other people just want to point out why they think Java> sucks. Not that that isn't a valid way to feel but it's> not really the intent of the thread, I believe.>I agree. I'm really trying to ask people who are programming in Java today what their pain points are. Not how it could be fixed, but what really are the problems? I've been thinking about this a few days and the only real pain point I honestly have is the verbosity that Java requires. The business cost of that pain point is it hurts my productivity. That verbosity comes in part from the language and in part from the standard APIs.

For those who have been complaining about things that are missing, that's not really what I'm getting at by "pain point." Those things you wish Java had sound like salves that you want to rub on to alleviate the pain. What is the pain, really?

> I agree. I'm really trying to ask people who are> programming in Java today what their pain points are. Not> how it could be fixed, but what really are the problems?> I've been thinking about this a few days and the only real> pain point I honestly have is the verbosity that Java> requires. The business cost of that pain point is it hurts> my productivity. That verbosity comes in part from the> language and in part from the standard APIs.> > For those who have been complaining about things that are> missing, that's not really what I'm getting at by "pain> point." Those things you wish Java had sound like salves> that you want to rub on to alleviate the pain. What is the> pain, really?

Well I see the lack of closures and function pointers to go right at the verbosity problem. I use anonymous inner classes as stand-ins for function pointers a lot and that's a lot of boilerplate code that has no real value in terms of readability. Every once in a while not being able to have use a closure causes me to have to write a bunch of ugly, confusing code.

The lack of a friendly reflective syntax causes a lot of pain because everyone uses beans and that means you end up with a lot of hard-coding or an external framework and code generators. This I don't hold out hope for because it would change the character of the language too much.

> I have to reiterate a gripe here- people are naming> feature requests, NOT gripes, without anything to back> them up! > > It doesn't seem like people are really getting into the> heart of working with Java or the JVM - instead most of> this thread is playing armchair language designer.

Well, good thing for them Java is being open-sourced and Gosling setup the "Kitchen Sink Language Project" (or something like that) so that people can create their own mini-forks of Java to demonstrate proposed language features for inclusion in the language.

So folks, get out of your armchair, stop complaining about missing features, and start hacking.

> So folks, get out of your armchair, stop complaining about> missing features, and start hacking.

And once I've done that, perhaps I'll rebuild my house to get rid of my gripes about a couple of the rooms, redesign my Peugeot to be more like a Porsche and maybe get my old soldering iron out and rebuild my hi-fi units.

The trouble is, what I want, in all these things, is something that has been designed and built by professionals and not something of the quality that I've knocked together myself in my spare time in an area where I have no experience.

> I agree. I'm really trying to ask people who are> programming in Java today what their pain points are. Not

1. Having to specify the maximum heap size on the command line. I have an application which uses variable (but considerable) amounts of both heap and native memory (via JNI). I have to guess a heap size in advance that will be big enough for the JVM and yet not so big as to crowd out the JNI stuff.

2. Verbosity. I'm split on this and even more undecided on the various proposed cures. Closures are an interesting solution, but I don't find then problem they address to be particularly painful. I think more irritating verbosity could be reduced by better designed api (and no language changes at all).

3. A few more minor irritations which don't amount to a major pain, so there is no 3! ;-)

> > I have to reiterate a gripe here- people are naming> > feature requests, NOT gripes, without anything to back> > them up! > > > > It doesn't seem like people are really getting into the> > heart of working with Java or the JVM - instead most> of> > this thread is playing armchair language designer.> > Well, I think a lot of that is because the main problems> with Java are what it lacks, not what it has. And at the same time, people complain cause Java is bloated. :)

> > So folks, get out of your armchair, stop complaining> about> > missing features, and start hacking.> > And once I've done that, perhaps I'll rebuild my house to> get rid of my gripes about a couple of the rooms, redesign> my Peugeot to be more like a Porsche and maybe get my old> soldering iron out and rebuild my hi-fi units. > > The trouble is, what I want, in all these things, is> something that has been designed and built by> professionals and not something of the quality that I've> knocked together myself in my spare time in an area where> I have no experience.

Ahhh, but I think that's the point. A bunch of people hack things a bunch of different things together, and then the professionals take it as inspiration.

> 1. Having to specify the maximum heap size on the command> line. I have an application which uses variable (but> considerable) amounts of both heap and native memory (via> JNI). I have to guess a heap size in advance that will be> big enough for the JVM and yet not so big as to crowd out> the JNI stuff.

I agree this is painful if you have to deal with it. In my experience, I've found that the problem here is that the JVM tends to be possessive and greedy. It will grab more memory as long as it's busy but then won't let go of it for a long while. This is a big problem if you have an app that needs a lot of memory up front and then releases a lot of it.

I think that this could be improved with some better JVM options. I have also found that the JVM tends to manage memory on Solaris than it does on say Windows, which shouldn't come as too much of a surprise. On Windows, the JVM appears to write unused heap to the page file and then read it back in when more memory is needed. I have to think it would be better to just release it. I'm guessing this is because the Windows paging operations are not visible to the VM.

Anyway, a VM option that would favor releasing memory over holding onto it or a way to set how long to hold onto unused heap would be a nice thing.

Just in case an existing setting might help you, here are some resources. It way very well be that what I mentioned above exists. There's a lot to parse here:

> Anyway, a VM option that would favor releasing memory over> holding onto it or a way to set how long to hold onto> unused heap would be a nice thing.

Something that would be nice would be a method to increase the minimum heap size of the current VM or otherwise indicate to just expand the heap when memory appears exhausted (i.e. don't do full GC). The problem arises when building a large data structure (say 500MB). If the VM starts out with a heap at the typical default (~ 8MB) and is then grown to 500MB it does a huge number of full GC cycles along the way. It is much faster if you specify a minimum heap size of 500MB up front, which is sort of OK if the application is being run by a Java guru, but less useful for something with more general release.

> > Anyway, a VM option that would favor releasing memory> over> > holding onto it or a way to set how long to hold onto> > unused heap would be a nice thing.> > Something that would be nice would be a method to> increase the minimum heap size of the current VM or> otherwise indicate to just expand the heap when memory> appears exhausted (i.e. don't do full GC). The problem> arises when building a large data structure (say 500MB).> If the VM starts out with a heap at the typical default (~> 8MB) and is then grown to 500MB it does a huge number of> full GC cycles along the way. It is much faster if you> specify a minimum heap size of 500MB up front, which is> sort of OK if the application is being run by a Java guru,> but less useful for something with more general release.

Kind of getting off subject here but have you tried using the throughput ocllector: -XX:+UseParallelGC? I thought there was an option to control the heap increase size, which might help too. The aggressive heap option would seem to fit but you can't set the max or min heap size with that option.

But I think we agree that the GC options do not give enough control. Actually, a being able to specify a detailed GC policy as a resource file would be better than trying to pass in the proper incantations of options. Personally I think the GC is too biased against allocating and deallocating memory from the OS. This causes a lot of problems for certain apps, especially in windows. There should at least be an option to reverse that bias. Allocating memory is much faster than paging. I used a Java app that would create nearly 1 GB heaps. Windows will page things to memory even if there is 800MB of RAM available. I think based on an LRU algorithm, which means unused heap gets paged. Then when the app needs to create some more Objects, all that memory is paged back in. When it's 500MB, it makes a big impact on the behavior of the application. The app should never have used that much memory in the first place but we work with the tools that vendors give us, not the ones we wish they would give us. If I could just set an option saying 'let go of memory that you haven't used in x seconds' this problem would be resolved, I think.

(1) strange rules (say, files must be named after the class, therefore they cannot be named anything that's not a valid identifier; and they must have a four-letter suffix (.java, .class) making it impossible to implement Java on something without long file name support -- and not that the long filenames do anything -- if I pass a file to the compiler, does it matter that it's named 'something.java'? And each .class file begins with '0xcafebabe', so '.class' is unnecessary; and the requirement that *everything* must be object-oriented, regardless of what the program does);

(2) Java's concern that "adding this feature would confuse programmers" (say, pointers, multiple inheritance, Generics that do something other than autocast, or anything not object-oriented enough) makes it a lot like Visual Basic with a C-like syntax;

(3) Willingness to claim C++'s heritage, but failure to learn from C++. For instance, Java did not start with namespaces (called packages), even though Sun's engineers have been used as an example of why namespaces are needed (a Sun engineer created a function called "mktmp" with the same signature as an internal function of a library he was using; sometimes the wrong mktmp would be called and since the two functions did different things, this led to a hard-to-track bug). Or Java's language designers are willing to give partial solutions to problems (say, Generics), but not solve the general problem (say, a good macro system that would handle what Generics, AOP, and what Generics could do if they were like C++ templates; "but that would confuse professional programmers"). C++ and Perl try to give programmers general solutions to general problems. Java seems to want to give partial solutions to specific problems.

> Or Java's language designers are> willing to give partial solutions to problems (say,> Generics), but not solve the general problem (say, a good> macro system that would handle what Generics, AOP, and> what Generics could do if they were like C++ templates;> "but that would confuse professional programmers"). C++> and Perl try to give programmers general solutions to> general problems. Java seems to want to give partial> solutions to specific problems.

Java claims heritage from C++ but as a simplification of it. Making it like C++ would defeat the purpose. If Java were just like C++, there would be no reason for it to exist.

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.

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.

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

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