Category Archives: software development

java, software development

Oracle, JDeveloper and Eclipse

1 Comment

Oracle has posted a strategy and roadmap (pdf) for JDeveloper, its Java IDE, and the Oracle ADF application framework. It looks like a bunch of interesting stuff is coming in JDeveloper 11, including JEE 5.0 and EJB 3.0, AJAX controls for JavaServer Faces, and “declarative validation using standard expressions or scripting languages such as Groovy”.

So full steam ahead for JDeveloper, but what about Eclipse? Oracle is a member of the Eclipse Foundation at the add-in provider level, but is sticking with JDeveloper as its primary development tool:

A question that we are often asked is “Why hasn’t Oracle implemented all of its design time features as Eclipse plug-ins?”. Given the popularity of this open source IDE, it is a valid question. However, the answer is simple. By controlling the entire development environment, we have been the ability to produce both the shell and the core architecture which allows seamless integration of all types of design time environments, all sharing the same concepts and look and feel. If we just created specific plug-ins for Eclipse, each plug-in might be very effective on its own but it might not necessarily be consistent or compatible with third-party plug-ins, and would not offer to developers the level of productivity provided by a fully integrated environment. For those developers who have already made the choice to use Eclipse, we also contribute to this platform and lead open source projects to provide standalone Eclipse plug-ins for specific technologies such as JSF, EJB 3.0 or BPEL.

This is consistent with the reasoning given when Oracle first joined Eclipse:

Oracle is joining the Eclipse board to make sure that Eclipse developers can take advantage of the Oracle deployment platform (i.e. database and application server).

In other words, Oracle does not want to lock itself out from Eclipse developers, which is just as well since Eclipse is by most counts the most popular IDE out there, while JDeveloper is maybe 3rd (after NetBeans); it used to be behind JBuilder but I doubt that is true now, with all the uncertainty around Borland’s tools. More worrying for Oracle is that some figures (BZ Research in December 2005) show its market share in steady decline, from around 25% in 2002 to 15% in 2005; I don’t much trust these figures but I don’t have better ones to hand.

Does it make sense for Oracle to persevere with JDeveloper? The argument quoted above is not the whole story. If Oracle thinks that combining plug-ins from multiple vendors in one IDE does not work, why is it the prime mover behind JSR-198, a proposed JCP standard for IDE plug-ins that is meant to enable interoperability across IDEs? I suggest this has more to do with Oracle regarding the IDE as a strategic asset. It wants full control of the tools as well as the platform (app server and database).

Personally I welcome JDeveloper in that I welcome diversity among Java IDEs, and last time I looked at it I was impressed with its quality. At the same time, I’m not convinced that there is any really good reason why Oracle should not embrace either Eclipse or Netbeans rather than continuing to go it alone. Despite its strong features, I doubt JDeveloper will attract much usage beyond Oracle shops, given the excellence of the open-source alternatives.

One final thought: the new Eclipse-based JBuilder will have to be extraordinarily good to succeed in this crowded market.

Tags:

internet, software development

Salesforce.com, Apex and Web 2.0 vendor lock-in

3 Comments

There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week.

I have mixed feelings on the subject because Apex is such a great idea. To write code that runs on a web server today, you have to go through a procedure that starts with learning a language, whether PHP or Java or C# or Ruby or Perl, along with some kind of web framework. Then you have to figure out how to test and deploy your code to a web server, hopefully giving some consideration to security issues along the way.

With Apex, the process is simplified. Instead of writing an app offline and then working out how to deploy it, you can write the code within a web form and deploy it by clicking a button. If Salesforce.com has done it right, the security risks are much less than with a conventional web app. By the way, you would normally work on a test copy of your live application so you do not have to inflict your buggy work-in-progress on your users. Salesforce.com handles all the difficult choices about which app server to use, and keeping it patched and up-to-date.

It’s possible that Apex and technologies like it may do for web app development what blogging software has done for web content authoring, opening it up to a larger community, and improving productivity for existing skilled professionals.

Although Apex calls the same internal APIs that are exposed through web services, it has the potential for much better performance. Consider the scenario where you want to loop through 100,000 records in code. Doing that with web services will take an age; in fact, that sort of operation is not what web services are designed for. Apex can do it though. The implication is that although you can choose between Apex or Web services, the Web Services choice will not always be viable. Another factor, as I understand it, is that Apex code can be triggered by server-side events, functionality which cannot be replicated through the web services API. The choice which Berlind notes may not be so free after all.

Is Apex lock-in? I think it is. Build your app in Apex, which is a proprietary language, and you will not be able to take it elsewhere without considerable pain and of course porting the code.

That doesn’t make it bad. The industry lives with vendor lock-in. It may still be worth it.

At the same time, this is surely the primary question you have to ask before embarking on a major Salesforce.com deployment. Do you trust Salesforce.com to keep its subscription charges reasonable, its servers running satisfactorily, its technology competitive, now and for the forseeable future? A competitive advantage could transmute into a significant disadvantage if Salesforce.com were to run into problems.

Tags:

