Java 7 Launch - Hits and Misses

Java 7 will be "launched" today with all sorts of hype and gala. After reviewing the presentation materials Oracle sent out, I figured I would throw in my 2 cents on Hits, Misses, and Who Cares Anyways?

Hits

•  The new try/catch - In Java, it's cool that you can catch individual Exception types. You may want to treat different Exception types differently. But let's be realistic: a good percentage of the time you end up treating all the Exceptions in the same way. And while it is considered bad form to just catch a superclass, I also don't like repeating those same lines of code in each catch block. As part of the COIN JSR, Java 7 introduces an "or" operator in the catch block, so you can have one catch block that catches, for example, IOException OR FileNotFoundException.
• The "Diamond Operator" - This will make for easier to read code and a few less keystrokes. No need to explicitly tell the parameterized types on both side of an assignment.
• Try with resources - Tell try which resources need to be closed before you user them. Could be a timesaver and help save some coding mistakes, since you won't have to use a finally block to close things like DB connections.
• The NIO updates - I guess that is cool and eagerly awaited. I don't think it will drastically change my life for what I do on a daily basis though. The filesystem provider for ZIP and JAR has a lot of potential though.
• Security updates are always welcome. Not sure how far behind the curve they are - this is the sort of thing that should be updated more often than major Java releases, IMHO.

Misses

• "Cloud" - Everything today is about the "cloud". But what does that really mean? Nobody knows. It's still a "nebulous" (pun intended) set of ideas, ideals, and technologies. It means everything, it means nothing. But instead of leading the charge to define how Java is all about the cloud, Oracle takes a back seat and gets their butt handed to them by Google, VMWare, Red Hat, etc.
• Closures - It's on the bill, but not for Java 7, it's destined (as of now) for Java 8. Too little, too late. The developers who are loving to hate Java right now, in favor of the newer languages like Ruby, Scala, Groovy, etc., aren't going come flocking back in a few years just because Java finally has closures.
• Consurrency and Collections Updates - According to Oracle docs, it's a "good start". But it's a few years behind languages like Scala that make concurrency a central issue. 
• Modularization -  it's on the roadmap for the future. What about OSGi? Isn't that already here and fairly well accepted?

And Who Cares Anyways?

• Invoke Dynamic - From what I can tell, average Joe Java Dev gets nothing from this. It is for dynamic languages running on the JVM. But languages like Groovy, JRuby, Jython, etc. are already thriving on the JVM, so not sure what the point is.
• Strings in switch statements - who cares? I tend to not use switch statements often. One time I thought I wanted to use Strings in a switch, but enums were the better choice anyways. This one has potential to get abused and end up with very un-OO code.
• Underscores in literals - thanks, because I know I was really hoping for this. On wait, no I wasn't.
• Unicode 6, IETF BCP47 and UTR35 - yawn! But then again I'm a stupid American who only cares about English ;-)
• The Swing and graphics enhancements - Java is still used on desktops!? Thought everything was server-side nowadays?
  

Groovy's Built-in Mock and Stub Support

Just when I was ready to bite the bullet and learn a new mocking framework like EasyMock, I find out Groovy has built-in support for creating dynamic stubs and mocks.

After seeing an example on the web and perusing the Groovy API docs, I was up and running with my own sample test in about 30 minutes. Even though it is very similar to the example I found, I threw it up on Github anyways so I can find it later.

What's JUnit?

Did You Get the Email From the CI Server?

http://troll.me/category/the-most-interesting-man-in-the-world/

Just Showin' Off

There's really no point to this post other than to show off the one decent fish I've caught in the past few years. I don't catch many worthy of taking pictures, or many period, so I'm entitled.....

17-1/2" bass, Honeoye Lake, NY - April 2011

Caught on a silver, blue, and purple Rapala diver

Using Groovy and Easyb to Unit Test PL/SQL

I'm not sure if PL/SQL developers just haven't embraced automated unit testing, or if the frameworks out there just suck for some other reason (maybe because PL/SQL itself blows goat). What I found was either abandoned, had a lack of user base, and/or was overly complicated for what it needs to do. Some frameworks require a bunch of PL/SQL code to be loaded into the database to be tested, others only run from GUI's (so much for automation), and some - GASP! - you need to pay for!?

