Sunday, August 07, 2005

Heads up: Eclipse 3.2 Draft Plan

There's a new revision to the Eclipse Platform Project Draft 3.1 Plan. This last one was published August 5th (Friday). It's a good idea to pay attention to these when they come out, especially with regards to the plugin APIs. The first milestone (M1) should hit the streets on or about August 12th. According to the draft plan, version 3.2 won't be finally released until sometime in 2Q2006. Since they only have four milestone releases listed so far, and the fourth is targeted for mid-December, I have to wonder what is going to happen in the next 3-6 months after the December milestone release. I hope it comes out a lot sooner.

Here are some of the proposed items for 3.2 that I'm most interested in.

Support logical model integration. The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on. [Platform Core, UI, Team] (37723) [Theme: Design for Extensibility]

Provide more flexible workspaces. Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files. [Platform Resources, Text] (106176) [Theme: Design for Extensibility, Enterprise Ready]

Update Enhancements. As the number and range of Eclipse plug-ins continues to grow, it becomes increasingly important to have a powerful update/install story. For instance, if more information about an Eclipse install was available earlier, it would be possible to pre-validate that it would be a compatible location to install particular new features and plug-ins. This information could also be used to deal with conflicting contributions. Update should also be improved to reduce the volume of data that is transferred for a given update, and PDE should provide better tools for creating and deploying updates. [Update, Platform Runtime, PDE] (106185) [Theme: Enterprise Ready]

I'm going to pay close attention to update enhancements. Keeping track of plugins and being able to manage them effectively is going to be crucial for Eclipse and NetBeans if they are to continue to evolve and grow.

Provide more support for large scale workspaces. In some situations, users have workspaces containing hundreds of projects and hundreds of thousands of files. Scoped builds and working sets have become important tools for these users, and the performance optimizations done in Eclipse 3.1 have proven helpful. Eclipse should have even more support for dealing with very large workspaces, including improved searching, filtering, working sets, and bookmarks. This goes hand-in-hand with ongoing work to discover and address performance issues. [Platform UI, Resources] (106192) [Theme: Scaling Up, Enterprise Ready]

Enhance the text editor. The Eclipse Text component provides a powerful editing framework that is useful in many contexts, but some of its capabilities are currently only available in the Java editor. The Java editor should be opened up to allow more general access to the reconciling, code assist, and template proposal mechanisms. Other enhancements to the look and feel of the editor should also be considered in areas such as the Find/Replace dialog, showing change history and comments in the editor, and annotation roll-overs. [Platform Text] (106194) [Theme: Design for Extensibility]

Improve UI Forms. UI Forms are increasingly being used in the Eclipse user interface. The UI Form support should be improved to allow for more pervasive use in 3.2. Critical widget functionality should be moved to SWT to ensure quality and native look and feel. The remaining UI Forms code (minus FormEditor) should be pushed down into JFace so that it is available in the Eclipse workbench. [SWT, UI, Help] (106203) [Theme: Simple to Use, Design for Extensibility]

Add support for Java SE 6 features. Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags (like @category), classfile specification updates, pluggable annotation processing APIs, and new compiler APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text, JDT Debug] (106206) [Theme: Appealing to the Broader Community]

Improve refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. Furthermore, existing refactorings will be improved to preserve API compatibility where possible (for example when renaming a method, a deprecated stub with the old signature will be generated that forwards to the new method). [JDT Core/UI] (106207) [Theme: Scaling Up].

API-aware tools. Given the importance that the Eclipse community places on stable, robust APIs, having good support for their implementation is critical. The support within Eclipse for describing APIs should be improved, along with better tools from assisting developers to stick to APIs provided by other plug-ins. [PDE, JDT] (106213) [Theme: Enterprise Ready]

Improve PDE build. PDE Build is fundamental to how the Eclipse Platform releases are produced. It is also increasingly being used by other Eclipse projects and in the wider community. Potential improvements to PDE build include parallel cross-building, incremental building of plug-ins, increased integration with the workspace model, and support for additional repository providers. [PDE] (106214) 106214[Theme: Enterprise Ready]

There's a log more to read, and there is the link on the page to API change tracking. If they deliver most or all of what is targeted (and not just my interest list), then Eclipse 3.2 is going to be a powerful challenger. It will be interesting to see how NetBeans responds.

