News

The Closures Controversy in Java

Tagged:  

I just finished viewing Joshua Bloch's talk at JavaPolis 2007 entitled "The Closures Controversy", where he critiques one of the leading proposals for adding closures to the Java language (BGGA, named as an acronym after its authors). The presentation is eye-opening, and it is thought-provoking to see two of Java's biggest lumunaries on opposite sides of the debate. Of course, Bloch himself is one of the authors of an alternative proposal for adding closures, CICE (Concise Instance Creation Expressions).

It's not Clarence Darrow in the "Scopes Monkey Trial", but it's the closest we programmers can get. I won't go into huge detail about the two proposals except to say that BGGA adds full support for functional types whereas CICE is a more concise way of expressing anonymous inner classes in Java (there are many places on the web to go into the details). The heart of the debate really boils down to Defensive Programming VS. (for lack of a better term) "Let the programmer do whatever he/she wants (and let the language support it)". The former position being more conservative and more pragmatic, the later a more libertarian view that experts (programmers) are smart and should be allowed to do whatever they want. Ironically, these two opposites are also embodied in many ways in differing philosophies in design between Java and its antecedent language, C++. Java was, after all, "C++ --", the language that made smart decisions to remove features from C++ that were considered dangerously error-prone: pointers, explicit memory deallocation, etc.

So clearly Bloch is in the defensive programming camp whereas Neal Gafter, the main proponent of BGGA, is on the other side. And, I have to admit, I am on Bloch's side as well, for many reasons.

  • BGGA is complex. Non-local returns, continues, and breaks have a great potential to confuse the average programmer. The syntax, when viewed in even moderately complex code, looks cryptic. Even if you get past the syntax and non-local oddities you have to acknowledge, as Bloch so eloquently pointed out, that new features tend to add somewhere between quadratic and exponential complexity to a language because of their interaction with existing features. This was the *gotcha* with generics, and I have no desire to see that repeated with closures.
  • Defensive programming is at the very heart of what Java is as a language. And, by and large, it is this philosophy which has made it so successful. Trying to make it into an "experts language", as C++ is, cuts against the grain of the spirit of the language. (As an aside, it is telling to note that Gafter himself was a member of the C++ Standards Committee.)
  • The Java camp is already losing programmers to newer languages like Ruby because it is "too complex". Do we really want to add more complexity to drive away more programmers from the language? Simplicity is beauty, and (as someone once said) the most important decisions in a language have to do with what features you should leave out.
  • There are already other languages that target the JVM (and hence at least theoretically can interact with existing Java code) which handle closures in a much more natural way: JRuby, Groovy, Scala. Static typing without type inference tends to make control structures like closures much more challenging, if not downright awkward. Both Ruby and Groovy are dynamically typed and Scala uses static type inference. Perhaps one of these languages is a more suitable vehicle for those who feel they really need closures.

Whatever the result of the debate, it is likely that closures in some form will land in the Java language in the not-too-distant future. Right now, BGGA seems to have the momentum, which is unfortunate. Neal Gafter may, in a very well-intentioned way, be leading Java down a path of bloated complexity from which it will never recover; and which will ultimately result in Java yielding its leading position to a new language that is far more agile.

John Resig Announces Plans for Second JavaScript Book

Tagged:  

On his blog yesterday, John Resig - creator of jQuery - announced plans to begin work on a new JavaScript book. His last book, titled Pro JavaScript Techniques, was a success and is available online at Amazon.

The content of the book has not yet been solidified, but John has posted a question to the readers of his blog requesting some assistance. He's asking: "What are the greatest untold secrets of JavaScript programming that you wish were thoroughly debunked and explained?"

John already has some of his own answers to this question, and they are:

  • What is (function(){ })() and why is it so fundamentally important to modern JavaScript development?
  • What does with(){...} do and why is it so useful?
  • How can arguments.callee change how I work with JavaScript code?
  • How exactly do timers work and how can I best use them?
  • How do I identify and tackle memory leaks in web applications?
  • How do I write a cross browser way of...
    • Getting/setting attributes.
    • Injecting HTML strings.
    • Getting/setting computed css values.
    • Managing DOM events.
    • Writing a CSS selector engine.
    • Doing smooth animations.
  • How can I use verification tools (like JSLint) to my advantage - and write my own?
  • What's the best way to transmit JavaScript files?
  • How do I write my own JavaScript compressor (like Packer)?

If you have any suggestions for questions to be answered in John's new book or would like to give him a word of encouragement, you can leave him some feedback on his related blog post.

