Dolphin is coming… do you think they’ll listen to us? From the looks of the most popular RFE’s, I’m kind of hoping they don’t.
What follows is a very brief and highly opinionated tour of the top ten requests for enhancement (RFE’s) on Sun’s Java Bug Parade. These 10 are pulled from the dynamically-updated list of the Top 25 RFE’s, as voted for by registered SDN members (there is also a list of the Top 25 Bugs).
For each, I’ll summarize the issue, and assess whether the RFE is a good idea, and whether I think it’s likely to get done in Dolphin. You are welcome to use the comments section to tell me what a dumb-ass I am for denigrating your favorite bug.
-
Bug ID 4499904 - RFE: Ogg Vorbis and Tarkin support for JMF Bug quality: Low Odds for Dolphin: Zero JMF hasn’t been touched in almost two years, Ogg Vorbis isn’t relevant to anyone outside the geek community (and even then it’s an act of ideological zealotry to rip your CDs as Ogg), and Tarkin has given way to Theora, which is also known only to zealots. Have Java developers ever heard of a little standard called MPEG-4? They use it for satellite TV and iPods. Seriously, guys, look into it. That this is the top RFE says a lot, and a lot of it not good, about Java developers.
-
Bug ID 4449383 - Support For ‘Design by Contract’, beyond “a simple assertion facility” Bug quality Medium Odds for Dolphin Low This RFE argues for a full-blown implementation of Design by Contract, with checkable method pre- and post-conditions. The comments suggest that the language may be too large to implement this feature now, and furthermore, third party tools exist for those who would like to bolt it on. If those took off, they could be folded into the language (like Doug Lea’s concurrency libraries), so this can be seen as a very understandable “wait and see”.
-
Bug ID 4802695 - Support Java Plug-in on 64-bit AMD Opteron Bug quality: High Odds for Dolphin: High Already exists… for Solaris, anyways. Think Sun won’t get behind it for Linux? They’d better; IBM already has.
-
Bug ID 4680244 - RPM does not follow LSB or filesystem hierachy Bug quality: High Odds for Dolphin: High Eminently sensible to straighten out the end-user install. On the other hand, is there any chance the Distro License for Java aspires to just let the distros themselves figure out where things are supposed to go?
-
Bug ID 4724038 - (fs) Add unmap method to MappedByteBuffer Bug quality: Medium Odds for Dolphin: Low It’s sensible that once you’re done with a file that you’ve mapped into memory for NIO, you’d like to have the freedom to delete or otherwise modify the file, but you can’t until the memory is freed, and that’s non-deterministic. Reasonable RFE, but Sun’s evaluation is that they can’t see a way to do this in a fast, secure, portable way.
-
Bug ID 4820062 - Provide “struct” syntax in the Java language Bug quality: High Odds for Dolphin: Medium Not quite C structs, but the idea is that given some arrangement of primitive members, you know the size of the arrangement (or struct) and could operate over them in memory in a fast, efficient way. The proposal comes from the needs of game programmers to load in OpenGL vertexes, textures, etc., in a highly-efficient way. This isn’t as icky-C as it might first seem, but then again, one of the knocks against Java from the scripting crowd is that the primitives were a premature optimization — Sun’s evaluation suggests that similar functionality could be achieved with annotations and a library to process them. This is an interesting problem and proposal either way.
-
Bug ID 4296022 - html4.x support within a JEditorPane Bug quality: Medium Odds for Dolphin: Low Welcome to the nightmare that is HTML handling in Java. HotJava was abandoned years ago, and Swing’s HTML handling stopped evolving back in the HTML 3.2 era, if not earlier. So, rendering real-world HTML in a Java GUI is a nasty proposition… so nasty that the new solution seems to be punting and loading up a native browser via JDIC. Too bad though, if you need to do anything with the page, like inspect its DOM. There’s also Flying Saucer, an all-Java option for the rare case of standards-compliant XHTML. Sun does have a survey up where you can tell them what your text-rendering needs are.
-
Bug ID 4267080 - break up rt.jar into downloadable-on-demand components to reduce jre size Bug quality: Medium Odds for Dolphin: Medium You call it bloat, I call it features, but the days of the monolithic JRE have to be numbered. My guess is that they could simultaneously solve the problems of end-user deployment and library versioning (as promised at JavaOne 2005), and apply that to the JRE itself. That way, you could ship a bare-bones JRE and the end-user dynamically get the pieces s/he needs — whether of your libraries, your dependencies, or the JRE itself — on an app-by-app basis. Let’s hope they finally get this one done, and done right.
-
Bug ID 4910812 - Enhance Hot Code Replacement Bug quality: ??? Odds for Dolphin: ??? This is totally out of my league, sorry. It would seem like bytecode manipulation potentially gets you some of this, and the use cases seem completely restricted to development-time “fix and continue” functionality (you wouldn’t want this in the end-user’s VM, would you?). Is this really a VM RFE, or a request for a kick-ass IDE feature?
-
Bug ID 4045688 - Add chdir or equivalent notion of changing working directory Bug quality: Low Odds for Dolphin: Medium Given 1.3’s ability to specify a current working directory for
Runtime.exec()-type commands, what’s the value of this? What’s the remaining problem that has 188 votes behind this? No, I don’t consider the current directory viable when I work withjava.io.File, but then again, I don’t trust anything related to the miserable API that isjava.io.File, and I carefully construct paths with newFileconstructors whenever possible.
Mpeg4 is a patent minefield, so it's next to useless, unless you want to be a target for $random_corporation looking to score some fast and easy money. AT&T is currently making the round, apparently.
Dalibor: That's what we have MPEG-LA for. And don't think for a second that scummy patent trolls wouldn't make a similar claim on Ogg if it were relevant.
MPEG-LA can license you some of the patents covering the video portion (except AT&T's claims, of course). You still need to go out and license audio separately from Thompson & Via Licensing, who have different terms, of course.
Nevermind that MPEG-LA's licensing terms have been rather weird in the past. Among other things, they tried to collect a royalty on all MPEG4 streams played, which heavily annoyed Apple and other implementors. Reasonable and non-discriminatory terms ... yeah, right. :)
JMF users and developers have been burned before when MP3 had to be pulled out. Putting patent-loaded technologies into standards is not such a great idea. That's what plugins like IBM's codec are for.
Good post!
Rendering potential HTML4.x sites is not the main problem, there are solutions for this in the opensource area.
But have you ever tried to EDIT HTML with the current implementation (notice that the component is named JEditorPane)? It contains so many bugs, that it really needs some redesign. But redesign does not make sense if it would only support HTML 3.2, because must of the sources for HTML-Text (think of copy/paste text out of a Browser or MS Word into a JEditorPane) are HTML4.x sources...
JEditorPane in Edit-Mode is a real nightmare!
Chris, Your point on RPM/LSB/DLJ is exactly why we created the DLJ. Part of the justification we mustered for the DLJ is the high ranking of the RPM/LSB RFE. Yes, the Linux distro makers know their system much better than we can ever know them ... and I don't mean that to say we don't/won't know Linux, instead what I mean is there are many flavors of Linux, each with their idiosyncracies. e.g. Solving for RPM would not solve for Gentoo nor Debian. So why not give the power to the distro maker to bundle Sun's JDK in the way that makes sense for their distro???
Dalibor: I had kind of intended to let the MPEG thing lie, for fear it was off-topic, but with new traffic on this blog entry (thanks, Java Posse!), it kicked up some old feelings I had when I first heard about AT&T's patent claims against MPEG-4. I'd intended to blog them then, but never did, and I really can't now with our awful new blogging system that won't let me out of my topic box.I can't tell if you assume AT&T's claims against MPEG-4 to be valid, but I don't. Then again, I think the RIM case showed that validity doesn't matter anymore. Which is scary. I suppose one could conclude that patent discussions have now left the realm of rational discourse.I would prefer patent-free standards, but I'm not convinced that's even possible in the media realm anymore. I don't know if the Ogg codecs do or don't use any patented algorithms, but do I think a lawyer could convince twelve laypeople they do? Given the similarity of the various DCT-based codecs, I think it would be harder to disprove a violation.
Given the reality of the field, I do think MPEG and MPEG-LA have done a very good job, especially considering that the likely alternative is the corporate-owned, non-interoperable codec. You know which ones I'm talking about. The MPEG organization and its standards have served us well for nearly 20 years, and I see the AT&T claim as an abberation, and probably a bogus land-grab. Do I like the terms seeking money from content providers? No, I think it's impractical. But that idea probably came from the patent-holders trying to maximize the value of their portfolios. It's reasonable (if a little greedy and unwieldy) and non-discriminatory (everyone gets the same deal). And again, I'd rather have that than have Microsoft getting into my TV.So if we're going to have Java Media at all, someone somewhere has to figure out how to get enough money to get a comprehensive MPEG-4 license for Java applications. Maybe that's Sun, maybe it's some kind of open foundation, whatever. Apple did it for QuickTime, back before Apple was cool (and rich) again, so it's not impossible.The thing that so burned me up that I had meant to blog about it was AT&T's claim itself. Either it's bogus and they're just using the patent system to extort money from technology winners, or it's valid and they ignored the MPEG-LA's call for participation in order to submarine the patent. Either practice is utterly unethical, and if I were on a standards body or expert group, the first thing I'd do is seek the expulsion of all AT&T employees in the group, on the assumption that it is now that company's policy to game standards bodies in order to generate patent license revenue.
> Enhance Hot Code Replacement
This is the one.
THis would be soo nice during developpement and let's not forget server code swapping!
Referring to #3:
I believe the comment is incorrect. While there are AMD64 JVM's for Solaris, Linux, and windows non of these provide 64bit java plugin support (applet and webstart).
From the 1.5 JRE download page for Solaris X86 for AMD64:
"Solaris x64 self-extracting file (use 32-bit version for applet and Java Web Start support)"
Last I checked, JMF didn't have any sort of reasonable lossy audio codec with it. Seemed like a no brainer to include Ogg/Vorbis and then not have to worry about patents.
Hot Code Replacement
Hey, even if the shorter fix cycle is not a reason enough (Hint: What is it that people like so much in Ruby on Rails?), hot swapping could be used for so many other things: low-overhead profiling and monitoring (check JFluid, currently NetBeans profiler) or aspect-oriented programming (check AspectWerkz and JBossAOP). Even Design-By-Contract's implementation could use a boost because of this RFE.
In regards to structs... Please... no more C features in Java. It is bad enough we have primitives.
Ad "Enhance Hot Code Replacement":
First off, an extract from JSR 292 (http://jcp.org/en/jsr/detail?id=292):
Specifically, we seek to add a new JVM instruction, invokedynamic, designed to support the implementation of dynamically typed object oriented languages. We will also investigate support for hotswapping, the capability to modify the structure of classes at run time.
This JSR 292 is about "Supporting Dynamically Typed Languages on the JavaTM Platform", which is mostly about introducing this invokedynamic instruction in the JVM.
So enhanced hot code replacement would practically be a byproduct of this JSR 292.
I don't know if Sun has any other solutions to this hot code replacement problem, but this solution will definitely take a little while until available, because the JSR 292 is just getting going.
Another bad expert, please if you do not know what you are talking about can you shut up
what I meant to say was: thanks for posting these opinions.. it really helps to bring the conversation out.
re: lack of html pane, wouldn't validating the html to xhtml using something like jtidy first do the trick? occasionally it may yield unintended results, but probably no worse than a buggy implementation.
On the subject of HTML support, readers might want to check out the TagSoup library at
http://mercury.ccil.org/~cowan/XML/tagsoup/ . I presume this is the solution that Markus Schlegel was referring to in his comment.
My own "pet deficiency" in the Java ecosystem is the lack of a standard application skeleton for Applets and GUI-based programs on the desktop (think of Borland Delphi, where hitting "new" in the editor yields a blank, but fully responsive application with all the wiring and infrastructure ready to go). Of the various things I blame for Java's continuing failure to impress on the desktop, this is the one that still hasn't been fixed (I believe there's a JSR now).
BTW: concerning the possible JSR-292 solution to the "Enhance Hot Code Replacement" issue (or at least some parts of it), Gilad Bracha has an interesting post in his blog.
Changing the current directory is useful in windows so that your files are loaded/stored based on the current directory.
Chris, I reject software patents as a fundamentally harmful idea, so as such, the validity of AT&T's claims does not particularly matter to me. Living in the EU, I do what I can to keep that particular sort of anti-social behaviour out of my legal system.
As you say, it doesn't matter if the claim is valid, it matters if someone has the lawyers (or guns & credits, on the international floor) to back it up. As far as ogg * goes, vorbis is patent free for all we know atm, and theora is basically on2's vp3 codec with an ogg vorbis audio container, with a patent covenant from on2 [1].
As for commercial relevance, Flash does not use MPEG4, and still managed to rock the online video distribution world in a major fashion in the past year, as all the hot new social video sites/YouTube lookalikes are using Flash to distribute their content, rather than using H.264/WMA/RealVideo/QuickTime or another format. There is a niche for Java in there somewhere ... and I hope freecast finds it. Of course it uses ogg. ;)
cheers,
dalibor topic
[1] http://svn.xiph.org/trunk/theora/LICENSE
pano mag download??