Have you ever searched google for a way to replace a regular expression with another string in Java? I did with this search and found some interesting results (you will see how Kent fits in just bit so hang on).
The first hit (at least when I searched) takes you to the great site Java Almanac and a piece of code that seems to fit the bill.
static String replace(String str, String pattern, String replace) {
int s = 0;
int e = 0;
StringBuffer result = new StringBuffer();
while ((e = str.indexOf(pattern, s)) >= 0) {
result.append(str.substring(s, e));
result.append(replace);
s = e+pattern.length();
}
result.append(str.substring(s));
return result.toString();
}
Now comes the interesting part. This code has a serious bug in it and its not all together obvious when you first grab it. And besides its on the Java Almanac, it must have been tested a thousand time right!
To see the bug in action try this test
replace("Original String", "", "pattern");
Unlikely that you actually type code in like that but who knows what might happen when the parameters that are passed are values in your program. These could be parameters from a user that forgot to type in the pattern or some other such thing.
The really interesting thing is that the method never returns. This code will go into an infinite loop because the indexOf will always return zero for the empty string.
That is where Kent comes back into the picture. A few weeks back he was called in to assist some of their clients with some problems they were having with their applications. Kent went to help them apply the Agitator to their apps to see if they could nail down the bugs. Come to finde out of the four clients Kent visited everyone of them had coppied and pasted this very code into their applications. This infinite loop was at least part of the problem.
There are a couple of lessons to learn here. One you should always test the code you down load from the net. The people who post code are just that, people. They make mistakes and sometimes what they post is broken. The second thing is test what you think of and also what you don't think of. The bug in the string replace code is non-obvious and in most cases I doubt I would have recognized the bug right off hand if Kent had not pointed it out. If it had been me that copied this code I would have very likely tested for passing in null for the pattern and/or replace string but probably not for the empty string. That is where tools like Kent's Agitator come in very handy they help you to see the stuff you did not think of.
Happy Coding, and make sure to test everything!
BTW: I tried to send email to the Almanac but there was no contact info on the site that I could find. If you know how to contact them please post it in a comment!
]]>This years focus is on web services with Java. I highly suggest you submit a proposal and if you are not keen on public speaking then I suggest you sign up today to go. Its going to be a blast!
]]>
Consider the UIComponent.getAttributes() : Map method, which is new in the latest beta release. This method returns a map that gives you get and put access to the JavaBean attributes on your component (all those evil accesors:). This fascinates me and I think its a cool thing to do. Tools have a very simple (java.util.Map) API to use and we as programmers have the accessors for the stuff we need typed access to (its likely to be a little quicker too but probably not called often enough to matter much). So for example;
public class MyComponent extends UIComponentBase {
...
public static final String FOO = "foo";
private String foo;
public void setFoo(String foo) {
this.foo = foo;
}
public String getFoo() {
return foo;
}
...
}
public class MyRenderer extends Renderer {
public static final String BAR = "bar";
...
public void encodeBegin(FacesContext context, UIComponent component) {
// instead of casting component to MyComponent I can use the attributes
// map to get at 'foo' or I could cast and call getFoo() either way
// it works the same (the map is of course a bit slower)
...
String foo = (String)component.getAttributes().get(MyComponent.FOO);
...
// even more interesting I can get at the renderer specific
// values put into the component by the creator of the component
// (usually a JSP tag) with the same logic
// Typically I'd be setting the value of bar in a JSP tag
// also using the map interface like this
// component.getAttributes().put(MyRenderer.BAR, valueSpecifiedInJSP);
...
String foo = (String)component.getAttributes().get(MyRenderer.BAR);
...
}
}
The spec calls this 'attribute-property transparency'. I like this a lot better than the way that the API was laid out in the EA4 version of JSF. In that world you had to keep everything in a Map and if you wanted accessors they had to delegate to the Map. This is a lot cleaner in my opinion.
Another side effect is that you can just assume that put(Object, Object) will 'just work' and will call the underlying set method when it can and put the value into a map otherwise. Thus we will be able to iterate through properties in a very straightforward way. This comes in very handy in the way JSP custom actions (tags) are implemented. The first example in the spec in section 9.3 shows how this could/should work.
With this API components could conceivably be writen without any accessors and no fields. All the instance data would be stored in the map. I think there is a certian danger of abuse like this.
On the positive side tools can access the whole component without having to know anything about it. This is a key aspect of the tooling requirements behind JSF and was possible in EA4 but uglier.
I've seen this sort of thing done on a limited scale on other projects but I've never seen something like this in a project like JSF (that will be used by lots and lots of people). What are your thoughts on doing this? Will it scale up in terms of usability? Will it get abused so much that we will end up with lots of nasty code? What do you think?
]]>OK so enough fluff here is the stuff :-)
Monday:
Keynote - John Soyring
The basic point of John's talk was despite the outsourcing that is happening there are jobs for people that have deep technical skills. He laid out eight areas where he (as the leader of IBM's services org) sees significant demand.Another cool thing that he mentioned was the IBM Design Pattern Tool Kit. I have not had a chance to play around with it yet but is sounds really cool.
Monday Sessions:
First I went to one of the many web services talks. This one was given by Denise Hatzidakis and covered the myriad of standards that make up what we call 'web services'. I enjoyed the talk and learned that someone needs to consolidate the specs :-) The treatment of WS-I was good too, I got a good feel for whats in there and what the point of the spec was.
The next talk was about J2SE 1.5 by Mark Reinhold. Overall a good intro to the new stuff in 1.5. I had heard of everything that Mark went over but the meta-data (now annotations) info was really cool. I have been meaning to read up on that for a while but just have not had the time. His overview was quick but good. There is another talk specifically on the meta-data stuff that I'm hoping to get to by Simon Nash.
The evening ended with a Q&A session where I learned that I'm not the only geek teaching my 8 year old how to build robots with java and lego-mindstorms. :-)
Tuesday Sessions:
The first one was on XSLT 2.0 given by Bonnie Ricca. It was good. I was hoping for more info on the standardization of integration but that was not to be. What I did learn is that XSLT/XPath 2.0 is going to make our lives easier in many ways. One of my favorite things is that XSLT and XPath now use the schema data types. Just from a cognitive perspective it will make the lives of those doing XSLT much easier only having to learn one XML type system.
Next I went to the portlets talk by Dave Landers and learned a ton of useful info about Portlets. I am planning to do some heavy portlet work early next year so this was most useful. I learned that Portlets are basically a step back in terms of rendering (who wants to put HTML into their Java code anyway). So I'm anxious to dig into some implementation to try it out and see if I can make JSP's work better with portlets. I will also be putting some JSF UI's into some portlets, when I'm done I'll repost with the results.
Wednesday Sessions:The first was on JSF by Stephen Stelting. He did a great job of presenting the basics of JSF. I enjoyed his presentation. I especiallly liked that he demonstrated some typical error conditions that happen with new developers. He also did a long example that showed several aspects of the JSF framework. A good presentation.
The second presentation was on Grid computing given by Paul Giangarra. All I had done before this talk was watch IBM's commercials that hint at grid computing (computing becoming a utility). So watching Paul go into detail and demystify the concept was great. I am really excited about the promise of Grid computing, but we will have to wait and see if the promise becomes reality. If it does we will be able to do some really cool stuff in the future. Grid computing (or actually the way apps have to be written for the Grid) reminds me of the way math apps had to be written for the Cray. He mentioned Globus and that looks like a cool place to start playing around with the ideas. If only I could quit my day job and play with new stuff full time!
Thursday:
Keynote - Simon Phipps
Great talk, Simon's basic point was the Open Source is not about free as in money free, but free as in freedom. Open source is enabled by the massively connected nature of our world. As expected (being from Sun and all) he talked a lot about the network being the computer. It was not a sales pitch at all but very interesting. Simon made the point that if we really thought the network was the computer then applications would be licensed differently and would run differently (and Sun is making some strides in the right direction with the $50/employee licensing). Lots of other cool stuff. Very entertaining and interesting talk.Thursday Sessions:
First presentation was on Portals by Paul Giangarra. Cool presentation with only a little over lap on the Portlet presentation. I basically learned that the race is on to provide good Portal stuff (i.e. portlet containers) for the big vendors and that IBM's intranet has some really cool Portal stuff.
Finally made it to Simon Nash's talk on annotations (i.e. JSR 175). There is some really cool stuff that could be done with the implementation of this. I was kind of tweaked that there is no definition of how to process the annotations though. I love the fact that I can declaritively say that my class is a websource but I'm not at all jazzed that I have to cook up my own way of getting to the annotations (i.e. parse the source, the class file or use reflection at run time). The talk was great though. Simon was really cool and you could tell he loved this stuff.
Friday Sessions:
The last session of the conference (I had to speak in the morning) was on the Globus tool kit (the grid computing stuff referred to by Paul Giangarra). Very cool content and very cool stuff. The tool kit basically enables you to do grid computing according to the Open Grid Services Architecture (OGSA) standard. Mike Brown did a great job of showing some of the cooler stuff you could do with the tool kit. The demo he cooked up was really cool (even though it didn't work). Each of the willing participants downloaded Globus, installed it and copied a web service from Mike's machine. Then with a simple Swing GUI Mike started up an SVG renderer service on each machine and got the results back on his machine to display the final JPEG. There was some bug somewhere that made it not work on everyone elses machines so he ran a threaded version on his own machine. Anyway it was really cool and I learned that I if I ever get the chance to do some grid computing I'll jump on it.
One of the coolest things last week was that the list of stuff to read or research that has been piling up on my desk for the last few months is finally starting to go down. I have learned so much that some of the items will just be pushed off the stack until I need more detail. This was an absolutely great conference and I highly recommend you comming next year if you have any money in your budget for such things. It was fantastic!
]]>