Java Spotlight 24


Roger Brinkley: Welcome to the 24th edition of the Java Spotlight Podcast, I'm Roger Brinkley.

Terrence Barr: And I'm Terrence Barr.

Roger: And in this edition of the podcast, we'll do a feature interview with Joe Darcy who is the spec lead for Project Coin. And with us again this week Java all stars Alexis Moussine-Pouchkine and Dalibor Topic who is going to be back on a more permanent basis now. In the news, Java EE7 and transparency, looks like we've got another JSR that's opened?

Alexis Moussine-Pouchkine: So, the JSR has been open for a while, yes. What's new here is that we have for every JSR that's out there an equivalent project on That is for more transparency and what that means really is that the expert groups will exchange emails and all of these emails will actually be posted to the default users mailing list on that specific project. So, the list is all the Java EE7 and related JSR's so, JRS, GPA, JMS, GSF servlets and EL all now have public projects, so you can follow what's going on. Some groups might even decide to use the Wiki or the download section, it's really up to them. But, I think it's a good step in the right direction for watching [inaudible 0:01:26] right there. You need to be a member of the project itself but that's as easy as having a account and following a given project, but you certainly don't need to be a part of the expert group to see what's going on.

In fact it's been decided that this will be the rule for every Oracle lead JSR that every JSR will actually have its equivalent project and it will be what after the acronym is.

So, jpa-spec as in specification, So, one of them for example is gms2.0 so that would be and the reason I mentioned GMS is that Nigel Deacon the spec lead is actually looking for people looking at the discussions in the expert group but also members for the expert group. And GMS has been around for really a while so I'm sure we can find a valuable set of people to contribute to that expert group.

Roger: And then, Steve Harris, there's a great article that's up on OTM. Steve Harris our senior VP on Oracles vision for Java. Most of us were out in at Oracle International User Group meeting that we had in January and we heard Steve talk about a number of these points, but it's good to see them written down on paper, good opportunity for us to go look at those. Alexis, you've got some news about NetBeans and NetBeans 7.0 release came up one.

Alexis: Right. So, I think we covered Net Bean 7.0 in the past in this podcast and other venues. I think it's going to be a great release; it has a number of features. This is release candidate one which as far as I know maybe they'll be a release candidate two, but I think we're really days maybe weeks away from a final release, so it's really, really coming close. In other news around NetBeans is people know mostly the NetBeans ID. What they may not know is the NetBeans platform and the NetBeans platform is really a rich client platform, which is used to build the ID but which you can use to build any other rich clients built with Swing. And it provides features like a module system, like a window manager and a few other things that are really useful to build. Any type of application, not just an ID. And Hurchin Elonga from the NetBeans has been gathering a number of screen shots for those applications. Some of them are really impressive because they show how much work has been put into those different applications and Hurchin has actually announced that he is running a contest for the 200th screen shot for NetBeans platform. And I think he received... he's already passed 200 and he has a blog up, you'll have the link in the share notes about this.

And interestingly enough, on the same day Dizo actually publishes a rev card for the NetBeans platform. So, if you've never heard of the NetBeans platform or if you need a well-written two pager on the main things you need to remember when actually using the platform, Dizo has this nice PDF for you.

Roger: NetBeans 7.0 RC1, these changes or this build will allow you to compile with the coin changes that we're going to talk about later in one of the follow up interviews here. So, let's turn the attention now on the mobile side. UTI has released this best practice guidelines for developing quality mobile applications. So Terrence, they got some good stuff in there?

Terrence: Right. So, if people aren't familiar with the unified testing initiative or UTI, that's an independent body that focuses on developing mobile testing standards, best practices, things like defragmentation initiative for the global mobile ecosystem. And UTI has just released a document called best practices guidelines for developing quality mobile applications, and that's across platform document that's been created by some of the UTI members, among them AT&T, LG, Motorola, Nokia, Oracle, Orange, Samsung, Vodafone, and others, it's free. In fact, you can download the PDF and they are encouraging developers to give them feedback for the next rev of this document and to just give you an idea of what's in this document, it's still at a fairly high level. It talks about things like installing and launching applications, memory usage, connectivity, external events, user interface, performance aspects, media handling and all things like that. So, this is something that's evolving, it's a start and again, they are welcoming feedback from developers on this document.

