 |
|
 |
 |
||||||||
|
 Graham Hamilton's BlogCommunity: JDK ArchivesHurtling Towards JavaOne...Posted by kgh on May 05, 2006 at 09:13 AM | Permalink | Comments (3)I'm in my normal ten-days-to-JavaOne panic phase, but the various pieces are starting to come together. Bill Shannon are I are finalizing the slides for the JavaOne 2006 Technical General Session at 12:15 on Tuesday the 16th. This is the session where we provide the overall roadmaps for the Java SE and EE platforms, to try to give people a context for the many individual technical sessions and BOFs that follow. As usual we're panicking over having far too much material for the available time. We'll be covering Mustang and Java EE 5, but we'll also have a section towards the end looking forward to Dolphin and other new technologies. This year we're including a range of demos, so you can see the reality, both of the "Now and How" for Java EE 5 and for some of the future ideas. So grab your box lunch and bring it into the keynote room for our 12:15 start! The program of general sessions start with the Tuesday morning Sun executive keynote with Jonathan Schwartz and Jeff Jackson. The Thursday morning keynote from Erich Gamma and John Wiegand of IBM should be particularly interesting: it promises many insights from their Eclipse experiences. And on Friday, Scott and James will show us the latest, greatest, craziest, most fun Java innovations! There are, of course, a vast range of Technical Sessions and BOFs covering all kinds of key Java technologies. but, in addition to the sessions and BOFs, I wanted to plug a few associated community events:
