Where’s the Flex Plug-in for Eclipse 3.5?

Eclipse + Flex = X

Over 7 months after Eclipse 3.5 (Galileo) was released, Adobe still has not released an update for its popular Flex Builder 3 plug-in that would make it compatible with the most recent version of Eclipse. Those of us who rely on the plug-in for Flex/Air development are still stuck using Eclipse 3.4 (Ganymede), or trying a number of manual install attempts, described here and here, neither of which worked for me. Ultimately, though, I’m not fond of hacky solutions for production-level products that I pay good money for.

Adobe has informally acknowledged the issue via its bug-tracking system, FB-21284 and FB-21025 (login required), although they have not publicly announced when a solution will be available. With the planned release of Eclipse 3.6 (Helios) now less than 5 months away, it makes you wonder when and even if the issue will be addressed. The Flex/Air projects have always been one of Adobe’s more grass-root movements, especially compared to its Creative and Web Suite products, and it’s a shame they have let the developers down. I call on everyone to contact Adobe with your concerns about Flex, with the hope they will address the issue if they understand how many developers this affects.

Updated (September 2010): Since releasing Flash Builder 4, Adobe has updated the Flex Eclipse plug-in to support Eclipse 3.5. Unfortunately, Eclipse 3.6 came out in June 2010 and is currently not supported, so Adobe is already another version behind. Also, I recommend developers stick with Flex 3 for now, as the new version is quite cumbersome to work with, meaning you’ll have to stay with Eclipse 3.4 for the time being to develop Flex applications.

The LED Revolution

Unless you’ve been living in a cave, you may have noticed that LED light sources are now appearing in a number of devices, from pocket flashlights to laptops to televisions, primarily because they are cheaper to produce and tend to use less energy in devices than their non-LED counter-parts. In this article, I examine 3 new LED replacement technologies and evaluate whether or not the technology is mature enough to start replacing your non-LED devices.

I. LED Printers

In the home printing market, first there were dot matrix printers, followed by inkjet and laser printers, and now color LED printers. LED Printers use an array of LEDs as opposed to a laser to produce images from toner. They have fewer moving parts than most laser printers, making them more reliable, cheaper to produce, and possibly faster than conventional laser printers. They are even deemed safer to use due to the potential health concerns of laser printers. The only problem is print quality, which is currently limited to 600 DPI, whereas most laser printers can print 1200 DPI. This means images produced with LED printers may not be as sharp or high quality as those produced with laser printers.

The verdict: Once LED printers close the DPI gap, they will be positioned to replace laser in both home and business environments. Costs are still high for LED printers, but that’s expected to fall over time.

II. LED Televisions

Most people aren’t aware that there are light bulbs of any kind inside LCD TVs, referred to as backlight devices, which allow TVs to be viewed in pitch black rooms. Therefore, many novice shoppers often confuse the technology, comparing LED versus LCD televisions, despite the fact that both are actually LCD devices. The difference, then, is that LED TVs are LCD devices with LED’s for the backlighting, whereas what is commonly referred to as an LCD television is the same device but with a fluorescent light bulb providing the backlighting. The most obvious advantage is the depth or thickness of the TV, which can go from 4-5 inches to a remarkably thin 1 inch since LED bulbs are significantly thinner than fluorescent bulbs. The cost should be cheaper, although LED televisions are so new that they are often priced higher than their LCD counter parts. Finally, the power consumption and overall lifespan of the TV are improved, in part because there’s no fluorescent bulb to change. I’ve read dozens of television reviews that claim LED televisions have superior picture quality due to the fact that they have more even lighting, but after viewing them in person, I find the picture quality improvements are vastly theoretical. The biggest disadvantage of LED picture quality is the reduced viewing angle. If you’re looking at the TV from any angle other than directly in front of it, such as from the side or slightly above/below, the picture becomes extremely dark.

The verdict: Due to the reduced picture quality and the fact that LED televisions currently cost more than LCD, now is not the time to switch to LED. The thickness of the TV provides a bit of bragging rights, I’ll admit, but for now I’ll stick with improved picture quality and lower cost.

III. LED Light Bulbs

The most common light bulb we have all seen is the incandescent light bulb, which are now being replaced with compact fluorescent lamps that use far less power. While these two types of light bulbs each have their advantages and disadvantages, I’m reluctant to call one better than the other. A third type entering the market is LED light bulbs, which uses a cluster of small LEDs inside a shell to simulate a standard light bulb. The biggest advantage of these bulbs is significantly less power usage; since they don’t generate much heat, even more energy than is saved than with CFLs. The biggest disadvantages are the cost per bulb and weak ambient quality. Because LEDs create directed light, such as in a flash light, they perform poorly when use as an ambient light source such as a lamp or overhead room light.