So how about good old JUnit? It would work, and work well, but with all the messy baggage that comes along with the JDBC API's. No on to my next step, use JUnit test cases written in Groovy instead of Java, to gain the groovy.sql.Sql convenience. Even farther in the evolution is use a behavior-driven approach using Easyb.

Below are sample tests for a simple PL/SQL procedure that writes messages to a log table. The first example is a JUnit test written in Groovy. The other is the same test using Easyb.

Other than a JDK, Groovy, Easyb, and your JDBC driver, this technique requires no additional libraries or frameworks. And it can be run in a CI environment like Hudson/Jenkins like any other JUnit tests (the Easyb tests can be run from a JUnit suite with a simple "bridge" class).

Unit Testing PL/SQL Using JUnit and Groovy

Using Groovy's Sql object makes it very convenient to test PL/SQL, because you get to avoid all the messy JDBC overhead.

package com.XXXXX.XXX.plsql

import static org.junit.Assert.*
import org.junit.After
import org.junit.Before
import org.junit.Test
import groovy.sql.Sql

class XXXWriteApplLogTest {

 Sql sql
 
 @Before
 public void setUp() throws Exception {
  def db = [url:'jdbc:oracle:thin:@XXXdev2.XXXXX.com:1521:XXXd10g', 
              user:'XXX', 
              password:'XXX', 
              driver:'oracle.jdbc.driver.OracleDriver']
  
  sql = Sql.newInstance(db.url, db.user, db.password, db.driver)
 }
 
 @After
 public void tearDown() throws Exception {
  sql.call "DELETE FROM XXX.APPL_LOG WHERE SOURCE = 'UT' and CORRELATION_ID = 'UT-101'"
 }
 
 @Test
 public void testWriteApplLog() {
  println "Calling procedure..."
  def plsqlCall = "{ call XXX.WRITE_APPL_LOG(?,?,?,?) }"
  def params = [ 'UT','INFO','Test message from automated test suite','UT-101' ]
  sql.call(plsqlCall, params)
  
  def verify = "SELECT * FROM XXX.APPL_LOG WHERE SOURCE = 'UT' and CORRELATION_ID = 'UT-101'"
  def results = sql.rows(verify)
  results.each { r -> println r }   
  
  assertEquals(results.size, 1)
 }
}

---

Unit Testing PL/SQL Using Easyb