Get Insight into Digg's Bury System with Ajaxonomy's Bury Recorder

Tagged:  

If you have been using the popular service Digg you know that it is very easy to submit a story and to see it start to gain traction just to be buried into the dark abyss. What I find particularly frustrating is that you don't know how many people buried the story and the reason for the bury. If you have seen Digg Spy you have noticed that the application does show buries, but you can't just track data for a particular story.

After much frustration Ajaxonomy is now releasing a Bury Recorder application. How the application works is you take the story's URL (This is the URL of the page that the "more" link on the Digg upcoming/popular pages takes you or the page that clicking on the story title takes from your profile i.e. http://digg.com/[story]) and put it into the application and once you click "Watch for Buries" the application will start recording any buries that the story receives. This will allow you to see if your story had 100 diggs and 5 buries before it was permanently buried, or if it was more like 100 diggs and 300 buries. The idea is that you would submit a story and then have the recorder capture any buries from the time that you start the application watching for buries. You'll want to note that in this Beta 1.0 release, so currently you have to leave your machine on and the application open in order to make sure that it continues to capture buries.

Before I go a bit into the design and more information on using the application I wanted to say that the application is open source and can be changed and put on your server. If you do change it and/or put it on a different server then we just ask for a link back to us and credit us for the initial creation of the application. Also, if you do decide to put it on a server, let us know and we might link to your server as another option to elevate traffic concerns on our server.

So, now that I have you are excited you will want the link to the application. Click here to be taken to Bury Counter Application.

