Friday February 01, 2008

JavaOne submission acceptance letters - and rejection letters - starting going out last night. This year, I was on the review committee for one of the tracks, so I got to see the proposals as well as the reasons for rejecting many of them. I thought I'd write these up, both to explain to the many submitters what might have gone wrong, as well as to give some tips for how to improve your chances next year. I'll probably link back to this post around the time submissions for JavaOne 2009 open up later this year.

• Not Enough Details! There were a number of submissions that sounded interesting, but didn't include enough details for us to judge whether there is enough technical meat behind the promises. If you're promising insights or "lessons learned", tell us what those lessons are, such that we can judge whether your presentation will be worthwhile (and in particular, whether to choose your submission over the handful of other similar submissions in the same topic area).


• Wrong category! I was on the Tools and Languages track. You wouldn't believe how many submissions to our track were not related to tools and languages. Framework, Practices, Process or Methodology: If any of these words are in your title, make sure you're really explaining how this is going to be tool related or language related.
  
  So why can't we just reassign them to the right track? Well, each committee works independently, and if we were to suddenly have to accept "new" proposals that were miscategorized earlier that would increase the work a lot - we've already gone through and picked our top candidates for each subject area and so on.


• Not of General Interest! If you're submitting for a technical session, rather than a BOF, the talk will be offered in a room seating hundreds and sometimes thousands of attendees. The subject needs to be interesting to more than 20-50 people. If you're proposing a talk on a subject that is extremely narrow or a tool or language that doesn't have a lot of traction yet, you'll have better odds submitting the talk as a BOF.


• Crowded Topic! Some topics are extremely popular. We received a large number of submissions for Groovy and Ruby for example. This means that if you submitted talks in one of these areas, even a perfect abstract wasn't enough and the choice for the committee was very difficult.


• Strong Competition! At the end of the day, we only had about 20 technical sessions to hand out. We had more than ten times that number of submissions. We had roughly 10 talks for tools, and 10 talks for languages. Let's take languages - there's Groovy, Scala, Ruby, Jython, Java, ... as you can see there's not room for more than one or at most two talks in any one topic area.
  
  The good news is that this hopefully means we'll have very high quality for the technical sessions!

Finally, work one one strong submission rather than submitting 5-10 half-baked ones; just adding lots of abstracts does not help your odds given my points above about the low number of available slots; each submission has to be fantastic.

Saturday January 05, 2008

Ruby 1.9 has been released. It's a "development" version meaning that you wouldn't want to use it in production, but now is a good time to learn the new ways of doing things such that migrating to Ruby 2.0 will be easier.

Via Ruby Inside, I read James Edward Gray's recent blog entry detailing the work he did to update his library to 1.9 - and a number of people leaving comments are also pointing out language changes.

One such change mentioned is case/when statements not allowing colon as a separator. (I don't see this in Ruby Changes Wiki - does anyone have a source for this?). Seems like a a good candidate for a Ruby quickfix:

There are a couple of available fixes:

The first one is just replacing the colon with a then:

The second fix is instead putting the statement on a separate indented line:

Another language change I found in Sam Ruby's post is that you cannot write hashes as lists anymore. Here's a quickfix for that - first the code, this is from webrick's httpstatus class:

The quickfix is attached to the first list entry in the hash:

And previewing the fix shows the following proposed edit:

Tuesday October 02, 2007

If you're on OSX, and you've experienced NetBeans 6.0 beta crashing on you, read on...

Right before beta1, we tweaked some of the Java VM startup flags NetBeans uses. In particular, we switched to the "Concurrent Mark Sweep" (CMS) garbage collector, which has a nice performance profile for IDE usage, since collection happens mostly in parallel so you don't get noticeable pauses.

Unfortunately, it turns out that these flags cause a lot of problems on OSX. In particular, they cause frequent virtual machine crashes!

Knowing this, for beta2 we've turned off those flags when running NetBeans on OSX. But that doesn't help you if you're trying to run beta1... Luckily, it's easy to fix it yourself, since the VM parameters are specified in a text configuration file.

First, open the netbeans.conf file. On my Mac, I installed NetBeans in Applications under NetBeans, so the file is

/Applications/NetBeans/NetBeans\ 6.0\ Beta\ 1.app/Contents/Resources/NetBeans/etc/netbeans.conf

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m 
  -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
  -J-XX:+CMSPermGenSweepingEnabled"
# (Note that a default -Xmx is selected for you automatically.)

# For JVMs which does not support Concurrent Mark & Sweep garbage collection
# algorithm remove "-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
# -J-XX:+CMSPermGenSweepingEnabled" part of options
# (see http://wiki.netbeans.org/wiki/view/FaqGCPauses)

Remove the bold section above; in other words, remove these 3 flags:

-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

Tuesday July 24, 2007

Roman and Gregg interviewed me in the latest episode of the NetBeans podcast.

Here are the shownotes from Roman's blog:

• 0:00 Introduction and Tor's podcasting, he's also a podcaster at the Javaposse
• 2:30 What Tor has worked on at Sun: Java Studio Creator, Project Semplice, and the Ruby tools
• 5:00 Overview of Ruby features in the NetBeans IDE
• 7:25 Debugging Ruby
• 9:50 Rails support
• 10:51 Switching between Ruby implementations
• 11:49 Implementation of the type inference and code completion logic
• 17:10 Implementation of refactoring features
• 18:54 Features Tor wants to implement next
• 21:33 Community feedback
• 23:17 Why should Java developers look at Ruby?
• 26:38 Other Ruby development tools
• 29:49 A version of NetBeans IDE that just has Ruby support? Check out this page on deadlock
• 32:16 Opportunities for contributors and cool features; check out the wiki page.
• 34:55 Support for other dynamic languages. Erlang IDE based on Tor's code.

The episode is here, subscription is here.

Monday August 16, 2004

I work on the Sun Java Studio Creator product (formerly, and by the development team fondly) known as "Rave". (Well, when going public with it last spring we had to rename it "Project Rave" to avoid trademark issues.)

I'm responsible for the visual page designer, as well as the navigation editor.

On this page I plan to post Creator-related news and thoughts - as well as any other random things I want to say. Tune in if you're a Creator user, or if you haven't tried it yet, head over to www.sun.com/jscreator.