Some random thoughts from Day 1 of JavaOne 2008 (belated):

Wi-Fi connections spotty at best.  Kind of disappointing they couldn't handle the traffic they could have reasonably expected.

"JRuby: What, Why, How...Do It Now!" -- Nice JRuby overview.  An admonishment not to be scared to let go of static types -- nice.  Interesting how Groovy lets you go either way, sticking with the manifest typing of Java or introducing latent types as you please. 

Demonstrated blocks for deferred invocation, and their uses in internal collection iteration and encapsulating transactional code -- important use cases for their potential inclusion (closures) in the Java core language.  I wonder if such language features are better left to the other JVM-based languages that are sporting them already, rather than over-complicating what started out as a simple language.  Josh Bloch speaks often of a "complexity budget" for a language, and that perhaps Java is overspent.

Much of Rails code is created on startup.  Interesting.  Cool that Ruby allows you to define classes and methods at runtime, and to open up classes for such additions.  Cooler still that in JRuby, core JDK classes become open (even those that are final).  Apparently the term for opening up and tweaking core classes in this way is "monkey patching" -- derogatory term in the Python world, celebrated in the Ruby world.

JRuby leverages native threading of the JVM for better performance, as opposed to the "green threading" of the MRI.  There is a jirb analogue to irb in JRuby -- nice.

"require 'java'" to use JDK classes in JRuby code.

"require 'irb/completion'" in jirb to enable auto-completion in the console.  Sweet.

Java methods can be invoked in their regularCamelCaseWay or via_lower_case_underscored_names.

Plenty of help for building Swing apps in JRuby -- Cheri::Swing, Profligacy, MonkeyBars

"More Effective Java" -- New edition of Bloch's "Effective Java" is out -- covers new ground of generics, annotations, enums, concurrency libs, etc.

Use wildcard types, bounded or otherwise, generally only as method parms, not as return types.

'PECS' -- Producer extends, Consumer produces -- mnemonic for remembering when to use ? extends X versus ? super X.  If a method is both a producer and consumer of X, no wildcards needed on the generic type.  Users should not have to think about wildcards to use your API.

Enums -- do not rely on ordinal() for business logic, if you need to use an integer distinguisher as a field for each enum, use a constructor with an integer parm.  Don't depend on which ordinal() integer is assigned to each member of the enum.  Good discussion of EnumSet and EnumMap.  Bit fields are obsolete in Java.

The power of readResolve() to enforce singularity of singleton Serializables has been oversold -- readResolve() works only if all fields of the Serializable are transient.

Enums are inextensible, but can implement interfaces and each member of the enum can supply an implementation.

Good discussion of various lazy-init techniques.

Java 5 memory model enhancements apparently make double-check locking idiom work now.

"Upcoming Java Programming Language Features" -- Alex Buckley, spec lead for JDK 7 JSR, speaks of stewarding the "moral and technical integrity" of Java.

"A good application is rich; a good language is pure." Gosling, about adding features to a language: "Just say no, until threatened with bodily harm".  Tougher to add language features due to the explosion of interaction between the features.  In an app, features relatively rarely interact, and more is considered better.  Not so with language features.  With a language, fewer, more regular features are better.

"Respect the past": new keywords shouldn't break existing code (a la 'assert', 'enum').
"Respect the future": allow room for syntax to breathe.  Syntax/semantics of a feature should not conflict with those of existing or potential features (quite a tall order!)
"Respect the model": every language reflects a model of computation.  Java's model: general-purpose, class-based, OO, concurrent, civilized relationship to APIs, aligned with JVM.  When evolving a language with features, have those features enable more regular and abstract programs.

Principles that recognize the Java model:

• Encourage high-level practices -- do the right thing
  • A program's meaning is hidden by accidental complexity (Fred Brooks)
• Covet clarity -- do the thing right
  • A program is read far more often than written/modified
  • Language abstractions are the primary enabler of clear code
• Prefer static typing -- stay safe
  • Proves absence of some bugs at compile time
  • Most Java keywords are about static typing
• Isolate the language from the APIs -- stay abstract
  • A language is more widespread than its APIs
  • APIs come and go, language remains
  • Language compromised by linkage to a deprecated API.
  • JLS used to define java.lang.

Under consideration:

• Disjunctive exception types in catch statements (yay!)
• Safe re-throw of exceptions in catch blocks when exception var is marked final
• First-class modularity support in the language and tooling
• JSR-308 using annotations to effectively introduce pluggable type systems into language -- for enforcing things like @NonNull, @Readonly, @Immutable, etc.

Not of interest:

• User-defined operator overloading
• Multi-methods
• Macros
• Dynamic typing (latent typing)

"GUI Testing Made Easy" was a nice introduction to the FEST library by former ThoughtWorker Alex Ruiz.

"Practical Applications of Static Bytecode Analysis and Transformation for the Java Platform" -- great demonstrations of tools that use libraries like ASM for tweaking bytecode in interesting ways:

• Cobertura for instrumenting bytecode to be executed by tests, and measuring coverage of that code when tests are executed against it
• Google Singleton Detector
• Google Testability Explorer

"Tips and Tricks for Using Language Features in API Design" -- lots of material to cover in a very short time.  I felt the speaker just ripped right through some topics that to me were non-obvious.  Slow down!  Interesting to learn a potential good use for wildcarded generic return types: return of an internal collection without having to copy it (callers won't be able to add/modify).

Be wary of interface covariant returns -- great for concrete impl classes, but in branching interface hierarchy, watch out.

If you're going to add an exception type, maybe make it carry more info other than just a new name?  Cause?  How to recover?  Also, in libraries, do take care to add serialVersionUIDs to your exception classes -- Exceptions are Serializable.