Roger: All right. On the other side, Java language specification gone into maintenance review, Dalibor.

Dalibor Topic: Alex Buckley who maintains the Java language specification and the Java VM specification at Oracle has published a blog post announcing the maintenance review of the Java language specification. So, for those of you who are not familiar with what it is, it's actually the authoritative definition of Java programming language. So, if you're a compiler writer who writes Java compilers or if you're just a language lawyer, if you want to know how things are really meant to be that's where you go and look it up. And the Java language specification has seen a couple of additions. We are now up to the third addition, it was released in 2005, but since 2005, a number of corrections and clarifications and specifications have been recorded in the public bug tracking systems at Sun Oracle and changes have been made to Java C as a reference representation of the compiler for Java language to go along with that. Now with this maintenance review, there is finally again, a cohesive document that integrates all these changes that happen since 2005 in a single publication.

Alex is, of course, hoping that people will find that the proposed specification interesting and useful and he's asking those Java users and developers that have substantial technical comments about specific changes proposed for the Java IC7 edition to send them to him directly.

Roger: OK. Let's turn now to the events section. April sixth and eighth, 33 Degree in Krackow, Poland and then on April sixth, the Northern Virginia Jug; I'll be speaking there for just a few minutes on that. That happens to occur just before April seventh on the OTN developer days in Ruston, Virginia. So, if you're in that area, a great opportunity to meet a few of us and talk with us about what's happening. The OTN today are something that occurs around the U.S. and around the world. And then April 12th, GlassFish 1.0 developer productivity features. I think this is a webinar, am I correct there Alexi?

Alexis: Yeah. This is a webinar on developer productivity features for GlassFish 3.1.

Roger: OK. And then Java 12th and the 13th, Java One, Russia, Alexi and I will be there. And then April 12th and 14th CON-FESS, Vienna, Austria. I think Dalibor you're there as well as in April 18th and 20th, and the dnevi slovenske informatike, is that correct?

Dalibor: Dnevi slovenske informatike in Portoroz, Slovenia indeed. So, this is going to be my first time in Vienna and in Portoroz as well. So, I'm very much looking forward to those too.

Roger: So, let's turn now to our feature interview and this last Friday I had an opportunity to speak with Joe Darcy about Project Coin. Now, one thing about the interview was our connection was a little bit sketchy, so our recording had a little bit of echo to it but I think the content in it is good. So, let's go directly into that interview. Joe, welcome to the program.

Joe: Thank you Roger.

Roger: Congratulations. You got 334, JSR334 which is on Project Coin out in public review.

Joe: Right. So, this is the second of the three mandatory drafts we'll be producing for JSR334 and people are encouraged to download the list of specifications and send us their comments on it.

Roger: Why the name Project Coin?

Joe: As with many good computer science terms, a pun is involved. A coin is a noun, it is a piece of small change and coin is a verb means to create a new language. So, Project Coin for JDK7 is about make it in small language changes in Java.

Roger: So, let's go into some of those changes. What's happening with the binary literals? What are trying to accomplish there?

Joe: This is one of the smaller changes on Project Coin. There are two related changes, you can now have binary literals for integers. Binary literals are just like hex literals except they're in binary and then for all kinds of numerical literals, you can have underscores between digits. So, this let's you break out the digits into groups of three or four or whatever is convenient. As a small change it's mostly geared toward a little programming where you want to use binary say, network masking that sort and the literals just let you format the number slightly and more regally in certain cases. We always have an eye toward improving developer productivity, and that often involves improving the readability of the program. So, for the improves in particular this is a small way to improve the readability in certain circumstances. And the other changes improved readability in larger circumstances too.

Roger: I got to tell you. I was at a customer site yesterday and I was talking to about 25 of their developers and when we did the strings in switch example they went, "Oh! I like this!" So, tell us a little bit about that one.

Joe: It's towards that favorites among your children but I do have a special connection to strings that switch since I did a lot of the implementation work for that. Previously integers were constants and if you had a number of constant integer values you want to group together and have some common action for them, you would typically use a switch statement for that as opposed to a sequence of if statements of some sort. With strings, even though strings have been considered constant in the language from the beginning, you haven't been able to use strings in a switch statement. And now you can. This doesn't get compiled down to if statements inside the compiler. Instead, it gets turned into a sequence of two switch statements. One that switches on the hash code of the argument string. And then a second switch statement that has the same shape as the original one, but uses integer labels instead.

