Something missing from the J2SE API that you’d really like to see? Something you’d like to use but can’t because it’s been broken for years?
Rant here! ;D
I’m first:
This afternoon a friend asked me about writing a little Java app to ease an unnecessarily repetitive job he has to do at work, and of course I’m only too happy to help out. Part of that job involved dumping some file metadata into an XML file, so I poke around java.io.File for the first time in about 5 years. There’s some pretty interesting design decisions in there, like the following:
[quote]public long lastModified()
Returns:
A long value representing the time the file was last modified, measured in milliseconds since the epoch (00:00:00 GMT, January 1, 1970), or 0L if the file does not exist or if an I/O error occurs
[/quote]
Now there’s me thinking that when a file isn’t found you should throw a FileNotFoundException. And when an IO error occurs you should throw an IOException. And what happens if the file was created at midnight on 1/1/1970? How do you distinguish that from it not existing at all?
Well, never mind. I don’t need to query the modification date at all, I need the creation date.
But no, I can’t have that! Some filesystems don’t support creation dates, so Java wouldn’t be able to give me a sane answer! We’ve all got to be alike. The only way to be happy is for everyone to be made equal. Well, guess what? I’m developing and deploying on filesystems that do support creation dates. And I want a creation date.
So my options are:[]Runtime.exec a “dir” command and regexp the output.
[]Write and distribute a JNI library to make the creation date check.
[*]Write it in VB instead.
What a mess.
The answer to this and other file related defects ought to be in the much delayed JSR 203.
File.exists()
;D
JSR-203 sounds interesting, although there’s very little public info from what I can see. There’s also some confusion over whether it’ll be available in 1.5/5.0 or 6.0. But anyway, it doesn’t help me today. I’m just amazed that it’s taken so long to provide something as basic as rich filesystem data.
Moving on to a different part of the same project, I’m playing with JMF for the first time just about since it was released. It still sucks, doesn’t it?
There’s no useful documentation that I can find, very few example programs, and no general overview that might help you understand how to get hold of an object of a certain type. I think I need a DataSource, but the only way of getting one appears to be via a MediaLocator. But sources created in that way always seem to be of type URLDataSource, which doesn’t implement the one method I need.
The JMF source is a badly-commented leviathan, containing such horrors as this:
// TEMPORARILY COMMENTED OUT URLDataSource: 1/15/99
// if( source == null) {
// try {
// source = new URLDataSource(sourceLocator.getURL());
// source.connect();
// } catch(MalformedURLException me) {
// // Can't get a URL so we're done.
// source = null;
// }
// }
I’m rapidly approaching the level of frustration where I just ditch the whole API and hack it: guess the general content type from the file extension, and hardcode a bunch of magic number checks to get the actual type. Yuk.
The lack of progress and information on JSR 203 is frustrating. In the mean time you could use things like JConfig now.
[quote]Moving on to a different part of the same project, I’m playing with JMF for the first time just about since it was released. It still sucks, doesn’t it?
[/quote]
Yep. Not even necessarily for the reasons you’ve found. The samples are a big help… once you get that far you will think it just works or you will find how much it really does suck. Depending on what exactly you need it to do.
[quote]I’m rapidly approaching the level of frustration where I just ditch the whole API and hack it: guess the general content type from the file extension, and hardcode a bunch of magic number checks to get the actual type. Yuk.
[/quote]
That’s probably the best that can be done anyway - it’s all the JMF stuff is likely to do.
The file stuff is a pain in the butt.
Other things the bug me:
Still no support for arbitrarily shaped windows and windows with translucent areas.
The audio APIs still suck.
COMM APIs (for serial and parallel ports) are unsupported… no access to USB or firewire devices either… no support for scanners or other acquisition devices (digital cameras). Poor support for video capture via JMF - which could be awesome if it got some attention.
Poor integration with native look and feel of JFileChooser on windows (context menu when right-clicking on files)
On the plus side I like what the Java Desktop guys are doing to get better integration (screen savers, system tray/dock icons and context menus)
JMF is awful. Just forget it. Perhaps you’ll be better off wrapping OpenML á la LWJGL.
Still can’t do window masks in AWT, so any groovy media player stuff isn’t going to happen in Java any time soon. Not that it matters coz JMF is so useless.
HTML rendering is woefully inadequate. I mean, just how useful would it be to have real HTML4+CSS2 rendering up to the standard of Opera in Swing? Amazingly bloody useful, that’s how useful!
Can’t get font kerning information from fonts, inexplicably. Very annoying.
The XML APIs seem to be incredibly complicated, and really really slow. I hate them.
Swing still does not antialias text by default. I haven’t used a blocky GUI for about 5 years now. I’ve had to do a lot of hackery to make my GUIs all render antialiased.
Cas 
Seeing as even the best dedicated browsers (opera and mozilla) are still not perfect [especially at css2] then what hope is there for Sun, which doesn’t put that much resource into JVM development (compared to the size of sun as a company, and compared to what they would do if it were not free), to even come close?
To be honest, I rather like the fact that it has a fairly lean HTML implementation because most of the time that’s precisely what you want (i.e. for doing fragments of complex formatting e.g. in Swing widgets). I agree there are places where a full embedded browser would be handy, but I’ve never ever liked embedded browsers as a user - I’ve got a dedicated browser for that! Just let me use MY browser, with MY settings!
Or am I missing some usecase here?
AFAICS this is nothing to do with Sun, but simply the standards imposed upon them by other people (i.e. W3C mandates the DOM API, and SAX API is again mandated by an external entity).
Frankly, I’ve never seen a benefit to AA text - to me, it always just looks blurry (maybe I’m more sensitive to blur than most people?). However, it clearly matters to so many people that I wouldn’t dare take it away from you all :).
On CRT’s I usually don’t care, but AA text often looks really horrible on a high-resolution ultra-sharp LCD. e.g. KDE offers 4 AA schemes for text, all of which make the ultra sharp text go noticeably blurry around the edges. Gnome does the same for 3 of it’s four schemes.
Now I think I’m using non-AA, and real fonts (this is something of an achievement in linux - for the last 2 years I’ve had truetype fonts rendered at a constant 12pt or so and then ZOOMED to fit - ohmygod it was ugly) and it’s beautiful. Reminds me what I spent all that money on a really good display for.
All good stuff from swp and cas, but…
…video capture and processing, IMHO, is the single biggest mistake so far listed which is entirely Sun’s fault (c.f. XML being partially out of their hands).
They ought to be so easy, and open up a huge world of possibilities to both app developers and games developers, and yet it’s so hard right now :(.
But then, AFAICS, the whole JMF is today what Java3D was for most of it’s life - the “ugly cousin” that no-one in Sun likes, and which regularly gets kicked in the head in passing by all the other depts. A job started but never finished, a core technology * ignored and forced to stagnate, a piece of crap implementation that’s so embarassingly bad it should never have been released (I mean, come on - IBM releases higher quality stuff on their alphaworks site!), etc.
-
- Java2D is core, 3D + hw-acceleration + scenegraph is extremely important, yet Java3D was never core. That is inconsistent.
Ditto JMF is more core for most client-side work than many other bits that are in the standard libraries. I guess this is just the whole “sun never quite got around to dealing with client-side java” problem rearing it’s head again…
[quote]The XML APIs seem to be incredibly complicated, and really really slow. I hate them.
[/quote]
I do a lot of processing on XML documents, since my main project’s file format is all XML based. I’ve never found the APIs to be complicated.
The XML APIs may be a bit slow (it is string processing after all which is slow relative to non-string alternatives), but they are actually relatively fast in some areas when compared to C code. Having string lengths is a big help I would guess.
Anyway, compared to the Microsoft XML APIs they are a joy.
Also, in Java 5 there are speed ups in the XML APIs, notably XSL transformations.
Yeah, I think the java XML apis are pretty damn good and fast.
A bit of personal experience:
I recently had to create a little app which transforms data coming out of an AS/400 to huge XML documents. At first I didn’t want to validate them against the schema’s because I had tried validating them (for testing) using MSXML and it took like >10 minutes to validate one such XML document while bringing the whole system to a grinding halt. Then I did a test using xerces and it took only about 9 to 10 seconds, doing a full schema validation!
No complaints at all
[quote]HTML rendering is woefully inadequate. I mean, just how useful would it be to have real HTML4+CSS2 rendering up to the standard of Opera in Swing? Amazingly bloody useful, that’s how useful!
[/quote]
Yes, +1 
At work we have an application with embedded help functionality written in VB. I think it simply embeds the IE html renderer in the user interface.
In java, you can’t do that and have the same kind rendering quality.
Well, outside of J2SE, there’s
JRex (http://jrex.mozdev.org/)
and the (not quite functional ATM?)
WebClient (http://www.mozilla.org/projects/blackwood/webclient/)
Both of these wrap Gecko of Mozilla as a Java widget.
Well, I would say wrapping the IE WebBrowser control on Windows makes much more sense, given the popularity of IE vs. Mozilla. Should I say SWT does this already…
Time for another rant! ;D
So I’m using JDK 1.5, and am rapidly growing dependent on Generics. At the day job I have to deal with ugly casts and runtime exceptions, in my free time the compiler sorts all that out for me. Lovely.
Except…
Spot the problem with the following code:
Properties properties = new Properties();
properties.load(url.openStream());
Set keys = properties.keySet();
for(String name : keys)
String value = properties.getProperty(name);
While “keys” is a valid argument to the enhanced for loop construct, that “String name” is illegal. Why? Because “keys” isn’t a “genericised” collection - the only thing that can come out of it is an Object. Fine, says I - I’ll write this instead:
Set<String, String> keys = properties.keySet();
And of course that needs to be backed up with:
Properties<String, String> properties = errr... hang on...
The Properties class only handles Strings. Returning any Set other than a Set<String, String> is non-sensical. But that’s what I’m getting - a Set<Object, Object>.
Fine, 1.5 is still in beta - but when the developer opened up Properties.java to change it to extend “Hashtable<Object, Object>”, surely they would have thought for a second whether or not that was the right thing to do?
You’d have thought so, right? :-/
Allegedly some people have put objects other than String’s into Properties. Now you might feel that such abuse doesn’t deserve any sympathy.
A thread on this subject can be found here http://forum.java.sun.com/thread.jsp?forum=316&thread=528691
Ah, I spotted that Properties was completely fscked from a design POV years ago, and guessed it would be removed at some point, so we made a parallel set of classes that implemented Properties in the way that Sun should have done it, and have been using our versions ever since (with appropriate glue / static conversion methods / etc to enable you to deal with things that require Properties).
The main one we use these days is a tree-structured TreeProperties that is able to encapsulate child elements in the obvious manner - IMHO only a very inexperienced programmer would have thought that it was safe to have a flat-file properties system. It converts into standard Properties format using a codec, the main one being the obvious
leaf child of br2 child of br1 writes as a single properties key of “br1.br2.leaf”
Sigh.
It is easy to say that Properties is broken, but much harder to come up with a replacement that would be generally approved. Personally the flat key space doesn’t bother me much, but restricting the values to String is a pain. I’d like to have Color, float[], etc as values.
[quote]It is easy to say that Properties is broken, but much harder to come up with a replacement that would be generally approved.
[/quote]
Sure; what I meant was that it was obvious that it wasn’t quite right for anyone, and that we found various alternative designs that did everything we needed.
But I definitely think it should have been tree-structured, seeing as system-properties have an explicit structure already, and Properties are widely used for configuration - which AFAICS is always better with a tree structure (if you have small systems, or need to not have tree-structure, you can always just ignore the tree and put everything in the root…). The chained-Properties system is IMHO a cheap hack to try and provide some of the benefits of trees, but without realising that chaining is very expressively-weak compared to trees.
One of the reasons that XML is so widely used for config appears to be the ability to nest sub-configs (for sub-modules) and the ability to structure your config so that it’s a lot easier for a human to work with (either directly or through editors that interpret the structure into e.g. a JTree GUI). Properties could so easily have done this…(indeed, we have a codec for our treeproperties that reads/writes from/to XML in a simple schema).