I've censored the following, in protest of a bill that gives any corporation and the US government the power to censor the internet--a bill that could pass THIS WEEK. To see the uncensored text, and to stop internet censorship, visit: http://americancensorship.org/posts/33408/uncensor

Access the new Eclipse Community Forums from inside Eclipse itself

Thanks to Denis Roy, Eclipse now has a modern web user interface for its user/developer newsgroups. While I, personally, still prefer to use Thunderbird to access the newsgroups the "old fashioned" way, I'm sure many users will appreciate this big improvement over the old web interface.
The new forums site is still in a "beta" stage (please report any problems or suggestions to bug 284281), but I thought it would be nice to have easy access to it from right within Eclipse itself. So I've developed this little plug-in that adds an "Eclipse Community Forums" view to all perspectives. The View is basically an SWT Browser widget that is hard-coded to the forums site, along with some basic toolbar buttons for navigation.


A few notes on this "first draft" implementation:

• I've only tested it on OS X (Cocoa) so far; please let me know how (or if) it works on Windows XP, Vista, and Linux.
• The View is supposed to be automatically added as a Fast View to all perspectives (and it does correctly when I test it in a self-hosting environment), but when I installed it into an existing Eclipse instance I had to manually open the View via Window > Show View > Other...
  If anyone has some ideas why it isn't automatically added after installation, please let me know.
  
  
• The Login toolbar action currently only takes you to the Login page, but my plan is to have it (optionally) automatically submit your login credentials if you choose to store them. I need to get with Denis to help debug why my attempts at submitting a login via URL isn't working.
• The Shortcuts list is an extension point that any plug-in can contribute to. For now I've included just some of the more popular newsgroups forums; if I get this accepted as an official plug-in, the vision is that different Eclipse projects would contribute to the extension point to have their forum included.
• Notice the "Open in External Browser" button in the View toolbar (not the toolbar that is inside the view above the browser). I waffled back and forth on whether to put the Login and Shortcuts actions up there, too. If you have a UI design opinion about that, please let me know.
• My goal is to get feedback and improve this over the next week or two and eventually submit it for inclusion as a first-class citizen of the SDK and package builds. So please let me know what you think and help me make it better.

You can install the plug-in from this update site: http://www.rizzoweb.com/Eclipse/updatesite

Thoughts on Google's operating system announcement

The rumors have finally been confirmed, Google is working on an operating system.

My thoughts on this are simple and limited: I see a small niche market for such an OS, but I just don't see the majority of computer users willing to accept web-only applications across the board. Connectivity is just too inconsistent and unreliable at this point, and even trying to own "constant connectivity" access (3G-based mobile and/or wi-fi access point access) is still way too expensive. Do we really think the 3G carriers are going to spend billions to make 3G as reliable and fast as the broadband that we're all used to getting at home and work? I doubt it. Without that, the web-only user experience will suck, because it won't be consistent.
Not to mention that I, personally, consider most web-based apps that attempt to replace a desktop app to be inferior in key ways. There are exceptions, and things are improving, but not enough for me to see this being a broad appeal by next year.

Having said that, I'm not foolish enough to bet against Google, who have quite a track record of success when it comes to delivering on new ideas and technology.

Early Thoughts on Portals/Portlets

I am in the process of evaluating/learning portal and portlet technology for my company. We are a HUGE organization, so there have been several efforts of exploration in various groups within the company. In fact, the "official" company-wide web-app and services framework team has actually implemented portlet functionality into the proprietary framework. I don't like the level to which they have abstracted away everything, though, so I'm making it part of my effort to evaluate their implementation. We use WebSphere Portal Server (we are a huge IBM shop, so it was the only realistic choice).

Thus far, my impressions of Java portal/portlet technology is that it is over-hyped. How many applications really have Yahoo-like requirements? Also, the portlet spec is over 18 months old at this point, but there is no public information about any activity on it. IOW, it appears to be stalled at the 1.0 level, and that 1.0 spec is quite immature. There are several key ideas that the vendors have all solved in proprietary ways that need to be part of the standard API and spec. The authors of the spec are remarkably silent on the progress of a 1.1 or 2.0 version - my educated speculation is that there is little or no progress happening at all.

The user activity I keep seeing (a Yahoo Group, articles, blog entries, etc) seems to be inordinately focused in the offshore population. I wonder if the offshore/outsourcing companies are hearing the hype from management types and trying to find ways to inject portal/portlet into every project they contract now...

Performance also appears to be a major issue. The extra processing required for every single user request is multiple times that for servlet apps, and, especially within our company, that results in apps that can handle significantly fewer concurrent users per unit of hardware than equivalent servlet/JSP apps. IBM claims that latest versions of WPS are significantly better than previous versions, but also seems to acknowledge that it is not equivalent to plain-old servlets and may never be - the stated hardware requirements for running Portal Server are pretty high-end.