Roger: Varargs warnings. I don't actually have an example of this one, when I was doing the demo. So, tell me a little bit more about that one.

Joe: It's a little bit hard to explain. But, you no longer get those uninformative, unchecked warnings from the compiler when you call library method like arrays.eslist. In a little more detail, there's a bad interaction between the generics and arrays. We had that back from JDK5. Varargs are implemented using arrays, so there's a bad interaction between generics and varargs. And because of that bad interaction, calling certain perfectly fine library methods, the arrays.eslist and one of the enumset.of methods could generate these unchecked warnings. And if you were a diligent programmer, you would have to apply a suppressed warning adaptation at each call site of one of these library methods. What we've done in JDK7, with this feature in point, is twofold.

One, we've added a mandatory warning that if you declare one of these problematic methods in your code, the compiler will give you a warning at the declamation site of the method in addition to the call secs. If the method is actually fine, in terms of it doesn't do anything harmful, there's a new annotation type you can use, Java.warning.varargs. And if you apply that annotation to your varargs method, it'll do two things. One, it'll stop the new warnings issued at the declaration site. But more importantly, it'll stop all the warnings at the use site of that method.

And as part of this change we've also gone over the JDK code base to find all the methods that should be retrofitted with annotation. After we scanned the JDK code base it turned out we only had to apply this annotation to four methods. Arrays.eslist, collections.addall, mediumset.of and a swingworker.publish method. I should also say that all these coin features have support in NetBeans.

We've been working with the NetBeans team for several years to have support for these features along the way. In particular, right now, NetBeans release candidate one has support for all these. It has support in several ways. It'll recognize the new constructs. But it'll also recognize locations in your code where you can apply the new constructs.

So, for instance, if you have a sequence of s.equals some string value in a row, in an if else statement, it'll suggest to convert to a string switch. And you can also convert between bases for integer constants. So, if you want to switch from you decimal constant to binary, to see if that might make the program clearer, the IDE can help you with that.

The release notes for NetBeans seven describe how you can configure the project to be a JDK7 project. And that will enable a use of the new language features.

Roger: One of my other favorite new pieces that you put in was a diamond piece. It didn't dawn on me what diamond was until this morning. It's the two angle brackets that are going together, and that's what's creating diamond. It was like an "aha!" moment there for me for a minute.

Joe: Right. So technically, diamond is just the less than and greater than symbols next to each other. The problem it's addressing is this. Back in JDK5, when generics were added, let's say you were initializing a variable to a value. You might have, before JDK5, just a Map. Capital "M" Map. My Map equals hash Map. In generics, with the angle brackets on the left hand side when you have the Map, you'd say what is was a Map from and to. Say a Map from strings to a list of integers. Now, on the right hand side, when you use the implementation type, hash Map, you'd have to repeat that information. You'd have to say it was a hash Map from string to a list of integers. That information's usually redundant. And with diamond we allowed the compiler to information that's on the right hand side in the constructor argument. So, now you can just say a Map of string to list of integers.

My Map equals hash Map of less than, greater than. Diamond. This is favorite once you start using it. And again, there's IDE support for this today. In NetBeans, you can auto-complete for diamond, for instance. In addition to having the IDE recognize locations, we can take existing type arguments and constructors and have them placed with diamond.

Roger: OK. Multi-catch and precision re-throws. And then try with resource. I'm kind of lumping those two together because they're kind of somewhat joined.

Joe: Right. They both deal with changes to the try statement and they do work together. You can use them in the same [inaudible 0:16:28] statement. Although we do break them up separately. The first feature, multi-catch, the observation is you'll frequently have repeated catch blocks after a try block. So you'll be catching different kinds of exceptions and you'll be doing the same action for them. Often you'll do this because you don't want to call a bad programming practice by catching too general an exception. Like runtime exception or exception itself. You just want to catch the particular checked exceptions that come out of your code. So, when you're in that situation now, you can declare a catch block to handle multiple exceptions. If you separate the types by or.

