I’ve just been digging through the J2SE 1.4 regex stuff, and every time I have to do regex work in Java I keep thinking how much easier it is in other languages. Specifically I’m talking about the clunkiness of the various regexen APIs in Java and the requirement to double-backslash regex operators. We need a better way. Ruby and Perl both have native regex support built in to the language, so the backslashes are just fine. Python, which doesn’t have native regex support (it’s in the library), does have “raw” string quoting, which allows you not to double-up the backslashes. So what I have to write like this in Java:

1  Pattern p =
2      Pattern.compile("(\(\d+\))?\s*(\d{3}\s*\-\s*(\d{3})");
3  Matcher m = p.matcher(my_string);
4  if (m.matches())
5  {
6      ...;
7  }

or

1  if (Pattern.matches("(\(\d+\))?\s*(\d{3}\s*\-\s*(\d{3})", my_string))
2  {
3      ...;
4  }

looks like this in Python:

1  if re.match("((d+))?s*(d{3}s*-s*(d{3})", my_string):
2      ...

and could be even more easily written in Ruby thus:

1  if my_string =~ /((d+))?s*(d{3}s*-s*(d{3})/
2      ...
3  end

See the difference? The built-in regex support is really nice and the ease of quoting is a beautiful thing. I doubt that we’ll ever see either of these in Java since they would certainly be considered non-trivial to add.

I discovered something interesting the other day at the office. We have a guy who has been unable to build a certain entire jar of entity beans ever since he started working there and I had only given it scant thought as to why. I knew that I had had no problems… So he came by my office on Wednesday and I said “OK. Let’s figure this out.” I ran our Ant build file that is specifically used for building this particular jar full of entity beans and got the same errors he was reporting. Odd, thought I. The errors being reported by ejbc were that the compiler couldn’t resolve symbols with names like Foo$ValueObject. That was odd since that looked like the inner classes defined in each of the entity beans were not there. But looking at the classes directory, those classes were definitely there. What was really odd was that simply dropping back to J2SE 1.3.1, or even 1.4.1 worked.

For reference, we have a group of entity beans that each have a nested class called ValueObject. (I don’t particularly like that, but they’re there nonetheless.) Essentially we have 80 entity interfaces that follow this basic pattern:

public interface Foo extends EJBLocalObject
{
   ...

   public ValueObject getValueObject()

   public static class ValueObject
   {
       ...
   }
}

and then 80 entity bean classes that actually implement the getValueObject method.

It was at this point that I started looking at that “$” in the class name. It then hit me that the code should be using a “.” between the outer and inner class names, not a “$”. But the code where the error was occurring was generated by ejbc. I’ve tried this now with WLS 7.0 sp2 and sp3 and the results are identical.

Even though I’ve not been able to find this documented in the release notes of J2SE, it would appear that versions prior to 1.4.2 allowed code to specify an inner class using a dollar sign, even though it was not technically correct, and that 1.4.2 has stopped being lenient in this regard. Yes, I know that WLS 7 is not officially supported with 1.4.2… I haven’t tried with WLS 8 yet; I would assume that since it is supported with 1.4.2 they’ve changed the code generation routines inside ejbc.

So the moral of the story is that if you find yourself needing to run WLS 7 with J2SE 1.4.2, and you happen to have entity beans that you need to run through ejbc, first run your build file for those entities using J2SE <= 1.4.1, and run everything else under 1.4.2.