blogging, software development

Moving to WordPress without breaking links

Some time back, I decided to migrate this blog to WordPress. Until today, I’ve been using a self-modified version of bBlog. It worked well, but WordPress has more to offer and has huge community support, so I’ve made the change. A few new things you will notice are the recent comments list, the search box, the blogroll, and limited html support in comments.

The change was delayed while I figured out how to handle old links. I didn’t want to break existing links to old blog entries, or to the blog home page; and I wanted to make it seamless for existing subscribers. In the end I did three things:

  • Installed WordPress into the same directory as the old blog
  • Modified index.php to redirect requests that point to old blog entries
  • Modified rss.php (the old feed url) so that it delivers the new WordPress feed

In other words, I’ve kept bBlog running in the same location as before. This trick works because the two systems only have one filename collision, which is index.php. The result is that links to old blog entries still work.

If you subscribe to the blog, you don’t have to change anything. The only annoyance is that you’ll likely get some duplicate posts, but I’m hoping that is better than having to re-subscribe.

I’ve only migrated a few recent posts and comments to the new blog. I might do the others, but it’s more likely that they will remain in the archive blog.

Tags:

software development

Users plead with Borland to give up .NET

13 Comments

Delphi user and Kylix enthusiast Simon Kissel (Kissel is the author of CrossKylix) has written a sharp critique of Borland’s developer tool strategy.

He says few are buying Borland’s .NET tools. They buy Delphi for its native code compiler, and need new features like Unicode and Win64 support. Borland (or DevCo) by contrast is focusing on .NET, but is failing because it cannot keep pace with Microsoft.

I am about 75% in agreement with Kissel. In addition, the splitting of DevCo from Borland, presuming it eventually completes, changes the dynamics in favour of native code. If you put ALM (Application Lifecycle Management) at the centre of your strategy, that pushes you towards .NET, which is great for Enterprise development. If you split off the pure development tools from the ALM side, that gives more voice to the non-Enterprise developers, where .NET has less appeal.

However, a key issue not covered by Kissel is that Win32 development is in decline. That decline will accelerate once Vista and .NET Framework 3.0 become widely deployed (admittedly that will take a couple of years at least). Another factor is the continuing growth in web applications and rich internet (or “smart client”) applications, for which Win32 is ill-suited. It would be tough for Borland to bet its future on a declining market.

Further, Kissel makes too much of how “The other big market player in native RAD Land, Microsoft, has just left the fields.” That’s true only up to a point. Microsoft has abandoned native code VB, but then again VB was never close to Delphi as a native RAD development tool; it did eventually get a native code compiler but always had big runtime dependencies and difficulty in making full use of the Windows API. In addition, Microsoft still has Visual FoxPro (more RAD than native) and Visual C++ (more native than RAD), so it hasn’t altogether abandoned the field.

What’s clear though is that Borland can’t continue with a .NET strategy based on supporting .NET features a year later than Microsoft. And it has to make more of its native code tools – though it actually took a big step in that direction with Delphi 2006, which is excellent for Win32 work.

I feel a little bad here. I said some years ago that Borland should embrace .NET. Still, I did also say this:

However, and it is a big hesitation, to prosper with .Net Borland needs to do more than simply build a Delphi for .Net at its own rather leisurely pace. To succeed the company needs to capture and pursue a vision of what .Net can do; RAD for the Enterprise, .Net beyond Windows; or whatever.

At the time I was hoping Borland would get 100% behind Mono and come up with elegant cross-platform .NET tools. That has never happened; though perhaps it still could.

Tags:


software development, windows

Times Reader memory shock

9 Comments

I’m an admirer of Times Reader; in fact I’ve become something of an addict. Then a discussion about .NET performance prompted me to check the memory usage:

At 92MB working set and 50MB private working set, this application uses an alarming amount of memory. I found this interesting as it’s an example of a real-world Windows Presentation Foundation application. WPF is great to work with, but if it catches on, how many concurrent WPF apps will we be able to run before our shiny Vista systems choke?

Caveats: All three of Vista, WPF and Times Reader are in beta, so things could improve; then again all three are close to release, so this is a real concern. More research is needed.

Of course it’s possible that Times Reader is just holding far too much data in RAM, though it is such a great app in other respects that it is hard to believe.

Other points of interest: as you can see from the screenshot I have Paint.Net running as well as another .NET app, Guidance Explorer, both of which consume less than half the amount of memory. In fact, Paint.Net’s usage is not bad in this context, given its sophistication and the fact that image apps tend to be memory-hungry.

I’ll have another look when the full releases are available.

Update

I investigated how much overhead WPF is introducing by comparing two trivial to-do list apps of identical functionality. One is XAML/VB.NET; the other is Windows Forms. Both compiled to release builds in VS 2005. Here are the results:

XAML/VB.NET

Working set: 30MB
Private working set: 11MB
Commit size: 44.5 MB

Windows Forms

Working set: 13.5MB
Private working set: 3MB
Commit size: 15MB

So on the face of it, there is a substantial memory jump for WPF.

Tags: