You've been able to can auto-close a closable thing for ages now.

try(Reader r = new FileReader(/*blah*/)){
   r.whatever();
}
// r is automatically closed

But today I found that it works for something you already opened!

Reader r = new FileReader(/*blah*/);
try(r){
   r.whatever();
}
// r is automatically closed

This came up because I had a list of files and I wanted to close each one after handling it. So I couldn't create it in the header of the try block.

(Cross-posted from my own account - I put it there because I forgot this community existed!)

There are so many ways to iterate in Java. 8~(

Suppose that we have

class Thing{...}
interface Processor{void process(Thing thing);}

We want to process each thing. How do we complete this method?

void processAllThings(List<Thing> things, Processor p){
    // ???
}

1. old skool C-style:

   for ( int i = 0; i < things.size(); i++ )
       p.process( things.get( i ) );

   Bonus variant 1:

   for ( int i = 0; ; ) {
       if ( i >= things.size() )
           break;
       p.process( things.get( i++ ) ); // careful where you put the ++
   }

   Bonus(?!) variant 2:

   for ( int i = 0; ; ) {
       try {
           p.process( things.get( i++ ) );
       } catch ( IndexOutOfBoundsException x ) { // spot the bug
           break;
       }
   }

   Bonus(?!) variant 3:

   for ( int i = 0; ; ) {
       Thing thing = null;
       try {
           thing = things.get( i++ );
       } catch ( IndexOutOfBoundsException x ) {
           break;
       }
       p.process( thing );
   }

2. You can use while (but who does that?)

   int i = 0
   while ( i < things.size() )
       p.process( things.get( i++ ) );

3. You can use do... while (but who does that?)

   int i = 0
   do
       p.process( things.get( i ) );
   while ( ++i < things.size() ); // careful where you put the ++

4. Still left over from before 1.2:

   Vector v = new Vector(things);
   for ( Enumeration e = v.elements(); e.hasNextElement();  )
       p.process( (Thing)e.nextElement() );

5. Still left over from before 1.5:

   for ( Iterator i = things.iterator(); i.hasNext();  )
       p.process( i.next() );

6. Still left over from before 1.8:

   for ( Thing thing : things )
       p.process ( thing );

   Bonus variant for newer Java versions:

   for ( var thing : things )
       p.process ( thing );

7. Arrived in 1.8:

   things.forEach(
       p::process
   );

   Bonus variant 1:

   things.forEach(
       thing -> p.process(thing);
   );

   Bonus variant 2:

   things.forEach(
       new Consumer(){
           @Override public void accept(Thing thing){
               p.process(thing);
           }
       }
   );

8. Can't be bothered with the lambda variants this time.

   things.stream()
       .forEach(
           p::process
       );

Phew! Hmm - I probably missed some...

I've been using Groovy. It's a pleasant scripting language that runs in a JVM, and has a Java-ish syntax. There are a number of differences to Java. One is it's relaxed attitude to typing, which I noticed when returning to something I wrote a while ago.

if ( someCondition ) {
    // do stuff...
} else if ( anotherCondition ) {
    // do other stuff...
} else {
    barf
}

WTF is barf? It looks like I was roughing out the code, and intending to come back to throw some exception if neither condition is true. In Java, the compiler would have complained about barf. But in the relaxed world of Groovy, the code works. After a little testing, I find that executing barf produces groovy.lang.MissingPropertyException: No such property: barf which is pretty much what I wanted!

I'm working on a project which involves a lot of JSP in an "interesting" CMS. We have a consultant helping us with the "interesting" bits. Today he gave us a JSP containing the following (some details elided to protect the guilty):

String sql = "SELECT * FROM tree WHERE id in (
	SELECT parent FROM tree WHERE id=" + parent + ")";
parents = cms.SQL ( sql );

I'd like to propose this for the canonical example of what *not* to do.

Edit: Many people dislike JSPs. They don't bother me, but they do allow you to do anything at all, not just rendering. In this particular case, the JSP has to know about the database table structure [sigh], and it should (but probably doesn't) sanitise the parent parameter [sigh], and it has to have a database connection wrapper object [sigh].

I'm even a little miffed about pointless local variable sql, but I'll let that one go. Oh, and KEYWORDS in UPPER case annoys me too, but some people think it's more readable.