So you can say catch, exception one, or, a vertical line, exception two, exception three and then the variable. And this variable is implicitly final. That gets to the second half of multi-catch, which is precise re-throw.

Precise re-throw actually occurs for all exception parameters in JDK7 that are final or effectively final. It's a refinement to the existing exception analysis that's done. The key observation is this: If you have an exception parameter that is final or effectively final, meaning it's not modified inside the exception block, the compiler knows that if you re-throw that exception, you're re-throwing an exception that came out of the try block. That means that you're not just throwing any hostile exception that could meet the declared type of the exception parameter. You can only re-throw the exceptions that can come out of the try block. And the exceptions that can come out of a try block are often more precise. There's a smaller set of types that can be thrown. That allows us to [inaudible 0:18:09] through in a more accountable way.

For instance, if you go through your code base and you use multi-catch to place these exceptions. You don't have to change any of the throw's clauses at the method or constructor boundary. Because the compiler will know that you're just re-throwing the same exceptions you can throw today. Or maybe even a smaller set. Initially, we required you to have an explicit final declaration on a normal exception parameter for the more precise analysis to kick in.

This was done for compatibility reasons, because it's possible to write a program that doesn't compile under the JDK7 exception rules because the more precise analysis allows the compiler to find more dead code. But, this situation's a little contrived. You have to have your multiple laws of nesting and things caught and re-thrown. So, we decided we can judge the actual source impact of this if we look over a large body of code.

In looking over millions and millions of lines of code, we didn't find any instances where this source incompatibility would happen in practice. So, we decided it was better to have the more precision on by default. And if someone has this strange coding idiom, it's easy enough to fix. You can just delete the dead code.

Roger: All right. So that's it with [inaudible 0:19:23] 7.

Joe: We have our try with resources. This was initially a feature suggested by Josh Block, currently of Google. The problem this is addressing is that although the resource of memory is managed fairly well in Java, and automatically using garbage collection, for other resources that require you to manually call close, such as some kind of input output that needs to free up a [inaudible 0:19:48] descriptor, Java doesn't provide a good way of managing that. If you try to write robust code to properly call close, if and only if an exception was properly initialized, the amount of exception boilerplate overwhelms the actual logic of what you're trying to do. So, we try with resources, you can now have the try statement and the compiler manage that for you. After try, you can have, in parentheses, a sequence of resources, resource declarations. And then you have your code using the resources.

And what that means is, the compiler will ensure that close gets called on those resources if they are properly initialized when you leave the code block. Part of this feature is also providing more informative exception information. Currently, if you have multiple exceptions, say from the try block and then from one of the close calls, only one exception can get propagated out. And the one that gets propagated out previously was the exception from the close. And then the exception from the try block, all record of it would be lost. You'd have no way of recovering that.

With try with resources, the protocol is a little different. If there is an exception from the try block in an exception from the close, what happens is that the exception from the try block gets propagated out. So, the first exception that gets thrown gets propagated. Wherever there's a new facility on a throwable where you can associate suppressed exceptions with the throw. So the compiler generated code calls the throwable that adds a suppress method on the exception from the try block.

And that adds the exception from the close to the list of exceptions suppressed by the exception from the try block. Then, if you print out then exception from the try block, the suppressed information gets printed out just like the call information gets printed out today. And there's also another method that will get you a list of the exceptions that were expressed.

Roger: What are some of the high level things that you're looking at doing for JDK8? For a future rev of Project Coin?

Joe: During JDK7 [inaudible 0:21:51] , some features that were initially accepted for Project Coin and JDK7 were dropped due to time constraints. One of those was collection literals. The proposal there would be, just as you have string literals or integer literals, you have collection literals. So you could have a sequence of text in program that made a constant list. It could be a list of strings or a list of other source's collections also made over constants. I think that would be a helpful addition to the line, which there's a lot of excess code when you want to initialize and such in small collections. So, that's something we'll consider again for JDK8.

Another collection related feature that was dropped from seven was support for using the array bracket syntax with collections. In many ways, collections are superior to arrays. You have more implementation choice. You can swap out an irregular source's [inaudible 0:22:42] by just changing the declaration. You can write your own collection implementations as well, of course.

