Believe it or not, but the latest is that they're actually going to release it this year. Not that there's a JSR yet, but don't let that destroy our hopes ;)

It's true that Java doesn't has a direct syntax to do that, which indeed may be a shame. But it's also not absolutely necessary. In the UI layer for example and increasingly in other parts of the code, Java uses an expression language (typically abbreviated as EL).

With EL in Java, I basically do precisely that. E.g.

T getFoo() { return foo; }

And then in the view definition e.g.

<h:outputText value="#{myBean.foo.some_call()}" />

Because of the usefulness of this, there are various efforts going on to support EL in more parts of Java than just the UI.

Sadly this is true, and an unfortunate consequence from the fact that Java added generic support relatively late in its life cycle. This opens the door to some very awkward corner cases.

That said, the benefits of such a sub-optimal generics implementation for me still far outweigh the disadvantage of not having any generics at all.

Also, don't forget that C++ templates not only are a whole different beast, but they actually have issues too. Not in the least that they function more or less as type factories, that produce different types for a different T, that are in no way related to each other. Maybe the situation has improved lately, but I remember that the compiler would generate a complete new list definition for each T I used it for. Ouch!

Sure, and I've seen long haired tattooed weirdos not knowing the first thing about correctness, stability or consistency of their code, and where basically every other class of theirs has a different layout and does similar things in a different way. You know, the kind of code where they store an image in the root folder as /tmp.png with the excuse that 'it's very unlikely that 2 people upload an image exactly at the same time'. Yes, I've heard those 'cool kids' uttering stuff like that.

Just because you are a 'cool kid' does not necessarily make you an intelligent, well thinking developer.

Exactly ;)

[...]

Hold on there for a sec. PHP is an advanced technology? Really??? Crap like this http://lwn.net/Articles/379909/ is what 'advanced' technology is about?

PHP is basically JSP with plain Java SE on it, and a rather poor version of that approach that this. It's perfectly suited for Joe's Burgers 4 page website, but when something more 'advanced' is needed, PHP just doesn't cut it.

For instance, the platform offers zero provisions for any form of concurrency. There is not even something like the basic threading support that Java has had since 1.0, let alone that there is any support for simple asynchronous execution (e.g. the @Asynchronous annotation) or highly efficient parallel computing paradigms like a fork/join framework. And what about an O/R mapper that comes with Java by default? How about dependency injection? What about declarative transactions? What about transactions that automatically span multiple method calls and multiple transactional resources?

Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there ...

And I can produce results a hundred times as fast by using Java EE/Java/JBoss AS than with Django/Python and surely PHP. I'm not sure what this proves though... Also, don't forget that hacking together stuff and throwing it out is nice when you're 16 and in high school, but in the real world maintainability, correctness, stability, scalability, etc etc all count and in the end are way more important than just the ability to get some prototype like code out of the door, that 'usually-works-but-breaks-down-every-tuesday-when-it-rains'.

On top of that, Jodatime (or rather a slightly modified version of it) is slated to be included in the standard library of Java 7.

It does indeed gets a tweak a little like this. You still have to write out the declaration in full, but there's a shorthand for the generic part of the right hand side: ArrayList<SomeObject> myList = new ArrayList<>();. It doesn't look like a major improvement in this example, but when there is a lot of generic type information, it can surely help.

Because:

• They prevent you from inserting a type in a collection that shouldn't be there? Good luck trying to put a battleship in a collection of pencils. It won't fit with generics and it shouldn't fit.
• They take away the need for guessing and down casting anytime you retrieve something from a collection.

There are some other reasons though, not all generic usage is for collections, but these are two major use cases.

No they're not. Maybe unfortunately, but they don't even work with primitives in Java.

Java is currently primary used server side. I'm not sure what kind of code you write, but if we need to restart the JVM once a month it's already a lot. A few seconds doesn't really matter when the uptime of your server is at least weeks, but more likely months or for 'finished & stable' software maybe even years.

Well, to be honest they actually seem to disrespect themselves even less ;) If you can read Dutch, take a look at this: http://www.amsterdamcentraal.nl/archief/2010/3/23/je-moeder#c especially the comment made by henk @ "25 maart 2010 20:03 uur".

