Image of Navigational Map linked to Home / Contents / Search TechEd '98

by Jim Karabatsos - GUI Computing
Image of Line Break

Well, I just returned from Tech Ed 98. It was strange for me to attend a conference as a delegate only and not as a presenter. I guess it renewed my understanding of just how incredibly draining it can be to spend a day listening to others present material, some of which you know nothing about (and some of which the presenter knows nothing about <g>).

It will come as no surprise to anyone that the Internet and Web development was prominent in just about every stream. Is there anyone out there who is not doing web development? Talking to the presenters and to the delegates, you would be forgiven for thinking that nobody is working on traditional data processing applications any more.

Microsoft will have you buy into the Windows-only mindset, and indeed they make a very good case by providing a set of tools that work well together most of the time and enable some very cool approaches to application development and deployment. Sure, there are still a lot of Un*x boxes out there serving Web pages and a lot of Perl script is running to create dynamic content. But the fact of the matter remains that it is quite possible to host a very busy site on NT using IIS -- just look at microsoft.com as a prime example. If you are not committed to using any particular platform, then deciding upon IIS on NT opens the door to what I believe is the most productive development environment for web applications. And no, I am not talking about Active Server Pages (ASP). Quite frankly, both VBScript and ECMAScript (aka JScript) just plain suck as development languages. No variable types, terrible error handling, comments slowing execution -- heck, I'd be better off using GW-Basic!

The way to do web server development on IIS is to use the tools you already know, probably Visual Basic but just as easily in Visual J++, to create COM objects that encapsulate all of the business rules and expose a set of well-designed interfaces that are called from ASP script code. The prime directive is that script code is used only as glue, passing parameters to those objects and (perhaps) doing some formatting of the output. Personally, I'd even wrap that formatting code in a COM object, but I guess I have this pathological desire for a real development environment that not everybody shares.

Dynamic HTML (DHTML) was heavily emphasised. It must be frustrating for Microsoft that, despite the support for DHTML in the latest versions of both IE and Navigator, the incompatibilities between the two implementations of the Document Object Model (DOM) continue to make development of cross-browser applications more difficult than it needs to be. Again, Microsoft makes a compelling case. Writing to the lowest common denominator on the browser end means that you can only send static HTML down to the client. In a very real sense, we have reverted to the block-mode terminal of yesteryear and are severely under-utilising the processing power of the client machine. Let's face it: rendering HTML is a pretty demeaning task for a fast Pentium.

Sure, if you are developing a site that you expect to be hit by all types of browsers, then you really are stuck. You need to balance the extra reach that static HTML gives you against the limitations that are inherent in that technology. But if your site is predominantly hit by IE and Navigator, then you should probably give DHTML another look. For intranet development, you really need to take another look.

COM+ was obviously at the forefront of the Microsoftie's mindset. Essentially, COM+ is the next evolutionary step in the development of the COM architecture. It has some cool new capabilities but, as it is not shipping yet, I won't go into them in this article, except to make one important observation. In the COM+ vision, transaction support will be built into the COM+ libraries. There will be no question about whether you will deploy MTS because MTS will essentially become part of the operating system software. Transactions will be supported and used everywhere, so much so that even TOOs (Transaction-Oblivious Objects - I just made that up) will be automatically enlisted within transactions.

At the 1993 VB Australia conference and at many DevEds that I spoke at even earlier, I emphasised that OLE was important and that you needed to get across that technology if you were going to have any chance of staying current with the Windows technology. At the 1996 VBA, I stated that the big new technology from Microsoft (then shipping as part of Visual Studio 5 Enterprise) was MTS and that you ignored it at your own risk. Well, COM+ is basically MTS 3, and I really think you need to make a conscious decision NOW to plan some time for you to at least tinker with this technology. I generally try to avoid making predictions but I really feel that this is both important enough and certain enough to make an exception.

Pardon me while I step down from the pulpit.

The real surprise of Tech Ed for me was the new version of Visual J++. We have had access to it for a while, but I never really had a chance to take a good look at it.

Let me explain my take on Java here. Java is a language, just as C and Basic are languages. Just as you can have C for Unix and C for Windows, so too you can have Java for specific platforms.

Sun is promoting the position that Java is a platform and that real Java must be host-platform independent. Platform independence is a good thing, or it would be a good thing if we could make it happen. I don't think anyone would say that they actively do not want their applications to run on more than one platform. However, when presented with the question: "how much are you prepared to pay for that platform independence?" the answer is usually "Not much".

Folks, TANSTAAFL - there ain't no such thing as a free lunch. The price of cross-platform portability is the need for applications to be written to the lowest common denominator and a significant drop in performance. The latter is not because of the interpreter - JIT compilers can fix that little problem - but because of the need to map a generic UI onto a particular platform and to maintain UI semantic consistency on all platforms. That is both hard and expensive to do.

I have no real problem with Microsoft's design goal to target Windows as the platform for programs written in VJ. If you want a cross-platform tool, there are plenty out there to chose from. VJ is not it.

You may or may not agree with the previous paragraphs and I certainly don't want to get into an argument with anybody about this. If you believe that we will indeed see cross-platform programming move from a curiosity to real-world, productive development in our time, then more power to you -- I really do hope you are right, but that's not the way to bet.

The question then becomes "why would you use Java if you were not interested in cross-platform compatibility?" If you have to ask, then I can really only make one suggestion: get yourself a good book on Java programming, one that focuses on Java as a language and not on the AWT or applets. Java is fully OOP, OOP to the core. It does automatic garbage collection. It understands interfaces as a native language element. It is inherently thread aware. It natively supports all the common internet protocols in addition to low-level sockets. The list goes on and on -- as a language, Java is very nice indeed. Everyone I know who has had a chance to really play with Java invariably uses the word "cool" when describing the language. I have often said that, despite Java's syntactic similarity to C++, it is much closer to Delphi in philosophy and attitude and my four-year love affair with Delphi is well documented.

I attended a presentation on VJ6 by none other than ex-GUI-ite and now Microsoft Visual J++ Product Manager Tony Goodhew. Forget everything you know about VJ -- version 6 is an entirely new animal. I spent most of the session thinking to myself: "this is Delphi for Java". I suspect that a certain individual who used to work for Borland but now works for Microsoft has had a hand in the new-look VJ and all I can say is that I approve thoroughly.

Evaluated purely as a Windows development platform, VJ ROCKS! The only thing I can point to that is a little bit disappointing is that (for the time being at least) VJ cannot compile to native x86 code. So, while you can create a stand-alone executable, it is really just a wrapper for a traditional Java VM application. Don't be misled -- the performance is still very good, better than VB4/32 because of the JIT compiler in the VM, but it can only get better when MS bolts its excellent, direct-to-Intel compiler onto the back of the product. Maybe VJ7?

OK, I lied, there is one other thing: why did they provide the option to generate a ZIP file format but not to actually use any compression? Bizarre!

VJ can use ActiveX controls, ADO and data-aware controls. Its programming paradigm is very similar to Delphi (and indeed VB): you create forms and write event handlers. You can create ActiveX servers and controls with full support for interfaces and events. And you can do all this using inheritance, so you can extend a component or an object without writing a wrapper for it. And you can use VJ components from VB.

Take a good look at VJ6. It is one cool product. There are only two reasons that I will use VB for new products: we have a lot more VB experience (and that counts for a lot) and I am not sure how well Active Reports will work in VJ. Now that I have a good reporting tool, I'm not going to let go so quickly. Perhaps Data Dynamics should look at a VJ version.



Written by: Jim Karabatsos
Septmeber '98

Image of Arrow linked to Previous Article
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]