Tuesday, October 25, 2005

"I still love Java after all these years"

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.



Be sure not to miss the latest Java Posse interview: #9 - Joshua Bloch. In case you don't know, he's behind java.math, the Java Collections framework, annotations, and my personal favorite book on programming: Effective Java.



In the interview you'll hear what he would like changed in the Java libraries, you'll hear about his plans for an update to the Effective Java book, his thoughts on Ruby and Python, and of course we cover his feelings about Java. The title of this blog entry is a direct quote.



I won't, and haven't, posted a note every time there is a new Java Posse episode. (There is a blog on the javaposse page you can subscribe to for that.) But I really didn't want you to miss this one!



One note on the audio quality. You may notice that the interview episodes have lower quality audio then our news programs. That's because when we interview people, we need to use either the phone, or some kind of voice over ip solution like Skype, which means we can't use the better quality (but harder to set up) rig we have for our own recording sessions. Bear with us. We're looking into better solutions for the future.



If anybody would like to create transcripts of some of the interviews (people have requested them) we don't have time to do that ourselves but would happily post contributed transcripts.









Wednesday, October 19, 2005

Security: Block worms from your abusing your web apps

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


I came across this fascinating piece about a worm that spread quickly through the MySpace web site.
What's remarkable is that the web site had pretty good security. The person who did it used some pretty clever techniques to make it work.
I highly recommend reading the write-up, and especially his detailed explanation for how he worked around each security measure.



Briefly, since the site lets you enter HTML in your profile, he wrote very clever HTML that would get executed in other people's browsers whenever they viewed his profile. The executed HTML would automatically do various background posts (using ajax techniques) to automatically execute a requests and confirmation responses on their behalf. It would have the author added as a "friend" to the account, and then it would add the same html code to the new user's profile such that anyone viewing this profile would become "infected" in the same way. The worm spread to a million users in a matter of hours!


Myspace already had various security measures in place, such as blocking out dangerous tags, and removing strings such as "javascript" and "onreadystate" completely. He got around that by taking advantage of browser bugs. For example, even though myspace removed references to javascript, it would not remove java\nscript, and it turns out IE will still recognize this as a javascript URL, even with embedded newlines in the name! As another example, even though onreadystate is blocked out, he could use his ability to execute JavaScript to reconstruct it with string concatenation:



eval('xmlhttp.onread' + 'ystatechange = callback');


Fascinating. This got me thinking. What if you wanted to have a Comments feature on your web app written with Creator.
You want to allow the user to enter some HTML, such that they can add emphasis, use paragraphs etc. But how do you prevent
HTML that compromises your web site?



It seems like a really safe way would be to prevent any HTML attributes from being entered! As long as you don't allow attributes, and you don't allow the style or script tags, you should be safe. This may be overly restrictive, especially for a site like MySpace which tries to let users customize their pages visually. But at least for a comments feature it should be viable.



I took a quick stab at this with Creator. What we'll do is this: Use a TextArea component for the comment. We'll add a Validation event on the text area, and the validation will check the string for suspicious text. If it sees a problem, it will raise a validation error, and the messsage will be displayed in the Message component associated with the text area. I drop the components, then right click on the
text area and choose Add Event Handler | validate, as shown below (click for full size):








Now we'll just need to write the code. Once you add the event handler, you're placed in the source editor and get to edit your code.
By default you get a simple comment telling you roughly how to write a validate event handler:


public void textField2_validate(FacesContext context, UIComponent component, Object value) {
// TODO: Check the value parameter here, and if not valid, do something like this:
// throw new ValidatorException(new FacesMessage("Not a valid value!"));

}



Here's a simple implementation - pretty naive. It doesn't try to properly parse the HTML,
it just looks for occurrences of <, and when found makes sure that it's properly matched
with nothing other than an approved tag and an optional / at the front or end.
Am I forgetting to handle some other tricks worm developers can take advantage of?



Here's
the event handler - shown as an image since many news readers completely butcher formatted
text in attempts to make blog entries comply to their site style; click link for text version.






Here's how this looks at runtime:






(No, the error text didn't magically move from the top of the text area to the bottom;
I moved it between taking the first screenshot and taking the deployment screenshot.)



P.S. Don't forget to hook up the Message component to the text area, such that it displays
errors raised in the text area's validator. Do that by dropping it, then follow the advise
listed in the default message area on screen text: Ctrl-Shift Drag from the message area
to the text area (or vice versa). If you use a Message Group component, you don't have
to "bind" it to any components; it will display error messages from any and all components
on the page. It's a good habit
to always have one during development.


Saturday, October 15, 2005

New Toys: Hot workstation and nice fonts!

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.





I've got a new toy: a brand new Sun Ultra 20 workstation. It's for home use. It's a great system, and very fast. I used one of these to do my coding challenge back in June. Now I've got my own!