The following is a quick overview on how to use the application so that it will make it a bit less confusing to use (more than likely most people could figure it out, but this way if it looks like it isn't working you have somewhere to look).

Using the application is as easy as one two three, however there are two ways to use the application below is the first way of using the application.

  1. Open the application (once again the link to the application is here)
  2. Copy and paste the URL of the story into the text box (i.e. http://digg.com/[story])
  3. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

The other way to use the application is as easy as one two (yep, there is no three using this method). Before using the below steps you will need to create a bookmarklet which can be done by following the directions at the bottom of the application.

  1. Click on the bookmarklet from the story page on Digg (this has to be the page that you get when you click on the "more" link in Digg [or from your profile page it would be the page that clicking on the title of the story takes you] which is the page that you would use to get the URL for the first method)
  2. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

Now that you know how to use the application I will go a bit into how the application was created. This application gets the JSON Feed used by Digg Spy. It does this using Ajax (i.e. the XMLHTTPRequest object) which requires a server side proxy due to domain security restrictions. Due to the way that the JSON is returned from Digg Spy, it doesn't set a variable equal to the returned object, which force us to use the before mentioned server side proxy and an eval statement instead of using DOM manipulation. The application simply polls for updated data every 20 seconds which makes sure we don't miss any data and that it doesn't put too much strain on the server.

You can download the full source code for this Beta 1.0 release here.

This release has been tested in Firefox 2.0.0.11 and Internet Explorer 7. It should work in many more browsers, but has not yet been tested. If you try it in a different browser and either find bugs or the application works perfectly then we would appreciate if you contact us regarding your testing results.

Also, if you do any cool things with the application or if you have any cool ideas then feel free to blog about it on this blog. Just sign up for a free account and once you login click on "Create Content" => "Blog Entry" and then write your post. If the admins of this site feel that your post is an interesting one they will move it to the home page.

I hope that you find this application useful and that you keep checking for new version and improvements.

If You Bury a Digg Story at Least Comment

Tagged:  

I have been posting to Digg for a while now, however recently my Diggs seem to continually be buried. Is this the rumored Bury Brigade? I don't have any way of knowing why these stories have been buried, they are not spam posts and are interesting original content. It seems like whenever I post a story and it gets in the "Hot" section that it gets buried soon after it starts to raise.

Since Digg gives me no way of knowing who or why my stories are being buried they give me no chance of knowing what I should do differently or a way to appeal that it was buried. All I want from people that bury my stories is the courtesy of leaving a comment that lets me know why they are burying the story. Kevin Rose some visibility would be very helpful.

So please if you bury my stories just leave a comment, so I know what you think I did wrong.

Videobox 1.1

Tagged:  

If you are familiar with lightbox you know how useful a tool it is. While with lightbox you you can easily display images, with Videobox you can do the same thing only with videos.

Videobox was written using mootools and uses the swfobject to embed flash videos. Videobox works great for videos from YouTube, but also works with other services.

Click here to go to the official page on SourceForge. The page includes code directions and demos of the library.

Check out Videobox and let us know about any cool sites or applications that you build with Videobox.

Create Your Own Blog @ Ajaxonomy

Tagged:  

That's right, members of Ajaxonomy.com can create their own personal blog! Registration is free - just sign up over on the right side of page (or log in with your OpenID). As a registered user you will be able to write and edit posts and have your own RSS feed. If that wasn't enough, your posts even have an opportunity to be promoted to the homepage and main rss feed of the site.

So, sign up today and get posting!

Yahoo! Maps gives Flash the Boot!

Tagged:  

Straight from the Yahoo Developer Network, Jason Levitt informs us that Yahoo Maps is now using pure JavaScript instead of a hybrid of Flash and JavaScript. If that wasn't enough, he also informs us that a new version of the Maps AJAX API will be available next year! Read the full post below:

You'd hardly know it by going to maps.yahoo.com, but Yahoo! Maps are now pure JavaScript instead of a hybrid of Flash and JavaScript. Lead Maps Developer Mirek Grymuza and the Maps team have done an amazing job of seamlessly moving the Maps client over resulting in at least double the performance of the previous Flash-based version.

The good news for developers is that the new Yahoo! Maps client uses an enhanced version of our Maps AJAX API which will be available to developers in 2008. This substantial upgrade of the Maps API will provide access to all the overlay components available in the consumer client and will give developers significant overlay flexibility. It's going to be a great new year for Yahoo! Maps users and developers.

Read the original post at the Yahoo Developer Network here.

ajax im 3.2 released

Tagged:  

Last month we had a post on the ajax chat and instant messaging clients created by unwieldly studios.

ajax im logo

I've just been notified that a new version their instant messenger ajax im 3.2 has been released, and there are many changes including:

  • a major overhaul of the code: everything (PHP and JS) is now
    object-oriented instead of procedural
  • multiple language support
  • admin panel added, supports searching for users, banning, kicking,
    and making/removing admin
  • PHP-based sessions implemented, so the username and password isn't
    sent on every message request
  • and many others.

ajax im buddy list

You can read more about ajax im at ajaxim.com and you can view a demo at ajaxim.net

Demo accounts are usernames "test", and "test[1 to 4]". Password is "test".

Making Prototype Smaller

Tagged:  

Prototype is one of the most used JavaScript libraries and is used for many other libraries. The problem with Prototype is that it is a rather large library. This has forced many people to either shy away from the library or to try and modify it. I say that just for the $ (for those of you who haven't use prototype the $ is used like document.getElementById) functionality the library is worth using.

I ran Prototype through ShrinkSafe and was able to get the code quite a bit smaller. The Prototype.js (I'm using version 1.6) file went from 122K down to 82K. That is an amazing 40K less which helps in using the library.

Below is a demo using the compressed and uncompressed versions of Prototype (the demo uses Script.aculo.us 1.8 and is taken from the demos that come with that library)
Click here to see the uncompressed version
Click here to see the compressed version

You can download the compressed version of Prototype here.

Now that you have a smaller version of Prototype use it to improve the load time of your application.

prototype.png

DWR 3.0 vision

DWR 3.0 is going to be released soon. Following are vision from Joe, Founder of DWR

DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release - I think we’re going to have to call it 3.0.

Since 2.0, we've been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.

There are also a whole set of non-functional things to consider:
* Moving the website to directwebremoting.org
* Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
* Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
* Get someone to pony up and let us move to SVN
* Unit tests

JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName?param1=fred;param2=jim and DWR will reply with a JSON structure containing the result of calling className.methodName("fred", "jim"); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I’m less convinced about this because it quickly gets DWR specific, and then what’s the point of a standard. Status - DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I’ve done most of the work so that DWR can use the JSON subset, but not created the ‘handler’ to interface between the web and a JSON data structure.

Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.

File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I’ve had some bug reports that it doesn’t work with some browsers, also we need to find a way to report progress to a web page simply.

DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part. Much of this work has not hit CVS yet, but will do soon.

Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs.

DOM Manipulation Library: Currently this is limited to window.alert, mostly because I’m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.

Gears Integration: I’ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.

Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don’t want to lose Google juice by doing it badly.
The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.

Source Repo: We are currently using CVS hosted by java.net (which is a collab.net instance - yuck). They support SVN, but want to charge me a few hundred dollars to upgrade. Maybe the Foundation can either ridicule them into submission or pay the few hundred dollars for the meta-data so we can host the repo. ourselves. The latter option is probably better.

Unit Tests: I've been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn't look like the project is going anywhere particularly quickly, so I'm back trying to get Selenium to act in a sane way.

Syndicate content