For more information on Easyb take a look at the Easyb website (http://www.easyb.org/). You can be up and running with Easyb in minutes, which will make you feel really smart.

package com.XXXXX.XXX.plsql

import groovy.sql.Sql

description """
  Prototype of PL/SQL unit testing using Easyb.
  Have full access to the Groovy libraries so we can avoid the messy JDBC baggage.
"""

scenario "Writing log message to APPL_LOG table via XXX.WRITE_APPL_LOG procedure",{
    given "XXX.WRITE_APPL_LOG procedure written in PL/SQL", {
        println "Setting up database connection..."
        db = [url:'jdbc:oracle:thin:@XXXdev2.XXXXX.com:1521:XXXd10g', 
              user:'XXX', 
              password:'XXX', 
              driver:'oracle.jdbc.driver.OracleDriver']
        sql = Sql.newInstance(db.url, db.user, db.password, db.driver)
    }
    when "procedure is invoked", {
        println "Calling procedure..."
        plsqlCall = "{ call XXX.WRITE_APPL_LOG(?,?,?,?) }"
        params = [ 'UT','INFO','Test message from automated test suite','UT-101' ]
        sql.call(plsqlCall, params)
    }
    then "The log entry should be written to XXX.APPL_LOG table", {        
        verify = "SELECT * FROM XXX.APPL_LOG WHERE SOURCE = 'UT' and CORRELATION_ID = 'UT-101'"
            results = sql.rows(verify)
            results.each { r ->
                println r
            }   
        results.size.shouldBe(1)
    }
}

println "Clean up after test run - delete the record we added..."
sql.call "DELETE FROM XXX.APPL_LOG WHERE SOURCE = 'UT' and CORRELATION_ID = 'UT-101'"

---

And the bridge class

Drop this in with your other JUnit test classes so Easyb stories and specs can be run from JUnit. See the Easyb site for more information.

package com.XXXX.XXX;

import java.io.File;
import org.easyb.junit.EasybSuite;

/**
 * This class provides the "bridge" to allow easyb behaviors to be run from a
 * Junit test suite. Allows Junit reports to be generated for easyb stories.
 */
@VersionId("@(#) EasybTest.java [@@/main/cr0000000/1]>")
public class EasybTest extends EasybSuite {

    /**
     * tell easyb-junit where to find the easyb stories/sepcs
     */
    @Override
    protected File baseDir() {
        return new File("test/behaviors");
    }

    @Override
    protected String description() {
        return "Project behaviors (stories, specifications)";
    }

    /**
     * See http://code.google.com/p/easyb-junit/ for reasoning. This ensures
     * time will be tracked when run from Junit.
     * 
     * @see org.easyb.junit.EasybSuite#trackTime()
     */
    @Override
    protected boolean trackTime() {
        return true;
    }
}

Testing SyntaxHighlighter Script

Just testing the Syntax Highlighter script....

Please disregard. There's nothing to see here, move along....

Some links:

• http://alexgorbatchev.com/SyntaxHighlighter/
• http://www.cyberack.com/2007/07/adding-syntax-highlighter-to-blogger.html
• http://accessify.com/tools-and-wizards/developer-tools/quick-escape/

#!/usr/bin/env ruby

class SyntaxHighLighterTest

$max_column_chars = 4000

attr_accessor :numRecords

def initialize(numEach=1000)
 @numRecords = numEach
end

def do_nothing
 tstamp = Time.new
 puts "The time is now #{tstamp}"

 @numRecords.to_i.times do
  puts "going...."
 end

 puts "gone"
end
end

if __FILE__ == $0 
 numRecs = ARGV.first
 fn = SyntaxHighLighterTest.new numRecs
 fn.do_nothing
end

WebLogic Annotation For MDB WorkManager

If you are like me, you have been searching the web for 2 hours looking for a way to tie your WebLogic 10g message-driven bean to a WLS WorkManager using the nice EJB3 annotations. But since you aren't me, let me save you some time.

It ain't there. Not gonna do it. Not happening for you today, my friend.

You have to do a bastardized mutt application using a combo of annotations and XML deployment descriptors (remember those?).

Allow me to save you more time by showing a more concise example, so you don't have to take a time machine back to a time when EJB2.1 and XML roamed together in dinosaur-like bliss and figure out what the descriptor should look like.

Here's an example:

My MDB class signature looks something like this....

@MessageDriven(activationConfig = {
  @ActivationConfigProperty(
    propertyName = "destinationType",
    propertyValue = "javax.jms.Queue") },
  mappedName = "jms.ens.yes943processing.queue")
public class YearEndProcessingMdb implements MessageListener {
...

And so on, with your onMessage() and all the other crap you would put in an MDB.
Then my weblogic-ejb-jar.xml file looks a bit like this....

 <wls:weblogic-enterprise-bean>
      <wls:ejb-name>YearEndProcessingMdb</wls:ejb-name>
   <wls:dispatch-policy>Ens943WorkMgr</wls:dispatch-policy>
  </wls:weblogic-enterprise-bean>
    
  <wls:work-manager>
      <wls:name>Ens943WorkMgr</wls:name>
      <wls:max-threads-constraint>
          <wls:name>Ens943MaxThreadLimiter</wls:name>
          <wls:count>10</wls:count>
      </wls:max-threads-constraint>
      <wls:ignore-stuck-threads>true</wls:ignore-stuck-threads>
  </wls:work-manager>
</wls:weblogic-ejb-jar>

You can tell if the thread limiter is working by deploying, chucking a bunch of messages on thequeue, and checking the WLS console.

• Go to deployments
• Click to expand your EAR
• Click on the MDB name.
  
• Then go to the Monitoring tab.
  
• Under that click on the Workload tab.
  
• Here you should see your work manager and thread constraints with the number of messages they are processing.

JMS Queue Depth

You know it seems like a glaring omission (IMHO) for the JMS API to not have a standard method for getting queue depth. It seems like such an obvious thing to want, esp. for monitoring production systems. Maybe I was spoiled using Websphere MQ (a.k.a. MQ Series) all these years, but it is the first thing I think of when dealing with queues -- how many messages are on it? Is it getting backed up? Are messages actively getting pulled?

Sure there's a way to get queue depth, but it seems like such a hack to have to write code to do it -- create a QueueBrowser to iterate through the messages on the queue, counting them as you loop. Then of course the extra step would usually be to expose that "depth getter" code via JMX so you can monitor it.

Wouldn't it just be great to have a method on javax.jms.Queue class called "getDepth()"? C'MON!!!