Why closure must be called using invokedynamic ?
In the latest Javaposse episode (Java Posse #078 - Listener Feedback) they identified me as "The dude in charge of open sourcing Java" ... (go :20.0 in the podcast)
heh... That's shades of Brian Harry nominating me the dictator for life over Java. But, hey, it's not true. There's other people in charge of open sourcing Java SE, I'm simply involved with the process.
So while I'm here, howzabout...
I'm not a security expert or anything, but I thought I knew enough about those stuff to get by. But when I looked at the new Java Web Start security dialogs in SE 6, I get nervous. AFAICT, this dialog is bit dangerous. But if the security experts of Java SE think these are fine, then I must be missing something. So what am I missing?
I'm writing about open source and the Java platform over on my other blog - here are links in case you're interested (updated December 9, 2006).
SUN is preparing to release part of Java technologies under
OSS licenses. Who is the best person to choose the best license
- I or you?
This article: IBM takes potshots at OpenSolaris has some interesting things to say about open source projects being more than the license that allows freedom. It's about the community that's built around the open source project. However I don't want to go into the specifics about IBM's characterisation of the Open Solaris community.
At the end is a rather interesting quote:
And making IBM's...
Sun is retiring the Mustang and Dolphin code names today and opening the JDK 7 project (formerly project Dolphin) on java.net.
Okay, cool, we're finally making announcements about our open source plans.
We have 'portal' page collecting the open sourcing information. We have a forum for your feedback on the open sourcing of Java SE. There is discussion from Mark Reinhold, Danny Coward, Simon Phipps, Tom Marble, and perhaps you might think my earlier blog posting might be included on that list.
There are discussion threads on Javalobby, slashdot, Digg, osnews.com, TheServerSide.com,.
There's an interesting article at C|NET News which repeats the fallacy that Sun is a proprietary source company, when Sun has contributed lots of software to the open source world, and not just recently but throughout our history. Another at zdnet blogs relates some discussion made by Rich Green and Laurie Tolson at LinuxWorld yesterday. We haven't settled on licenses or governance models.
In another article at tech news world Simon Phipps is quoted saying "If I could snap my fingers and make [Java open source] happen tomorrow, I would. It's not a simple endeavor. You can't just slap a license on things. You have to be sure that you have the rights to every line of code. So we have to work through all sorts of issues -- legal, access, encumbrances, relationships with Java licensees," ... this is so very true. It's not just encumbrances, though that's a big deal, but there's a cultural shift that is going on here as well. The Java team has been working on Java for, oh, 13 years or so (11 years since it was made available publicly) in a more traditional product model. To shift to a collaborative community engaging model takes a very different mindset.
My interest, coming from the role I have in the team, is with the role the Quality Team plays in this picture. As the whole picture begins to unfold, as we bring more of this to the public, we can expect the quality team to have more presence. We're thinking about a range of possible projects from publishing metrics, to collaborating on test development and execution, to collaborating on test tools development, and more.
Yesterday, Sun announced it will take another step towards open sourcing the JDK.
Many thoughts bubbled up from listening to FLOSS Weekly 11: Guido van Rossum ... so here's a couple.
First, they discussed the major complaint against Python, a complaint that has kept me from learning the language lo these many years since I first heard of it way back in the early 90's. Namely, it seems broken for a language to use white space as anything important like delineating "blocks"....
Here's an interesting question: How many of your Windows apps use the native Windows UI? (dzone.com)... Prashant Devi asks that question, in a moment of realization that almost none of the applications he uses daily use the standard Windows UI.
To me this begs the question ... what value is the standard Windows UI if almost no application uses it?
The story has been, for years, that users are confused if different applications use different look and feel arrangements.
I used to argue this exact point in 1992ish .. at that time I was designing a cross-platform email client that was supposed to run on Windows, Mac, and if possible on System V. My team at that time was evaluating the then-available cross platform GUI toolkits .. some followed a policy of "must use the system provided GUI components", where others followed a policy of "we'll draw our own widgets" ..
This is kind of like the current SWT versus Swing argument .. except it was happening 15 years ago.
At the time I thought, hey, those poor users will be confused if every application is different. But today, hey, with the wide variety of skinnable applications and UI designs, if the users aren't confused by the current environment, then will they ever be confused? I don't think so.
However ... let's take this with a grain of salt, or rather some perspective.
There's the issue of metaphors and behavior styles. I don't know the official UI terminology .. but .. if you want a user to treat something like a button (e.g. know they can mouse over and click on it) then it oughta look something like a button. Ditto with the other basic components like lists or trees or whatnot. It's not that the component has to look rigidly like the platform designer thought it should look. But so long as it looks like what it's supposed to be, then the user will be able to work with it.
Think about what frequently happens on highly Designed web sites. The only way to navigate some of these sites is to mouse over every possible random widget and see what reacts to your mouse. Some of these sites give little or zero clues what are clickable and what isn't.
Modern GUI and website toolkits offer designers tremendous flexibility. Designers can potentially have a field day making beautiful looking applications .. you can certainly go way too far, making a brightly polished thingy with lots of sparkle and flash, but leaving the user completely clueless as to how to interact with the thing.
The way JDBC 4 defined how to create an empty DataSet using the query
interface introduces a meta protocol mix.
"We" are having planning and discussion about how to handle Sun's Java implementation as open source. I've seen several articles and blog postings from the folk directly involved in the discussions, and it's all very interesting. What I'm most puzzling over is, what should the quality team do or publish etc in this environment?
In my past reading it was most enlightening to learn that one of the major advantages of an open source project is -- the public has more ability to gauge the quality of that project, than they can with the typical closed source project.
Now, in the book I was reading the distinction they were making is a typical closed source project where all you get is a binary, versus the typical open source where you compile it yourself or install prepackaged stuff from some repository off the net. Of course Java has always been in a middle area between those two extremes, making the source available, and more recently being more open with the source, accepting contributions, etc. But even so, there is a major mindshift difference happening in the Java team as part of moving to an open source project.
In my case I'm leading the discussions in the quality team to plan what the quality team ought to do as part of the open source Java project. One issue is there are few examples, because in the majority of open source projects there is not a dedicated quality team, and instead either there's no formalized testing or else the developers follow a test driven development process and think they don't need formalized testing beyond their unit tests.
With the few examples available to us of an open source project with a dedicated testing team ... let me ask you, our public, your opinion. I am making zero commitment to do anything you say, but I do value your input and advice.
What information / metrics / reports / plans / tests / etc would you find helpful to see to help you gauge the quality of Sun's Java implementation?
Is scripting environment more usefull for end users than
for developers ?
Why the signature of the SwingWorker's process method changed ?
Perhaps not only to bother developers that already play
with JDK betas.
Recently I've seen several people ask what the cost of enabling
JMX monitoring on an application is. If I run with
-Dcom.sun.management.jmxremote and connect
jconsole, how much will that affect the performance of my app?
Here are the results of some highly unscientific
There was a little "discussion" about the inclusion of Java DB into the JDK. I was on vacation and didn't read it too deeply.
At least a) it's only in the JDK, and it's the JRE download size that's more of an issue than is the JDK download size ... b) it's not in rt.jar but instead a separate directory in the JDK ...
What struck me, though, is the idea that a database is only suitable for server side applications. And that a database is only suitable for Java EE usage. Well...
Generally I think that's a very limited viewpoint. A database is a general data storage system, and it's suitable to a wide array of applications.
For example .. an email client (e.g. Columba) might want to include a full text search engine (e.g. Lucene). Lucene, for example, uses an SQL database to store its indexing. Hence, Columba, if it used Lucene, would need an SQL database. The general form of that use case is .. any application that deals with a large set of text files might well want to store full text indexing of those text files.
There's many other kinds of applications where a database might be a good idea. For example iPhoto doesn't necessarily require a database, but one could be useful. An MP3 player might store its association of playlists to songs using a database.
What triggered writing this posting is the announcement here: Meta Tracker is a powerful desktop-neutral first class object database, tag/metadata database, search tool and indexer.
I often want to test that my MBeans work correctly when accessed remotely. For example it's easy to accidentally introduce non-serializable objects in them. It's a pain to set up a real remote connection, but you can make a loopback connection in the same JVM to test most of the same things. Here's how.
MBean proxies allow you to access an MBean through a Java
interface, writing proxy.getFoo() instead of
mbeanServer.getAttribute(name, "Foo"). But when you create a
proxy, there is no check that the MBean actually matches the
interface you specify, or even that the MBean exists. Why is
that, and what can you do about it?
A brief update about what's been going on lately with Java SE and the JDK Community -- Mustang, Dolphin and more.