Now I have to run - Chet has just got me some new benchmark data to expose (!) concrete numbers for the benefits of the famous Gray Rect UI fix...
My Favorite (Dead) Java BoilerplatePosted by kgh on November 13, 2005 at 04:03 PM | Permalink | Comments (31)In the Java platform we have tended to focus on adding lots of power and flexibility. That's great, but sometimes that power and flexibility can get in the way of doing common tasks. As part of the Ease-of-Development initiative we have been focusing on simplifying common tasks and getting rid of unnecessary boilerplate code. Here are my five of my favorite cleanups so far: #1: Opening a Text File In JDK 1.1 to 1.4, in order to open a simple text output file you needed to do: FileWriter fout = new FileWriter("fred.txt");
BufferedWriter bout = new BufferedWriter(fout);
PrintWriter pout = new PrintWriter(bout);
Say what? Why are we having to type three "new"s in order to do what should be a simple operation? In Tiger we have finally added direct support for the common case and now you can do: PrintWriter pout = new PrintWriter("fred.txt");
This is an interesting example of a common glitch in our thinking. In the Java platform we often like to provide lots of well designed, well separated components that can be plugged together in interesting ways. In fact some people might argue be that the design is cleaner if the PrintWriter class doesn't know anything about files. Well, personally, I don't think so. I think it is good to provide clean, well separated components, but we also need to provide simple shortcuts to support the most common use cases. #2: Avoiding the Content Pane Pain In JDK 1.1 to 1.4, if you wanted to add a Swing GUI component to a container you simply said container.add(component). Well, yes, except that if the container happened to be a JFrame you would get a helpful runtime exception saying that you ought to be saying frame.getContentPane().add(component); Umm, say what? Rather than raising the exception, couldn't the JFrame.add method itself call JFrame.getContentPane().add()? Yes it could. And in Tiger it does. Now you can just call add, as you would with any other container object. frame.add(component); This only saves a few keystrokes, so is this really a big deal? Yes. The real saving is that you can avoid having to learn a whole new unnecessary concept. The reason that the JFrame.add method originally threw an exception was because JFrames actually support three different panes (content, glass and root), and it was considered important to educate developers about those choices. Well, I've written various Swing applications over the years and I've never actually found the need to exploit the various different panes. The old behavior of JFrame.add forced me to go away and learn about panes. And that was distracting and unhelpful. The lesson here is that (once again) it is normally better to provide simple sensible defaults and to avoid forcing people to learn about complex options. #3: Self Registering JDBC Drivers Since JDK 1.1, in order to load a JDBC driver, you needed to do: Class.forName("com.fred.FredDriver");
Connection con = DriverManager.getConnection("jdbc:fred:fredsite.com");
Umm, what exactly is that Class.forName doing there?
This one is my fault. Back in the early days of JDBC, we needed a way
for the JDBC DriverManager to locate drivers. We arranged that newly
loaded driver classes would register with the
DriverManager. And then we asked that developers call
"Class.forName" to force the driver class to be loaded.
Sigh. This is an ugly wart. I'm happy to report that this one is going away as part of JDBC 4.0 in Mustang. The JSR-221 Expert Group is adding a new mechanism so that the JDBC DriverManager can locate and load driver classes without the need for developers to explicitly type Class.forName. So you will be able to just do the obvious: Connection con = DriverManager.getConnection("jdbc:fred:fredsite.com");
#4: Locating Resources in J2EE In J2EE 1.4, if you wanted to locate a reference to a remote EJB you needed to type: Context context = new InitialContext();
Object obj = context.lookup("fred");
FredHome fred = (FredHome) PortableRemoteObject.narrow(obj, FredHome.class);
Yikes. What on earth is going on with that PortableRemoteObject.narrow? I have to confess that I'm one of the prime culprits here and, given some of the constraints, it may have been unavoidable. But I think this one definitely does win "Ugly Boilerplate of the Year". As part of Java EE 5, there are now specific mechanisms for dependency injection, so you can now replace that code with a simple annotated field definition: @Resource FredHome fred; And then the Java EE runtimes will take care of locating the resource, doing the "narrow" for you and injecting the resource object into your field. By default the resource name is inferred from the field name and the type is inferred from the field type. This is an example of using JSR-175 annotations to restructure how we handle a common task so that it can become much simpler. I'm very excited with what is happening with annotations as part of Java EE 5 - I think it is allowing us to greatly simplify Java EE programming. And I'd like to find more ways to use annotations in Java SE, too. #5: Iterating over Collections My last example is from Tiger. We've all been used to typing some standard boilerplate for iterating over collections, such as: Vector<Wombat> v = getWombats();
Enumeration<Wombat> e = v.elements();
while (e.hasMoreElements()) {
Wombat w = e.nextElement();
...
}
Josh Bloch successfully argued for a language change to make it easier to iterate over both collections and arrays, so now in Tiger we can do: Vector<Wombat> v = getWombats();
for (Wombat w : v) {
...
}
We all knew this would be useful, but I have been really surprised by how much I have enjoyed using it, for both arrays and collections. This has turned into one of my favorite Tiger features. The resulting code is distinctly easier to read, partly because we have managed to eliminate an unnecessary local variable. This is an example of fixing a boilerplate problem we barely realized we had. I'd like to find a few more things like this! To be continued... I'll continue this topic in my next blog.
Help Crack The Java VerifierPosted by kgh on October 30, 2005 at 06:05 PM | Permalink | Comments (0)Sun is asking the developer community to help attack the new bytecode verifier in Mustang. Here's some background on how and why the community can help here. In developing Java SE 6 ("Mustang") we have adopted a more open, community-based, development model. As part of that we are releasing complete binaries and sources for all our weekly Mustang builds at mustang.dev.java.net and we are also recruiting community contributions into the release. In previous JDK releases we had waited until the releases were functionally complete and stable before we released our first binaries as official betas. And we waited even longer (often until final release) before making available full source for the releases. After all, why bother to release incomplete builds or non-final sources? We all want to be seen and judged on our best work, not on our rough drafts, right? Well, we were partly right and partly wrong. There are many customers who are only interested in seeing the final, stable end product. They want to download something that will work well for them and they don't want to see the intermediate development steps. That approach is perfectly valid and makes a lot of sense for many busy customers. And we don't want to delay or distract those customers. 
However, it is also clear that there are many developers who would like to act as collaborators in helping to make Java SE better, both by reviewing the work in progress and by actively contributing code and insight into the release. For that community, exposing rough drafts makes perfect sense. These are our coauthors who are helping us create the final work. That is why we created the mustang.dev.java.net collaboration site so we could expose interim builds, get feedback, and incorporate changes from the community. We've already been receiving a lot of feedback on Mustang based on the various weekly builds. That has been much appreciated and has been helping us to tune and adjust the release as we go along. Thank you. But now we have come to a particularly scary moment and a particularly important opportunity for the community to contribute to Mustang development. As part of Mustang we will be delivering a whole new classfile verifier implementation based on an entirely new verification approach. The classfile verifier is the very heart of the whole Java sandbox model, so replacing both the implementation and the basic verification model is a Really Big Deal. See Gilad Bracha's blog for an overview of the new verifier plus links to the spec. The new verifier is faster and smaller than the classic verifier, but at the same time it doesn't have the ten years of reassuring shakedown history that we have with the classic verifier. The new verifier led us to an interesting test of our new development philosophy. Should we delay exposing the new verifier for as long as possible? Or should we push it out, advertise it, and ask for the community's help in reviewing it? Well, I will confess that many of us had an initial fit of the heebie-jeebies about publishing the source code for the new verifier. "But what if someone finds an ugly security hole?" Gasp! But that question does kind of answer itself, doesn't it? If someone spots a problem we can fix it and we can fix it before we finalize the release. Happiness! We think the new verifier model is sound and we are taking various steps to review the actual implementation code. But the more eyes that can look at this before it goes into production use, the better. As a result, Sun has launched the Crack the Verifier initiative. Read the article for more details, but broadly Sun is looking for security experts and astute hackers in the Java community who can help review the new verifier and help discover any potential holes in time for them to be fixed in Mustang. I hope people will rise to this challenge. This is definitely a case where broad community involvement can trounce what any one individual company can hope to do on its own. I hope this will be an opportunity to demonstrate that community-based development can really help improve a core area of a key Java technology. Now, I'll also be extremely happy if what happens is that a lot of people look at the new verifier and no one finds any holes. That will be a good outcome! But if there are any holes, let's find them now...
Slides for JavaOne Technical KeynotePosted by kgh on July 10, 2005 at 05:31 PM | Permalink | Comments (6)Here are the PDF slides for the JavaOne 2005 Technical Keynote (450 K). The Technical Keynote is our attempt to provide a high level overview of the roadmaps and big directions for the core Java platform. The rough agenda was:
The JavaTM ME roadmaps were covered in a special kickoff session for the Java ME track. (We had way too much material to fit into a single keynote session.) The Technical Keynote aims to provide a high level overview to help set direction at the start of the conference. But the real technical meat is, of course, in the individual technical sessions. The PDFs for all the technical sessions will be going on-line in a few weeks and those will provide much more detail on specific areas.
| ||||||||
 java.net RSS Feeds
|
