Anthony Goubard is a freelance Senior Software Engineer from Amsterdam. He has developed in Java since 1995. He has developed many softwares available at http://www.japplis.com and is the main developer of the Web Services framework XINS. Anthony is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile

The Top 10 Unused Features in Java

04.17.2009
| 28897 views |
  • submit to reddit

10) const, goto
What? Yes, they are Java keywords. But they do nothing.

9) Some Java flavors
Such as Personal Java, JavaOS.

8) Indexed Jars
Indexed Jars are jar files containing a special index file (META-INF/INDEX.LIST) indicating which packages are in the jar. With Ant it's index="true". Its purpose is to speed up classloading and enable lazy loading of Jar files for Applets and Webstart Applications.

7) Most of the exe files in the bin directory
Such as javah.exe, javadoc.exe, jdb.exe, jar.exe.
They have been replaced by Ant or Maven and IDEs.

6) Applets
Popular 10 years ago, they saw their popularity going down since. But they will make a come back with Java SE 6 update 10.

5) CORBA
This API would probably win the vote among developers on "which API do you want to remove from Java?".

4) javax.accessibility and accessibility
This package exists since Java 1.2 but is not that much used. On one hand it's true that Swing will do a lot for you but one the other hand it won't do everything. Especially empty text fields and text areas need to be annotated.

3) Midi library
Yes, Java has midi build in it. So Java can play music since 1.1. At the time they added a sound bank so the music quality would sound better. Now the sound bank doesn't sound that nice compare to sound cards.
Most of time when talking about the modular JRE, CORBA is often named as the library that won't need to be downloaded, but the sound bank is probably the bigest win.

2) Java 6 API
Here is mostly Apple to blame because they decided not to support Java 6 for 32 bits platforms, a lot of API's and programs are blocked at the Java 5 level.

1) Assertions
In Java 1.4 Sun added assertions. Well I remember at the time there was a few talk about Java missing assertion/pre/post conditions. So this feature was added.
Let's face it, it's not often used.

From  http://www.jroller.com/agoubard

Published at DZone with permission of Anthony Goubard, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Peter Maas replied on Fri, 2009/04/17 - 5:52am

I don't agree with point 7, those utilities are in a lot of cases simply invoked from a build script... so they wheren't replaced by the script; and therefor still in use!

Romain Linsolas replied on Fri, 2009/04/17 - 6:21am

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.

Eugen Paraschiv replied on Fri, 2009/04/17 - 6:28am in response to: Romain Linsolas

I agree with most of the points in your post, save assertions. I use assertions extensivelly, and I find the fact that I can turn them on and off very usefull. 

Benedict Aluan replied on Fri, 2009/04/17 - 6:53am in response to: Eugen Paraschiv

Agree :-)

Alessandro Santini replied on Fri, 2009/04/17 - 7:16am in response to: Romain Linsolas

Double braces are extensively used with JMock, AFAIK.

Stefan Fussenegger replied on Fri, 2009/04/17 - 7:26am in response to: Romain Linsolas

"Double braces initialization" isn't a language feature itself. What you are doing is creating an anonymous class and use an initializer block in it. Two features which I personally user quite extensively - but independently.

Mladen Girazovski replied on Fri, 2009/04/17 - 9:27am

1) Assertions
In Java 1.4 Sun added assertions. Well I remember at the time there was a few talk about Java missing assertion/pre/post conditions. So this feature was added.
Let's face it, it's not often used. 

 I find Assertions not just useless, but even dangerous.

Hontvári Levente replied on Fri, 2009/04/17 - 9:28am

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.

 

Hontvári Levente replied on Fri, 2009/04/17 - 9:29am

Btw. assertions are used in testing code with TestNG and they are useful there.

Mladen Girazovski replied on Fri, 2009/04/17 - 11:34am

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

 

Bruno Borges replied on Fri, 2009/04/17 - 11:35am in response to: Hontvári Levente

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

m2c

Alessandro Santini replied on Fri, 2009/04/17 - 12:26pm in response to: Mladen Girazovski

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

Hontvári Levente replied on Fri, 2009/04/17 - 12:37pm in response to: Mladen Girazovski

In the TestNG manual and in the book the authors use assert in the examples. A JUnit compatibility class is also included in the distribution.
Thanks for the Sun reference.

Mladen Girazovski replied on Fri, 2009/04/17 - 4:47pm in response to: Bruno Borges

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

 

Liam Knox replied on Fri, 2009/04/17 - 6:10pm in response to: Mladen Girazovski

Absolutely agree. The fact you can turn them on and off is just plane dangerous. I really dont see any need for the feature at all and you are better of using a static utility Assert class that has definite unchangeable behaviour.