In addition to that, cyclists in Amsterdam are notorious for this kind of anti-social behavior. Try to visit some cities in the direct surroundings of Amsterdam (Haarlem, Utrecht) and you'll find a whole different atmosphere.

Hey, thanks man! We houden ook van jullie hoor. ;)

Polite Europeans huh? Guess you never had to jump away for a bicycle approaching you at high speed while you were at the middle of a pedestrian crossing in Amsterdam! :P

Yes that's true. My main point is simply that the situation isn't as black/white as saying that either using frameworks or using hand crafted code is always better for performance. It depends really and the ability of an engineer to chose and use a given framework wisely is an important asset. Some bigger frameworks like Oracle's Coherence can absolutely improve performance too, while some home cooked solution may never obtain the level of performance that Coherence has, simply because you are maybe just not a good a programmer as Cameron is. But blindly applying Coherence for each and every problem simply because you heard "it's good for performance" of course doesn't work. But I doubt a programmer who thinks like that is capable of writing anything efficient himself anyway ;)

It depends. Sure, there are some models out there which are quite hard to beat. I surely won't underestimate the lurking power of certain cloud or grid offerings. Yet, IMHO it's naive to think 'the cloud' will just fix all your problems for you.

For starters, you might have a single query and a DB that can't run a single query in parallel (like Postgres or MySQL) which is already executing on the fastest hardware available. We for instance have a DB running on a dual socket Nehalem based server (8 cores), running at some 3.4Ghz with 4 Areca 1680's (each with 4GB of cache for a total of 16GB) and 32 Intel X25-E SSDs (8 per Areca). I dare you to come up with a faster machine without stepping into a completely different price category. You know, the kind of category where prices aren't listed anymore but sales representatives visit your office to negotiate a deal.

At the moment, there simply isn't a faster DB available and even the hugely expensive IBM POWER offerings are only a factor or so faster for our kind of workload. So simply buying a faster machine is absolute not an option, even if we had money to burn (which incidentally, we haven't). So, if I can optimize some piece of code in 30 minutes, maybe even less, why shouldn't it do that? It's basically as simple as turning:

for (Customer customer : customer) {
BigInteger companyRevenue = rewardService.getMontlyRevenue();
// ... customer specific calculations here
}

into

BigInteger companyRevenue = rewardService.getMontlyRevenue();
for (Customer customer : customer) {
// ... customer specific calculations here
}

Why shouldn't I grab that low hanging fruit, yet pursue on a mission to find a faster machine since Blakey Rat on /. told me that software optimizations, no matter how trivial, never pays of? That would be rather silly, wouldn't it? On top of that, you seem to forget that a new & faster machine even if would exist doesn't magically fly into service. Real people have to order it. Real people have to install it with something, real people have to test its stability, real people have to place it into some rack, etc. All of that costs money, time and potentially worries too.

It is surely not my intention to insult anyone, but if you read back my post then you might see that I mentioned what I said was true particularly for web sites, not exclusively for web sites. Although there is a big difference between interactive and non-interactive payloads, at the end of the day a batch job should not recklessly consume resources either. Just because batch jobs can be queued and can be run right after each other, doesn't mean there isn't someone waiting for the result. Worse yet, if batch jobs are submitted to your queue at a certain rate and your system can only process them at a lower rate because of some completely unnecessary resource hogging, then eventually your queue will spill over. Your DB may still not be offended, but a slow turnaround and a denial of accepting new jobs surely will offend customers again.

Now you'll probably say that I simply need to throw more hardware at it and that batch jobs by their very nature can always run in parallel on multiple machines, but this is certainly not true in general. In order to make that possible you need to carefully craft your software architecture, which takes... guess what... engineering effort. If you're really so reckless that you're throwing around 100,000,000s of queries, then you need more than a little bit of engineering effort to cope with that. At such rate all kinds of things start to fail and overload if you're not very careful in what you do. It really doesn't matter a lot here whether the load comes from a 1000 simultaneous web site requests or a 1000 batch jobs that run in parallel and which may tolerate 'some' delay, but -have- to be processed before the next business day.

Basically any kind of computation that your enterprise is running...