However, arrays do have this more concise mutation using the brackets. So, I think it would be helpful to be able to use that with user defined types as well as exception collection types. For Project Coin, what we did was a bit different. In the beginning of 2009, we actually ran an open call for proposals period. There was a standardized proposal form, to suggest features for the platform. We received about 70 proposals. Of those, we chose about six or seven. These six or so we're getting into the platform.

We don't currently plan to have a similar open call period for JDK8 because of the number of other language changes going into a particular lambda, but we do plan to continue work on some of these other con features that were deferred from 7.

And we're also always looking to integrate with the other language features going on in the platform, in particular lambda, and also listed in the Java SE8 JSR is a possibility of JSR 308 coming in, annotations on types. So, that will be some changes to the annotation facility as well.

There are still several routes people can send feedback to us. For example, there has been the Coin-dev list that has been an open list since its beginning. Earlier this year, after the first early draft review of JXR 334 was available, Remi Forax, who is a participant in open JDK, as well as a member of various expert groups, sent feedback to the Coin-dev list, the public mailing list that's been used for discussions of Project Coin for the last several years, that in his opinion there is a possible improvement that could be made to the try-with-resources statement in terms of its handling of nault.

Based on discussions there and discussions in the expert group and an evaluation of how that change would affect the usability of the feature, we've been looking to retrofit JDK libraries to use the new language features, in particular the try-with-resources.

So, after we ware able to make that evaluation based on discussion on the Coin-dev list, as well as within exit group, that change was reflected in the next formal specification of JXR334, the public review draft, which is now available. So, there are routes for feedback to the expert group and then be reflected in subsequent drafts of the proposals.

Roger: Joe, thanks for your time today. I appreciate it. I look forward to seeing when this comes up for a final vote and actually be able to use it in JDK7.

Joe: I do, too, and I'm looking forward to getting these features out into developers hands and also getting them more widely used in new code and improving old code that's already out there.

Dalibor: It's been very interesting for somebody like me who's not actually a language developer to watch Project Coin from its inception to the states where it's now with the JSR progressing along. When Joe initiated the project, I think he did a lot of things right that were not obvious at the time because something like Project Coin just hadn't been done before. So, to actually go out and ask developers what they think that small features are they could find useful to then go and have a public debate around those proposed language changes where experts like Neal Gafter or Josh Bloch would provide useful feedback to hone and to improve such proposals, to then go on and then pick a set of things to work on with the community, I think was very, very interesting to watch and actually a great experience to see happen in the open JDK community.

Some of the things that I think Joe did really, really well were to move from just having debates on the features to actually have a more empirical approach and with the community develop tools to actually examine bodies of code for where the features would work or wouldn't actually be necessary in these cases as [inaudible 0:27:01] .

And I think a lot of that has helped make the results of Coin fit together so well. If you look at how these features come together in 7, a lot of the boilerplate code with handling of exceptions, with dealing with, for example, catching, logging issues, with dealing with IL and Diamond and all these features, come together to actually remove a lot of code that now seems almost extraneous.

So, I think Project Coin has been one of the shining examples of what a community can do in open JDK under great leadership. So thanks to Joe, and thanks to his collaborators for making this stuff work.

Roger: Does anyone have a favorite among the small changes that are being made?

Alexis: No, I like the combination just like Dalibor said. That's really the beauty of it is how they combine well together. I mean Diamond operator if you want really want is something I've been asking for a while, and I think it's quite elegant how it came out, but really the combination, I think, is what I like best.

Roger: Let's now turn to the mailbag section. So this last week Agnes Crepet sent us an email, and she said, "I follow your podcast every week. Congratulations. They are nice and very interesting. Could you speak about our event, Mix-It, in your next podcast?" So yes, Agnes, we can certainly do that. Mix-It will occur on the 5th of April in 2011 at Lyon Epitech Computer School, and this will be mixing agile, test, Java craftsmanship and new trends, NoSQL, HTML5, etc. It'll be a full day conference to share and approve your knowledge with these domains. My understanding is that this is a sold out conference, 32 speakers and 250 attendees, so this will be a great event there.

Alexis: I just wanted to say that I was actually reading an article called, "The Overview of Java Development on the Cloud," and this was written by folks that will be presenting there. And by the way, I think it's cloud IT. It's kind of a play on words there.

