The Top 10 Unused Features in Java

Point 10: Of course these keywords are unused, as they are useless ! You can also talk about strictfp keyword, which is almost never used (but do something !)

Point 1: Assert is  not often used? As far as I am concerned, I would say "is never" used ;)

Another unused Java feature is the double braces initialization.

I would happily use assertions in my own code because they are much more readable than
 if (!cond) 
  throw new XY(); 
There are two seemingly small problems with assertions. The first is that they throw an Error and not a RuntimeException. Errors are usually not catched, so they can stop a server. I don't understand this decision, to me a failed assertion is similar to a NPE.
The second is that they are switched off by default. This might have been a good decision at its time, but nowdays we are more concerned with stability than performance.

Are you sure that TestNG uses the Java Assertions rather than it's own implementation (like JUnit)?

 Here are Suns recommendations when to use them and when not: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html#usage

Assertions should NOT be used for application code but test code.
That's why they are switched off by default and throw Error.

I agree, my statement was to general.

In the TestNG manual and in the book the authors use assert in the examples. 

I have to admit that i haven't used TestNG yet, so i was surprised to learn that you could use Java assertions.

A JUnit compatibility class is also included in the distribution.

From the TestNG doc:

TestNG also include JUnit's Assert class, which lets you perform assertions on complex objects

The JUnit assertions seem to require less code.

 That is an interesting point, especially considered that they are turned off by default. Can you please elaborate?

To enable them, you have to set the -ea (or -enableassertions) jvm option.

Your comment about the so called "double braces", aka anonymous inner classes, they are used in JMock to specify Expectations. I could think of a couple of reasons not to use them to initialise a collection, the most obvious one is that there is a more convinient way by using java.util.Collections.addAll

Point 8) Have you ever tried your own?

I did and was way disappointed. See what I found here: http://forums.sun.com/thread.jspa?threadID=568620&range=15&start=0&forumID=22#2811377

7) Ant calls the same java classes in tools.jar as the bin exe's do. I most definitely need jar. Also, javah is needed for JNI development. I do JNI development for graphics development like my record breaking fastest shadow dropping subroutine ever made by anyone in the whole wide world.

2) Java is better on Linux, so if you want to be cool, use Linux, not arrogant Apple.

1) I use assertions fairly often, because I don't know what else I can do to have debug features without impacting performance. Resorting to M$ style Debug/Release builds would suck for obvious reasons.

I have another largely unused Java feature, labels, or whatever they're called:

find:
{
  for (int i = 0; i < str.length(); i++)
  {
    if (str.charAt(i) == findChar)
      break find;
  }
  throw new Exception("not found");
}

And how about using scopes to contain local variables so you can use them again (and avoid problems):

switch (something)
{
case 1:
  {
    int i = 123;
    ...
  }
  break;
case 2:
  {
    int i = 256;
    ...
  }
  break;
}

I develop MIDI solutions using Java.

I cannot disagree more with the view that the javax.sound.midi package is useless. You arguments are from someone who just have no usage of this package, just as I have no usage of Java2D at the moment.

It is interesting to note that the JDK is one of the rare language API that offers a MIDI API out of the box. Although far from being perfect, it is very decent and one can write great MIDI centric applications with it. It works fine for basic editing/playback and fine (with some tweaks) for recording.

Also, your point about the soundbank is really moot: the JRE ships with a small-footprint soundbank so as not to inflate the JRE package. However, you can download a much better version  (http://java.sun.com/products/java-media/sound/soundbanks.html) and copy it in your JRE installation. So you have the choice and considering a mere 0.35Mb as a not-desirable download with the JRE in 2008/2009 sounds like bad faith to support your argumentation.

It is true though that the MIDI API is not for professional MIDI. It is not really the Java business to produce high-quality soundbanks, or near-time clocks for professional MIDI. No known langage provides that in its basic API but it all can be done in an easier way with Java than, say, Gnu C. Java does a very decent job in that matter anyway.

Of course, I wish SUN would have come with a really reliable Sequencer implementation. The default JRE one is pretty weak. Attempts have been made to enhance that (http://www.tritonus.org/) but sadly, there is not a real community around MIDI and around MIDI and Java.

Which makes you think MIDI in Java is useless. It's not. I am glad SUN included the whole API with the Java language. Too bad they never really polished the job.

I've never said that javax.sound.midi package is useless or MIDI in Java is useless. This is my Top 10 of the unused features (not of the useless features).

About the sound bank being too big, it's actually more the opinion of the JCP:

http://jcp.org/aboutJava/communityprocess/final/jsr270/index.html (Java SE 6 - JSR - Chapter 4):

"Per that policy, this specification proposes the removal of the javax.sound.midi package in a future release of the platform. This package is not often used and typical implementations of it require a large data file, about half a megabyte in size, which is a significant component of minimal Java Runtime Environment (JRE) download bundles."

I think this is rather skewed towards what the author uses (or rather doesn't use).

For myself, I use assertions quite extensively, and have used a lot of the EXE files in the bin directory (of the ones listed here, jdb is the only one I haven't used!).