Monica Walker replied on Sat, 2009/04/18 - 2:09pm

This is a really interesting post, I'm questioning my Java knowledge now..Thanks

Thomas Nagel replied on Mon, 2009/04/20 - 4:10am

Well, most are true also in my eyes.


Number 4 would be badly needed though. Try writing a barrier-free Swing-App, then you'll see what I mean. I once made a heavily table-using Struts app use CSS instead, so not to confuse screen-readers. Took me about a week.


Number 2 is in fact not forgotten, as MacOS isn't as important as some people may think. You can really do very good things as annotations, even invent your own.


But maybe the story of enhancing Java has already ended, Sun has already resigned.

Look at Groovy and its sack-full of badly needed Java-enhancements. Or, look at JavaScript, one of the most undervalued languages. It's way to model objects directly without the need to write a class for each and every deviation is so concise for many problems, especially if you'd write a singleton anyway.


Regards,
Thomas

Peter Huber replied on Mon, 2009/04/20 - 5:41am

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

Anthony Goubard replied on Mon, 2009/04/20 - 9:53am in response to: Peter Huber

Yes, I'm very happy with it especially for my online text to speech application.

Note that I don't use Ant index="true" but <exec> with java -i for it. For my online dictionaries I create the INDEX.LIST file in advance and add it to the Jar like a standard file.

Mike P(Okidoky) replied on Mon, 2009/04/20 - 5:00pm

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;
}

 

 

Mladen Girazovski replied on Tue, 2009/04/21 - 2:18am

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.

 What kind of Debug featuers do you have?

If it's about lgging, then log4j has built in support to check if debug is enabled or not which is really low on impacting performance (a boolean is checked).

 

Me Here replied on Wed, 2009/04/22 - 3:29pm

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.

 

 

Markus Schlegel replied on Thu, 2009/04/23 - 3:32am

Well, your view of the java-world is really very limited.

Personally, I've used 7,6,5,2 and 1 already and I still use 6,2 and 1.

Assertions have two advantages in my opinion:

1. when you read code with an assertion, you know from the first time of reading that this test is used only during the development to clarify and ensure things. As a developer you can express, that a certain pre- or postcondition holds. testing this is not needed in production (this is part of the contract when you use assertions).

2. the code will not be executed at all if assertions are disabled. The jvm simply does nothing -  not even a boolean check or a method call. With logging frameworks, you often have something like "log.log(levelY, "bla"+var.someMethod())" which wil first execute the "someMethod" then use a StringBuilder and call log.log().
Or you have an additional if (log.DEBUG){...}.

Notice that you carefully have to understand the contract of assertions to use it properly...

Anthony Goubard replied on Thu, 2009/04/23 - 3:42am in response to: Me Here

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."

Hopefully the Java kernel and the upcoming modular Java will make this removal unneeded.

Peter Lawrey replied on Sat, 2009/04/25 - 2:46am

I wouldn't agree with point 1), I use assert fair often, at least as often as enum (perhaps not as often as envisioned by the creators)

 

One feature I am sure isn't used much is casting a negative primitive to a wrapper.

Object o = (Integer) 5; // compiles fine.

Object o = (Integer) -5; // fails to compile even in the latest compiler.

So I pretty sure this feature isn't used much. ;)

 

George Wells replied on Sun, 2009/04/26 - 2:09pm

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!).

Anthony Goubard replied on Tue, 2009/04/28 - 3:23am in response to: George Wells

Hi George,

I have used most of the features that I mentioned (for some I still do).

How many open source project can you list that use assertions?

As for the exe, here is the list: appletviewer.exe apt.exe extcheck.exe HtmlConverter.exe idlj.exe jar.exe jarsigner.exe java-rmi.exe java.exe javac.exe javadoc.exe javah.exe javap.exe javaw.exe javaws.exe jconsole.exe jdb.exe jhat.exe jinfo.exe jmap.exe jps.exe jrunscript.exe jstack.exe jstat.exe jstatd.exe jvisualvm.exe keytool.exe kinit.exe klist.exe ktab.exe native2ascii.exe orbd.exe pack200.exe packager.exe policytool.exe rmic.exe rmid.exe rmiregistry.exe schemagen.exe serialver.exe servertool.exe tnameserv.exe unpack200.exe wsgen.exe wsimport.exe xjc.exe

Ask your Java colleagues which ones they still use. 

Vijay Bhagat replied on Fri, 2010/01/15 - 1:42pm in response to: super pan

when you read code with an assertion, you know from the first time of reading that this test is used only during the development to clarify and ensure things. As a developer you can express, that a certain pre- or postcondition holds. testing this is not needed in production (this is part of the contract when you use assertions). ductionare engleza

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.