Roger: This will be a great event, and certainly we would love to let people know about any of your Java events that are coming up in the next month timeframe from our podcast, so if you want to send those to us. Then the second question that I had is when I was out on the road this week in Tennessee at FedEx, a question came up as to what are the security changes going into JDK 7? So Dalibor, what are those changes?

Dalibor: We have a couple of changes coming in 7, I mean there are change levels in place, but in particular in security area I think the features that people will find most interesting are the addition of a portable implementation of the standard elliptic curve cryptographic algorithms so that old Java applications can use elliptic cryptography ECC out of the box, which was something that was actually supported in Java SE6 if you use an external library and put it in the right place and so on. And in seven it's coming out of the box with a portable implementation, which basically, makes the deployment much easier. And then another feature that I think is going to be interesting for a lot of people is that we've added support for transport layer security version 1.2 which we standardized back in 2008. And of course, GLS is already supported in an earlier version in the JDK but since Java SE6 was released back in... oh how far back was that? I think back in 2006, the TLS has gone through a revision or two in-between, and we have updated JDK7 to support it.

The code for these features actually since we're feature complete is already in JDK so if you wanted to give them a shot, make sure to download one of our weekly builds and try them out, and of course give us your feedback.

Roger: So let's now turn to the "What's Cool" segment. So Alexis, what's cool?

Alexis: Oh, what is cool is WebSockets and GlassFish. I did a post on The Aquarium recently mentioning the status of web sockets which is kind of a moving target given the spec isn't final just yet, and we had to ship 3.1. And I had a lot of very positive feedback for that, so I think we should be talking more about it. I think that's one of the unique features of GlassFish. There are many more, but that one kind of went unnoticed given all the clustering theme we had overall for this release, so we'll have a link in the show notes for that article.

Roger: Dalibor, what do you have that's cool this week?

Dalibor: Yeah, what's cool this week is actually that I have the pleasure of being back on the show. My little girl is now three months old so I have more time for fun activities like this one. But of course, the really cool things in JDK things what's cool is that Paul Hohensee has been busy. He is one of the really great HotSpot guys, and he's added a patch to HotSpot in JDK7 that allows tracking of the cumulative Java heap bytes that are allocated on a per thread basis so that you can actually get better diagnostics on how much memory your threads consume, which I think is going to be very interesting for people who are writing application service, for example.

Then of course, the Mac OS X port in open JDK has seen some significant updates. The developers from Apple and Oracle have been collaborating, and there is now an initial check in for a Cocoa-based AWT implementation and lightweight peers. In the show notes you can find the corresponding thread on the Mac OS X port, develop the main list, and of course, if you want to see the code, the comment is in there as well.

And finally one thing that popped up in my feed reader I just wanted to mention was that I saw last week there was an open JDK6 port for OS/2 and in ECS, and I'm not sure how many of you actually know about OS/2.

Roger: You mean Warp?

Dalibor: Right. Exactly [laughs] . Right. And I think ECS is a full up version of that. And somebody has been actually taking the open JDK6 code base and working on a port. They're up to release kind of two based on the most recent open JDK6 built, build 22, and the link is of course, in the show notes in case you are an OS/2 user or a CS user and want to go and check it out. This kind of demonstrates the nice things about open source communities. They will take a project into environments that one would not have necessarily expected before. So the community has been able to take up the open JDK6 code base and run with it and make it work as far as I can tell from the screen shots on their favorite platform. And I think that's a very, very cool aspect of open source development and open JDK in general.

Roger: So, my what's cool for this week has to do with two people that work from Oracle, Rafael Tores and Fred Louis. Just a big "thank you" for the work that you did this last week. These guys were instrumental in setting up all of the meetings that we had, that I had in Tennessee this last week, and then were very gracious in meeting me in Memphis and renting a car, driving that car, and driving it to Nashville, and then driving it on to Knoxville from there. So a big kudos to you guys and the work that you did. I think it was a great effort, and I know that your customers greatly appreciate what you did.


Roger: Thanks for listening to the 24th edition of the Java Spotlight Podcast. I'm Roger Brinkley.

Terrence: And I'm Terrence Barr.

Roger: And send your feedback to

Transcript by CastingWords