It depends really. The right algorithm and especially the complexity of that algorithm obviously matters a lot, but for true high performance computing, knowing your hardware can make a huge difference too. Regarding space/time optimization, it simply matters to know if you have more memory or more cpu cycles to burn in your actual machine. Very few to no algorithms can optimize for both space and time, so you have to know your target hardware in order to make the necessary tradeoff.

Next to such general choice, it can matter immensely if your hardware has special provisions that you can exploit. For instance some CPUs have hardware support for BCD arithmetic, which can speed up calculations a great deal if your software can take advantage of them. Knowledge about alignment of your memory can matter a lot too. Mathematically identical algorithms may cause your target machine to resort to trashing if you misalign every memory access and/or access 'adjacent' memory cells in the wrong order. In you have to process some matrix, it normally doesn't matter for the algorithm whether your process it row wise or column wise. If the matrix is stored into memory in such a way that cells in a single column are adjacent in memory, while each row in this matrix is the column length of cells away, then processing row by row may cause a page fault for every new cell access which completely blows your performance away.

Then there are such things as certain CPU instructions like an atomic test and set, or certain addressing modes that your language may or may not be capable of taking advantage of. Using such things can matter a lot too. Then there is a whole category of special hardware, like DSPs, vector units and lately GPUs. Taking advantage of such hardware might make more of a difference then choosing between a bad and a good 'normal' algorithm that only runs on a general purpose CPU. A simplified example is hardware H264 decoding. If your CPU is not powerful enough, then no algorithm, no matter how cleverly constructed will be able to decode say an HD H264 stream. But if your machine happens to have an HD H264 hardware decoder, then obviously simply using it in your software will yield much better results. On a more fine-grained scale, it's the same with all those little things your hardware offers. Is your language able to take advantage of that, or does it just let it sit idle?

I basically agree with your point that making the right choices regarding performance matters immensely. It's just that I don't think this necessarily means that you should write all code yourself instead of intelligently using a library or framework.

You can either write slow and inefficient code yourself, or you can use an existing library in such a way that it will be slow and inefficient and vice versa. I've written high performance software capable of processing 6000 fairly complex transactions per second on moderate hardware, while still using highly convenient library classes like Java's ConcurrentHashMap. Some would perhaps even say that just using Java is already a 'framework' and I should have used C++ or maybe assembly... where does it stop?

I'm also implementing some high performance (beta) code using preleases of Java's upcoming fork/join framework and the level of performance I can squeeze out of this is fairly impressive to say the least. I'm not sure if I would be able to write my own "work-stealing work queue" that offers better performance. Actually, I'm pretty sure I wouldn't.

I'm not entirely sure about that last thing you're saying. The problem is that teaching your framework over and over again to new developers takes a fair amount of time too. You'll also have to make damn sure you write good documentation and keep it up to date. Depending on the size of your development team and the amount of time dedicated to such a framework this may be doable, but more often than not this is precisely the part that's lacking.

A standard well known framework has the advantage of having heaps of documentation already written. When stuck, programmers can post questions in forums, google away for answers, buy some books or even follow some course. This won't be possible with your proprietary in-house developed framework. When stuck, programmers will come directly to you and if maintaining this framework is not your core job, this can get annoying pretty fast.

Don't get me wrong, it can definitely pay off to build something of your own. After all, most best-of-breed open source frameworks on the market today where once started because some programmer in some company wasn't satisfied with the readily available stuff. I'm just saying that you should really think twice before starting development of some framework and carefully consider your options.

For instance, if you feel the need to develop yet another web framework, logging framework or ORM for Java, my first advice would be to simply not do it. The amount of web frameworks already available is simply getting ridiculous and don't think lightly of the pressure you put on your fellow programmers who have to learn a new g*dd*mn framework for each and every new Java job they take. It would be far better to start with one of the excellent web frameworks already available (e.g. JSF, Wicket), and extend them where necessary. Most good frameworks have a lot of options for customization and extension. Going that route will not only safe you and your fellow programmers time, it will also allow you to leverage third party offerings for that framework. In the case of JSF, there are a couple of high quality component sets emerging (like RichFaces and PrimeFaces). With your own web framework, you simply won't be able to use any of that.