(If you're looking for a new home computer, check these out. They're using AMD 64 bit Opteron processors - mine is 2.6 Ghz - so you can run many different operating systems on it. Here's a very enthusiastic review of it, and
here's another. I just wish
the fan could have been a little quieter.)



I decided to put Ubuntu linux on this one. It was straightforward. (I had first tried putting Fedora Core 4 on it, including the various java tools. But those systems do all kinds of weird things to support Java (some kind of GCJ variant plus various "smart" scripts which essentially prevented ant from running). For Ubuntu I didn't install any of the Java development tools, and instead downloaded them directly myself and put the latest Ant and Tiger on there.



I then decided I wanted smooth fonts; after looking at nicely rendered fonts on an Apple laptop it sure hurts the eyes to look at the default configuration of a Linux desktop! Luckily I could enable subpixel antialiasing in one of the configuration screens. Much better. But my IDE still didn't look good. That reminded me that Mustang, the next generation JDK, will support LCD subpixel rendering. So I downloaded Mustang, restarted NetBeans with it, and lo and behold - it works very nicely. The following screenshot shows the before & after effect but will only look right on LCDs:






Here's some more indepth analysis of the rendering changes.


Friday, October 14, 2005

AJAX+Java FAQ

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


Greg Murray has posted a comprehensive FAQ on AJAX as it relates to Java. If you want to dip your toes in Web 2.0,
this looks like a great resource and starting point.


Monday, October 10, 2005

Code Advice #6: Write debuggable code!

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


(See intro for a background and caveats on these coding advice blog entries.)



It's important to write readable code. But that's not the whole story. Your code should be easy to debug too. In this blog entry, I'm pointing to some Bad code patterns that makes your code hard to debug.



The first, and most evil practice is to write a conditional on the same line as the if:



if (foo) bar();


Yes, this already violates other rules of good coding style in that it's missing braces. But even the cleaned up version is no better in terms of debugging:



if (foo) { bar(); }


This is Bad for debugging because as you're stepping through code, the whole if block becomes a single step! While you're debugging, you typically want to know if the conditional branch was taken or not. With the "correct" three line version this is not a problem; you step once over the if, and you can then separately decide if you want to step into the conditional method call for example.



if (foo) {
bar();
}


You may not realize you're guilty of the above problem, but if you use the ternary operator, a?b:c, you might be. The ternary operator is really an if-then-else block in disguise. Don't write code like this:



x = foo ? bar() : baz();


for the same reason as above: this is now a single debug statement so it's hard to decide if you want to step into or not (if you for example are only interested in stepping into if the target is baz().)



This frequently comes up in conjunction with return statements. I've seen coding styles recommend you to use ternary operators instead of if blocks. This is where code simplicity (for those who feel that a terse ternary statement is more readable) goes squarely against debuggability. I recommend you stick with the if block. I feel if blocks are more readable too. The argument for collapsing statements is usually that it makes the code more dense, so you can "fit more on the screen", but the same argument could be used against whitespace between logical code blocks and methods etc., and I think we all agree that optimizing for code density is not optimizing for code readability.



Another bad code pattern for debuggability is



getFoo().getBar().getBaz().doit();


or even the slightly less evil, but still bad



getFoo().doit();


What's wrong with this? Convenient SteppabilityTM. In this pattern, all the method calls before the last one are simply getter calls. The doit() method is the interesting code we want to step into. However, since all the preceeding accessors are called in the same statement, we have to Step Into, then back out of, each method in the call chain up until we finally get to the interesting method!



Overshooting (the technique
of Stepping Over, then Undoing when you've gone too far
) doesn't work here.
There are some simple workarounds; for example, some debuggers let you put the caret on the last method, and then invoke a different stepping action to step into the desired method. But this is clearly inconvenient; you don't want to force users who are rapidly stepping with F7 and F8 to have to click to step into interesting code.



Thus, you should write the above code like this instead:


Foo foo = getFoo().getBar().getBaz();
foo.doit();


Obviously, if any of getFoo(), getBar() or getBaz() were interesting too, you could break
this up further, but the whole point here is that you typically don't want to step into accessors (which I'm assuming the above are) so get those into their own statement. Now you can step right over the first line and into the second.




Tools can help this situation. In Sun's C++ development environment, there is a fourth Stepping action: Run Into Last Statement Call. This stepping action "magically" achieves precisely what you want: It analyzes all the method calls in the current statement, and steps into the last such statement. The net result in that the code example above (before we broke it up) you could click on the Run Into Last Statement Call button, and it would step right into doit() ! I really really want that action in the NetBeans debugger. I guess it will require some fancy bytecode analysis. The screenshot on the right shows the Stepping action part of the menu in Sun Studio - the last action is the magical one...