Saturday, August 06, 2005

A Car Wreck with Boobs

So writes Paul Clinton for CNN. And that's actually one of his kinder remarks. I knew this was going to be a stinker of a movie for the following reasons:
  1. The original was a stinker.
  2. Jessica Simpson.
  3. The trailers.
  4. Jessica Simpson (I may be well beyond the 18-34 age demographic for T&A, but I ain't dead).
Since I refuse to spend $8 to see this cinematic roadkill, I'll let the poor sods who have seen it speak to its quality.
The film's only redeeming feature is the end credits, which show extremely funny outtakes from the movie. Unfortunately, they come about 103 minutes into the 106-minute film.
Paul Clinton, CNN Online
The Puke of Hazzard
But the "meanness" of the movie is what truly ruins it... When will the movie industry come out of their bubble and realize that Americans aren't the bad-to-the-bone, morally corrupt characters that they portray every time a movie tries to "keep it real"...
Yahoo User Review
Looks like we got another Gigli.
I understand the formula Hollywood uses for making movies, I just don't understand why they use it. Take one hot chick that can't act, add a bunch of male leads that also can't act, throw in some actors that actually have talent for seasoning, stir and poor into the mouths of idiots dumb enough to lop it up.
Yahoo User Review
Got In For Free...And Paid Too Much!!
And Jessica - well, she's crossed the "Britney Line" now, and is a bona-fide slut. Pity. I'm even having issues with my boyhood idol, Willie Nelson, for being in this horrible movie. All I can say is, I hope he was stoned for the whole shoot...because I wish I would have been to sit through this piece of garbage.
Yahoo User Review
It's every bit as bad as you thought it'd be. Only worse...
None of this is fun. Not even the lowest-common-denominator kind of fun that explains high Nielsen ratings and huge opening weekends. Director Jay Chandrasekhar has added some third-rate raunchiness — smoking dope with college coeds for a T&A and drug-joke double whammy — that might be funny to a seventh grader. And the stunts are so-so — nothing we haven't already seen in "Herbie: Fully Loaded" or 28 years ago in "Smokey and the Bandit," the movie that invented the car-chase leap of faith.
Eleanor Ringel Gillespie, The Atlanta Journal-Constitution
All hail 'The Dukes of Hazzard,' the absolute monarchs of horrid
"The Dukes of Hazzard" is hardly some routine bad movie. Rather, it's one of the elite, right up there with "I Am Curious ... Yellow" (1967) and Bo Derek's "Ghosts Can't Do It" (1990), in stiff competition for the lamest thing ever put on celluloid. Of course, that makes it, by default, the worst film so far of the 21st century, but to say that does little to acknowledge the ambition behind this project. Make no mistake, director Jay Chandrasekhar was swinging for the fences with this one. He was shooting for the millennium.
Mick LaSalle, Chronicle Movie Critic
And I think that just about does it.

Friday, August 05, 2005

Blogspot messing with me again

I like to use images with my posts, especially my technical posts. And the images I like to use are PNG. Most of my images are screen captures that I edit and save with The Gimp on Windows XP. Unfortunately, when I upload the images using "Add Image" feature that was just added to blogspot, blogspot converts my PNGs to lossy jpegs. Very lossy jpegs. For some images this isn't a problem. For technical images where I'm trying to show some specific detail, it's a disaster. I just realized this was happening from an email comment. I'm now looking to host my images on some other service, such as Flickr, and then link back to them. I know that blogspot is free and that the conversion of PNG to jpeg is to save server space, so I shouldn't gripe, I guess. But I am working to fix all the jpeg corruptions, and I hope to have it in place by the weekend.


Well I just tried out Flickr, and it's worse than blogspot. Not only are they converted to jpeg but they're cut down in size as well. Suggestions as to what to do now are welcome.

Thursday, August 04, 2005

Running the Amazon Web Services Sample Application In Eclipse

The NetBeans site has published an article on running the Amazon Web Services Sample with NetBeans 4.1. I thought I'd pull the sample down and run it in Eclipse, just to see what would happen. Turns out that Eclipse runs it just as well if not better. Of course, Your Mileage May Vary, but at least it was fun running it under Eclipse.


The Amazon Web Services Sample requires that you register as an Amazon Web Services Developer before you can download and use it. Registration is free. Once installed and built the sample application will make web service requests to Amazon. Each Amazon web services request requires a subscription ID parameter, which you'll receive via your email address after registering.

If you don't have Java installed, pick it up from your favorite Java download site. Make sure you at least have Java 1.4.2 installed. The Amazon sample application runs against 1.4.2_08. I had 1.5.0_04 installed on my notebook, so I had to download and install 1.4.2 side-by-side with Java 5. If you don't have Eclipse then download Eclipse 3.1 from the projects download page and install it.

If you're installing Java 1.4 onto a pre-existing Eclipse setup with another JVM other than 1.4.2, you need to tell Eclipse about the new JVM. Go to Preferences (Window | Preferences) and hit the Add button if the 1.4 JRE is not already known by Eclipse.

As you can see I've already added the JREs for Java 1.4 and Java 6, while Java 5 is my default JRE.

With that out of the way, we'll now start the Amazon Sample step by step like NetBeans.

Create the Eclipse Project
  1. Start your Eclipse.
  2. Right-mouse-click New | Project... in the Package Explorer.
  3. Select Java Project then Next.
  4. Type in 'AmazonProject' for the project name and click Next.
  5. On the Libraries tab, make sure you're using JRE 1.4. If you're not, select the JRE system library line and click Edit. In the JRE System Library dialog, click the Alternate JRE radio button. This will enable the alternate JRE dropdown. Select the 1.4.2 JRE and click Finish. If you don't see the JRE, you can add it by clicking the Installed JREs button and adding it as outlined at the start of this post. When you've selected JRE 1.4.2 click Finish.
  6. Import the sources. Right mouse click AmazonSample on the Package Explorer and select Import.
  7. On the Import dialog select File system. Click Next.
  8. Browse for the location where you unzipped the Amazon sample files. In my case it was under C:\downloads\java\AWS4Sample_JavaTool.
  9. Select the top level directory (AWS4Sample_javaTool), then on the right unselect the items you don't want imported into the source area. I unselected the jar files that are in the root distribution. Click Finish.

  10. Expand the AmazonSample project in the Package Explorer. Right mouse click on the AmazonSample root folder and open the Properties dialog.
  11. Select the Java Build Path entry. Click on Add External Jars. Navigate to the AWS4Sample_JavaTool folder and pick up axis.jar, commons-discovery.jar, commons-logging.jar, jaxrpc.jar, and saaj.jar. Click open. You can select all of the jar files in one operation simply by using [Ctrl] left mouse button click to select just the files you need. Then click OK on the Properties dialog.

  12. You're now ready to build and run the project.
Build and Run the Project
  1. There are a number of ways to build the project under Eclipse. For now select Project | Build Automatically on the main menu.
  2. After Eclipse is finished you should check the Problems pane. The Problems pane is usually at the bottom of the IDE, beneath the editor panes. Because of how my configuration is set up, the Amazon sources generated a large number of warnings. You can finely tune the generation of warnings from the Properties | Java Compiler dialog section. Some warnings I consider annoying, such as the ones about not declaring a static final serialVersionUID field. Others I pay attention to, such as the use of 'enum' as an identifier. Enum is a keyword in Java 5, and I use those warnings to clean up code destined for movement from prior versions of Java 5 to Java 5 and beyond. It's your call at this point, and I leave it as an exercise to the reader to explore this portion of the IDE. But the warnings will not stop the application from running. At this point, the application is ready to run.

  3. From the main menu select Run | Run. This will pull up the Run dialog that allows you to create, manage, and run configurations. At the top of the dialog box type in 'AmazonSample' for Name.
  4. You need to tell Eclipse where main() is. On the Run dialog click the Search button in the Main class sub-panel to select your main class, or simply type in 'Main' (without the quotes) in the text field. Click the Run button at the bottom.
  5. The application will start and a Console pane will appear in the same area as the Problems pane, overlaying the problems pane. It should have just one line in it: "Starting Application..."

Test the Application

The Amazon web services include a Help operation, which returns information on how to execute the other operations. We're going to follow the instructions exactly as posted on the Netbeans site.
  1. Select the SOAP tab on the application.
  2. Select Help from the dropdown.
  3. Enter your Amazon subscription ID.
  4. Enter ItemSearch in the About text field.
  5. Enter Operation in the HelpType text field.
  6. Click the Send button. Unfortunately, the response I got was not the same as the response on the NetBeans page. Just to make sure there was nothing out of the ordinary, I created the project under NetBeans 4.1 and got the exact same response.

    It was at this point I said "hmmm...." but decided to continue playing with the application. I need to go back to the Amazon web site and find out what is really happening here. Anyway, continuing with the demonstration...
  7. Select ItemSearch from the dropdown menu.
  8. Enter your subscription ID.
  9. Enter an interesting author, such as Terry Pratchett.
  10. Scroll down and enter ResponseGroup Medium.
  11. Enter SearchIndex Books.
  12. Scroll back up and click the Send button.

Modifying the Sample Application

Note to the reader: If you have read and tried to run the NetBeans article at this point, you may find as I did that pressing F7 puts starts the application in Debug mode.

It would be nice if you didn't have to paste in your Amazon subscription ID every time you wanted to run a different operation. Let's fix that:
  1. Open If you're running with emacs key bindings you can search for createGUI using [Ctrl] S, or you can look at the class in the Outline pane and click on the class function there. If you use [Ctrl] S you'll have to hit it a few times to move down the source file. If you use the Outline pane you can single click on it and go to it immediately in source. Regardless of the method used you should now be at the createGUI class function.
  2. Insert the code in blue between the two existing lines of code:
    commonTextFields[i] = new JTextField();
    if (commonParameterNames[i].equals("SubscriptionId")) {

    container = new Container();
  3. Save your changes. The file will be automatically rebuilt. To re-run the application again, press [Ctrol] F11 or click the round green run button on the tool bar.

    I'm not going to attempt to show how to use a proxy. I'm doing this behind a firewall that doesn't require a proxy.
Debugging the Application

One of the real advantages to running the sample application from Eclipse is the ability to debug it.
  1. Open if it isn't already opened. Navigate back to the createGUI class function using [Ctrl] S or the Outline pane. Using the mouse, double click in the left margin to create a break point on the variable commonTextFields.

  2. Press F11 to run the sample application in debug mode. This should put the IDE in Debug View. I've used my IDE for a while now, but if this is the first time you've run the IDE in debug mode you will be asked if you want to switch to debug view, and to make the selection automatic in the future. Note that when you finish debug mode that the IDE will switch back to Java edit view.

  3. In Debug view one of the panes opened is the Variables pane in the upper right. The variable you placed the breakpoint in is centered in the Variables pane and is highlighted. From this point you can examine commonTextFields, or continue debugging the application with F5 (Step Into), F6 (Step Over), or F7 (Step Return). Experiment and have fun!

Java 6 and one area where Eclipse is better than NetBeans

After reading the latest status report on Java 6 (Mustang) I downloaded and installed the latest Java 6 drop (build 45). I then ran some quick and dirty tests to check out some of the improvements mentioned in the status report. Note that I'm running both versions of Java under Windows XP SP2 on a Gateway M680 with a 17" LCD screen.
Feature: Improve Windows Look and Feel
Bug IDs: 5106661
Status: 5106661 integrated into b14, remaining work ongoing
The look and feel is indeed looking better. The following screenshot shows SwingSet under 5 on the left and SwingSet under 6 on the right. The look under Swing 6 uses the same windows widgets you see in Window's File Explorer.

Feature: Improved text quality and capabilities
Bug IDs: 4502804, 5057760, 4871297, 4726365
Delivered: b39
This feature has indeed been delivered. The following is a comparison between two samples of source code in the SwingSet demo app. The difference between the selection of the fonts as well as their rendering is the difference between night and day. It's unbelievable the improvement in overall quality. Again, SwingSet under Java 5 is on the left and under Java 6 is on the right.

Time and schedule permitting I'll look at other features mentioned in the Java 6 update.

Comparison: Eclipse text rendering vs. NetBeans text rendering

When I was ranting yesterday about NetBeans and Eclipse, I overlooked the most fundamental and important difference between the two IDEs: text rendering, especially in an editor pane. Rather than talk about it, look at the following screen captures where the same source file in both IDEs are shown side-by-side. NetBeans 4.1 is on the left and Eclipse 3.1 is on the right.

As far as I'm concerned the difference is crystal clear. Regardless of the warts and limitations I'd rather work with Eclipse, especially on Windows XP running on a notebook like the Gateway with ClearType technology. I tried to run NetBeans with Java 6 by changing NetBeans netbeans.conf netbeans_jdkhome property to point to my installation of Java 6, just to see if NetBeans 4.1 would benefit from Java 6's new text improvements. It does not, at least with the text editor. But it does take advantage of Java 6's text improvements in some odd places. Take a look at the following image, for example.

Look at the right side of the Properties pane and see the difference between text on the right vs. text on the left. The text on the right is much clearer. Text in the editor did not show any benefits, and looked just as bad as it does in the earlier side-by-side comparison with Eclipse.

One "Clear" Area of Superiority

I've always felt uncomfortable about SWT because I cut my user interface teeth on Java using JFC. But in this particular instance SWT is head and shoulders above Java because SWT is a wrapper around the underlying operating system's (Windows in this case) text rendering engine. Applications written to use SWT benefit from many of the Windows UI features that native Windows applications do. I have poor eyesight, and I do suffer from eye strain and headaches from long sessions in front monitors reading and working with lots of text. Working with the latest versions of Windows in front of LCD screens is a lot easier for me than stock CRTs or other operating systems that don't have the equivalent text rendering technology. The only exception to this that I've seen to date is Mac OS X.

The Future of NetBeans and Java 6

Reading the Mustang status report, this caught my eye:
Feature: New Examples
Bug IDs: 6246816, 6246820, 4989244
Status: In development
Description: Swing's current examples do not illustrate best practices and are not representative of real applications. With that in mind, we plan on providing two distinct types of examples. One shows all the widgets in all possible states. SwingSet2 currently serves this purpose but has grown stale and out-of-date. The second example type is one that better matches a real-world application, showing best practices in using the toolkit.
Let me make a suggestion to both the NetBeans 4.2 development team and the Java 6 development team. Work together so that NetBeans becomes the second example mentioned above, showing best practices in using the JFC toolkit. Both Java and NetBeans would benefit from the combined effort. And NetBeans will certainly benefit from better use of Java 6's text rendering improvements. When NetBeans text editors look every bit as good as Eclipse's, especially on LCD screens (which are the future) then NetBeans will truly stand shoulder-to-shoulder with Eclipse where it matters most.

Wednesday, August 03, 2005

NetBeans 4.1 can't import Eclipse 3.1 projects and I go on a rant about both

Just a short note to the NetBeans' folks. NetBeans has a module that allows you to import Eclipse projects into NetBeans. It appears that it only works for Eclipse 3.0.x projects. I've since moved on to Eclipse 3.1. Well, when I read how one developer felt that Eclipse failed to meet his enterprise java development needs, I got all fired up (again) to give NetBeans 4.1 (not 4.2) another chance as my primary IDE. To start with I tried to import a project I was currently working on from Eclipse to Netbeans.

So I went to the NetBeans website import pages and attempted to follow the simple and clear directions. The problem I found is that the NetBeans import plugin only works for Eclipse 3, not Eclipse 3.1. When I attempted to import a project out of an Eclipse 3.1 workspace, NetBeans 4.1 failed. It did not recognize the workspace and would not allow me to pick the project to import.

And as you can see below, the workspace directory structure does exist and it works quite well for Eclipse.

The Truth About Eclise and NetBeans (at least in my eyes)

First, let's get one thing straight. I think both IDEs suck, they just suck in different ways. Let me count the ways.
  1. Editors. I have spent years moving back and forth between emacs (and emacs-like editors) and vi (especially vim) and putting up with the holy wars between the two camps. When I attempt to use another tools editor, it usually offers an emacs emulation mode (hell, even Visual Studio offers it). Eclipse does make an attempt to provide emacs key-bindings. NetBeans does not. In Eclipse 3.1 the common editor preferences are now in one spot (number of spaces/tab, substitution of spaces for tabs, line numbering, etc). With NetBeans you have to touch each and every editor for every file type. If you have more than one type of file to edit (Java, JSP, XML for example) then you get lots of practice setting editor preferences in NetBeans.
  2. Core Java Editing. Eclipse has the best core Java editing environment. When I'm in the Java perspective (and yes, I do like the idea of perspectives) I can look at three panes to quickly find my warnings and errors. On the left is the Package Explorer where I can see the error and warning icons on each package and file. At the bottom is my Problems pane that keeps track of everything and allows me to find every individual problem in my source files. And of course there is the source editor which shows each line where there is a problem. Those features have helped me more times than I can remember when developing Java applications. Gerard Fernandes is correct that those panes can get out of sync on occassion. I've had that problem, which is corrected only by a rebuild of the project. Depending on how big the project is and powerful the machine you're own, it can go from very quick to excruciatingly slow. NetBeans will tell you if you have errors in your source code, but only in your source code editor pane. Warnings are non-existent. Errors that occur during a build will appear in the Output pane, and you can click on errors to open the offending source file at the line where the error occurs. But if you close the IDE you loose that information. Eclipse's built-in incremental compiler helps maintain warnings and errors in the Problems pane. As each problem is corrected that problem is automatically removed.
  3. Simple Database Support. NetBeans out of the box exceeds Eclipse when it comes to working with databases. Why? Because Eclipse provides absolutely nothing. There are plugins you can google down that provide the same equivalent functionality for free (SQLExplorer) that are unfortunately non-intuitive in their use, or you can purchase more powerful database editing and management capability plugins for Eclipse for lots of money. I'm a cheap bastard. So I'll take basic free capability any time, especially if I don't need fancy ERD/OR diagramming. My only complaint about the NetBeans database support is you have to know the name of the database before you can use it. It would be nice to have an automatic listing of all the databases (MySQL's show databases, for example).
  4. J2EE Support. This is where NetBeans is headed and this is where NetBeans is strongest. NetBeans has a Runtime pane (a very nice feature) that allows me to support multiple J2EE servers. I added my local Tomcat 5.0 server and immediately picked up the ability to develop with all the web applications on that running instance. I also have the ability to work with JBoss 4. I have installed version 0.7 of J2EE Standard Tools/Web Standard Tools on Eclipse, but I have not yet attempted to use them. I will say that having to download an 89MB Eclipse IDE and then a 138MB JST/WST extension is a bit much when you can just get NetBeans at a more "modest" 46MB.
  5. Plugin Hell. I have begun to feel the initial pains of Eclipse plugin version collision. Every plugin has its own unique version, and they vary within the overall Eclipse version release.Right now I can't use the Laszlo IDE because it's not yet been released for Eclipse 3.1. IBM has gotten into the bad habit of releasing, to much fanfare, new tools for Eclipse that will not run on the latest version of Eclipse, or that will not use the latest version of installed plugins. And that's getting to be really annoying. And that leads to:
  6. Plugin Management Hell. You can get to the Eclipse plugin manager under Help | Software Updates | Manage Configuration. You can get to the NetBeans plugin manager under Tools | Setup Wizard | Step 2 - Module Installation. I would have not thought to look under Help for Eclipse, and certainly not Tools | Setup Wizard for NetBeans. The bigger issue is removing plugins. In versions before Eclipse 3.1 you could remove plugins. Not anymore. The only plugin management actions you can perform on an installed plugin with either IDE is either update or disable a plugin. If you want to remove a plugin you uninstall the IDE and then, after installing the bare-bones IDE, you make sure not to install the plugin you wanted to remove in the first place. That's a bit extreme. And that leads to...
  7. Plugin Development Hell. NetBeans support for formal plugin development is non-existent. Eclipse's plugin development is obtuse. Both suck. Big time.
  8. Plugin Updates. NetBeans plugin update service is the bee's knees. Eclipse plugin update sucks dead bears out loud.
  9. Toolkit Selection.I don't care what the Eclipse camp says, SWT is not Swing. There's a lot I'd like to do with Swing that I can't with SWT. And mixing Swing with the SWT_AWT bridge is a big hack. And I don't care what the NetBeans camp says, Swing is not native and is slow and is still a lot of the awful things that Eclipse has said about Swing in the past. Although it has gotten better with Java 5. And I do like the look-and-feel of NetBeans 4. And I do like what they're doing with SwingX.
  10. We Will Sell No Matisse Before Its Time. I'm old enough to remember Orson Wells shilling for Paul Masson wines. No matter what, drunk or sober, using Matisse for anything other than carefully crafted demoware or trivial mp3 players is a royal pain in the ass. I don't know if it's Sun trying to push on the NetBeans crew, or if the NetBeans crew were just honestly enthusiastic, but one thing should be absolutely clear: don't shill a new feature until it's reasonably solid to turn loose to people like me. My view of NetBeans has been tarnished by this particular episode, and I now look with considerably more skepticism on NetBeans that I did in the past, as well as announcements from its more vocal supporters.
So which one do I use? I use both depending on the task at hand and I have actually set projects up on my notebook that I share between both (OpenMap is the biggest so far). As far as I can tell it will stay that way for the foreseeable future.

Tuesday, August 02, 2005

Dear PayPal phisher: Learn to spell

The PayPal phishers are getting bolder, if not dumber, by the day. Consider this little missive that landed in my Gmail spam folder today:
Security Center Advisory! (grabs your attention, doesn't it?)

We recently noticed one or more attempts to log in to your PayPal account from a foreign IP address and we have reasons (sp) to belive (sp) that your account was hijacked by a third party without your authorization (well duh! i guess it's ok if i give my authorization?). If you recently accessed your account while traveling, the unusual log in attempts may have been initiated by you.

If you are the rightful holder of the account you must click the link below and then complete all steps from the following page as we try to verify your identity.

Click here to verify your account (a bogus link was here)

If you choose to ignore our request, you leave us no choise (sp) but to temporaly (sp) suspend your account.

Thank you for using PayPal!
So, let's recap for a moment. I get this urgent email from PayPal with whom I have no account and have never had an account, filled with definite misspellings and dubious grammar and an even more dubious back story (come on, I'd give permission for a mysterious third party or parties to hijack my account???). And I'm supposed to follow that dubious textual link which does not, by the way, lead you to a secure (SSL) link. Even if you're dumb enough to click it, that alone should give you a Big Clue that this might not be legitimate. I wonder just how successful this kind scam is.

Monday, August 01, 2005

Long live Soyuz

Because of possible problems with the launch of Discovery, the Russians have offered to bring the shuttle crew home in three Soyuz spacecraft in January or February if they "work really hard". The Russian's are even thinking of sending the Soyuz to the moon. And all this, with a 40 year old workhorse. It may not be pretty, it may not be big, but it was there to help out the International Space Station when the shuttle fleet was grounded over two years ago, and it's been the ISS' lifeboat because of the failure of NASA to deliver the X38 Crew Return Vehicle. NASA canceled it April 29th, 2002. Because of the limitation of three crew in the Soyuz (not the Soyuz's fault) the crew of the ISS is limited to no more than 3 crew (two since Columbia, as a cosmonaut needs to pilot Soyuz back). As with so many (should I say all?) of the NASA projects, the X38 was cut when the ISS budget hit $5 Billion over budget in February 2002. Now we subtract one number from 38 and wait for the X37 Orbital Space Plane to take the place of both the shuttle and CRV. Oh wait. It's been canceled too. Now we have the Crew Exploration Vehicle to take over everything. Lovely. Just lovely.

Everybody seems to like to knock the Russian Soyuz. But the Soyuz Just Works. I hope the Russians do send the Soyuz to the moon. And I hope they do it before we do. Which shouldn't be hard given our track record over the last 30 years. We literally had space in the palms of our hands by 1969. And we pissed it away. Now the rest of the world has caught up in raw capability, if not outright finess. We're about to get our butts kicked out of space. Space was ours to loose and we've lost it big time.

Maybe I won't be buying Apple

Just when I finally felt comfortable with Apple, and after I enthused about how I was ready to buy an Apple Intel system if only it was available, now comes this report off of Slashdot that the Intel version of Mac OS X is using TCPA/TPM DRM. In fact it turns out, via Slashdot, that there is at least one Wiki devoted to MacOS X on Intel called OSx86.

The primary reason for DRM at this point seems to be to keep the Mactel version of OS X from booting on anything other than a legitimate Apple Intel system. As if that's really going to stop the hard core from running the system on anything other than an Apple Intel system. The sad thing is that I would actually pay good money to buy Apple OS X for Intel from Apple. Limiting my purchasing choices to just Apple and Microsoft for a moment, I am far more inclined to give my money to Apple than I am to Microsoft. Right now. But if Apple keeps this up, I will more than likely run a hacked version of Apple OS X for Intel, provided from some other source. I'll try to keep it legal buy purchasing my own copy and applying the hacks myself. Ah well. Let's just wait and see what the future really brings us.