The verdict: There is still a long way to go on LED light bulbs, both in terms of quality and price, which is right now quite expensive per bulb. While we’re still a long way off from replacing all the lights in our house with LED bulbs, the potential cost saving is astronomical. Granted, there are some previously unknown side effects of replacing lights with LED, such as this Wisconsin town found out, causing increased costs for snow cleaning crews.


The advantages of LED devices are pretty consistent: they use less power, are cheaper to produce, and often allow for smaller, lighter, and more compact form factors. One disadvantage is also pretty consistent, though: they tend to sacrifice quality. I suggest holding off jumping on the LED band-wagon until the technology has matured. There’s no doubt the prices of these devices and quality will improve, as manufacturers see lower costs equaling greater profits, but the technology just isn’t there for widespread adaptation. If you value quality over energy savings, you would do well to wait for the technology to catch up.

javaranch forums go mobile

Want to know what went  on behind the scenes of JavaRanch’s mobile site creation?


  • January 2009 – We started talking about how poorly the site renders on a BlackBerry
  • July 2009 – I got a BlackBerry for work.  And ugh.  The forums do look horrible.
  • August 2009 – Tried out BlackBerry emulator and explored the minimalistic approach possible to creating a mobile version (see next section.)  That didn’t work and I wasn’t prepared to spend a lot of time on it in the summer.
  • mid November 2009 – Start discussing design/UI.  Noted it took 4 minutes to edit a post via BlackBerry.  Very excessive.
  • late November 2009 – Restart development using approach #2.
  • December 2009 – Weekly deployments to production using “secret URL that only the moderators know” for beta testing.
  • January 3, 2010 – Mobile URL announced to public and added to e-mail notifications

Approach #1 – Mobile CSS

My original theory was that the easiest thing to do would be to just add a mobile stylesheet that would hide some columns.  It wouldn’t shrink the pages of course.  But as a first step: slow and readable beats slow and un-readable.  I quickly ran into some problems:

  1. The BlackBerry doesn’t like mobile stylesheets.  Bushido covers the options in a lot of detail.  Search for “Alright, alright. Gimme the code already!” for the ugly CSS imports.  The real problem is that you don’t have a mobile stylesheet with this technique.  You have a stylesheet that everyone uses called mobile and the main stylesheet which cancels out the main one.  Developing for this is crazy as you are compromising what stylesheets appear to do.  And it will break when RIM finally gets their act together.
  2. JForum uses a largely table based layout.  This doesn’t go well with CSS for hiding things.
  3. The table layout made changing anything incrementally very difficult.

Approach #2 – An actual mobile site

This approach is definitely more mobile friendly as the pages are designed to be mobile sized.  They are also written from scratch and get to use <div>s.  Basically what I did was take the real page, pick the most important parts and create div layouts for them.  Once I had one done, the rest followed easily.  There are a few limitations documented in the JavaRanch announcement site.  But overall, I’m happy with it.  It is certainly way better than what we had before.  And we will continue to tweak it.


I tested locally using the BlackBerry simulator and later with the Droid emulator. I also tested using my real BlackBerry after deploying to the test server.  The aggravation of using a real mobile device isn’t captured on the emulators!  It is possible to use testiphone.com as an emulator.  It is not completely accurate though.  In particular, it didn’t show the viewport problem.

<meta name=”viewport” content=”width = 320″ />

We also tested on a variety of real devices.  Many moderators tested on their personal handhelds and we got a good variety that way.

I’d like to thank a few people in particular.  Thank you to everyone who let me test on their device, especially

  1. Gregg Bolinger – for instant feedback in testing the viewport fix at 11pm on both the iPhone and the Droid.  (And more testing than anyone else.)
  2. A few coworkers (at my real job) – for the wide variety of devices I got to put my hands on.  The simulators really aren’t the same.  Five minutes on the real handheld at lunch really helped.
  3. Chuck from the NYC Spin for offering his tiny touch screen device (the smallest I’ve tested on) without my even asking!


You know how sometimes marketing picks a ship date and it overrides “doneness” ?  Well, I really wanted to announce this on January 3rd – the one year anniversary of us being on Java based software.  There are some things that I wish were more resolved like why Google Mobilizer is injecting itself in links. Overall, I think it is in good shape and ready for people to try out though.

What do you think of the new site?  Share in the JavaRanch announcement thread or as a comment here!