Something else: I haven't seen much talk about portal in terms of transactional applications. I can see that having a "main" app as a portlet surrounded by little helper stuff like calculators, mail checkers, stock quotes, etc. would be "nice to have" candy, I haven't seen any examples of highly transactional portlets all coexisting and sharing window space.
Another potential problem is that of screen real estate - you UI designers have a significantly harder job when you're dealing with multiple portlets on every page; it means none of the portlets have as much real estate to work with as they would if they were individual pages or traditional web apps.

I think the portal idea can be very useful for certain applications that have specific requirements about incorporating multiple data views onto one page. I just don't think many applications actually have such needs. When they do, implementing it in plain servlets and JSP can be done, but would require building something like the portlet API and container anyway. It's just that I prefer to build something like that as-needed and specific to what you really need, rather than relying on a huge, bloated, wants-to-do-everything implementation like is provided by IBM, BEA, etc.

As I said, I am still learning and evaluating and planning some PoC mini-projects to explore these topics. Thus, my opinions are young and likely to change at least a little over the next few months

Struts: At what point does it pay off?

The topic of Struts recently came up on the ST-Java mailing list and my thoughts about it got rather lengthy, so I thought they'd be better served here than just in a Yahoo message.
The following question was posed:

I admit I don't know much about Struts, but I am wondering whether it's a bit "heavy weight" (for lack of a better word) for a small system (i.e., in terms of how rapidly you can do development in it) and/or whether there's a big learning curve involved in coming up to speed with it. Got any thoughts or experience you can relate that might alleviate those concerns?

It's hard for me to be completely unbiased in answering that, because I am already intimate with Struts. But, I'll try...

There is definitely a "tipping point" below which you may not want to invest the time into Struts. Like so many other things in our chosen art, where exactly that point lies depends in large part on the person/people doing the work and the nature of the relationship you/they have with the Goal Donors and Gold Owners ^(tm).

I would say that the point where learning and using Struts becomes worth it is likely lower than some people think/say it is. It is not as heavy as I've seen/heard some people say. And for apps with simple needs, it is simpler to use than for apps that have complex needs. IOW, in some ways simpler apps don't need as much design, maintainability, cleanliness, etc (ie, the things Struts brings you to); however, in other ways simpler apps mean less need for the more advanced Struts stuff that makes learning/using it more burdensome. Does that make sense, because it's Friday and I've had one of those weeks...?

Bottom line, if you need a small app that is low-volume, only a few pages, and pretty much will never need sophisticated logic (besides, for example providing CRUD for a simple data model), well then Struts can be too much. But I see it like buying some big-ticket power tool for your garage or shed: yes it is difficult to justify the cost and storage required to get one just to cut a few 2x4s for that small project. But once you've made the investment to have one, you can use it again and again for both small projects and large ones that come up. And the small ones become trivial and the large ones become a lot easier.

When I said "I will never do a web app with plain old servlets+JSP," I should have made it clear where my "tipping point" is - perhaps 5 pages with simple DB calls and no "business logic." Because, yes, even I wouldn't use it to, for example, make a utility app that does soemthing small like store my contacts list in a DB and give web access to them. I least I don't think I would...you know, now that I think about it, I probably would, because with Struts and its rich set of taglibs I can crank out a couple of JSPs and Action classes that do that kind of thing just as easily as if I tried to use straight servlets and/or JSP and scriptlet - And since scriptlet makes me want to throw up, I'd choose the Struts/taglibs approach if for no other reason than to hold my lunch :-)

I recently introduced Struts to the team I work on for use on a new project (re-write of an existing atrocious web app). The 3-4 people I'm working with on the project, none of them had any experience at all with Struts, although they each had worked on J2EE-based web apps. With my past experience to guide us, we have been able to get up and running in a pretty good amount of time, and that includes adopting Tiles (which I had not used before) and the latest Struts version (1.2.x - I had only used 1.0 before). Everyone, including the page design/HTML "guy" were able to pick it up pretty readily, with me providing abbreviated insight that is proably more efficient than having to scour all the documentation and mailing lists. It has gone very well so far, and now we can cank out new functionality with realitve ease.
The moral of that story is that having someone along for the ride who has done Struts before is probably a big advantage. I am not claiming to be anything special as a mentor or guide or teacher - it's just that having past experience, on the team, close at hand, made a noticable difference. My teammates have said that repeatedly over the past 4-6 weeks.

Of course, I am a "framework" guy - I enjoy using well-desinged ones, I enjoy trying to extract them from my own work - so I'm probably naturally inclined towards things like Struts that are nicely abstract and pluggable. But I'll tell you, in the past year I've also had to work on a plain servlets+JSP (with lots of scriptlet - YUCK!) application, and I was neither as happy nor as productive as I am on this new one where Struts is the Path of the Beam.

Eric