With the Standard Widget Toolkit (SWT), you can develop a stand-alone Java application that feels and operates like a native application. If you’ve spent any time developing Java client-side applications for Windows, you’ve probably wanted to integrate some native Windows components into your applications. This article shows you how to use Eclipse to easily leverage and integrate ActiveX controls within a stand-alone SWT application.
Eclipse does ActiveX Controls with Java SWT
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Caveat emptor with SWT, it is not truly cross platform like Swing and is NOT 100% Java. It relies on native libraries compiled specifically for the OS it is running on. This is not necessarily a big deal but can be a pain in the butt when deploying your app. Beware.
Microsoft was a big fan of Java in the early days as it was a great match for COM.
So building ActiveX/COM apps with J++ was a blast. Easy and fast. Microsoft’s native code bindings were simple, much more elegant than the messy JNI we have today.
As IBM and others are finding out, building “100% pure” client apps does not work for most users.
Of course, even with Java finally catching on and making it possible to build usable client applications, with all the new API’s in Windows that are coming out, Microsoft will have made sure no Sun version of Java will work right on Windows for another few years.
Too bad Sun got all puffy and didn’t accept ‘delegate’ and J/Direct and the few other SMART changes Microsoft wanted to make to Java — on Windows — all those years ago. We might we writing everything for Windows in Java these days.
Actually. In theory swt is less portable in swing. In practice however it works on much more java vms/platforms than swing does.
There may be one or 2 obscure platforms that swing has over swt, but swt definetly has more and it’s defiently friendlier to use on platforms that it does work.
Happy SWT user,
Taras
I have this theory that using gcj(or other java2native compiler)+swt it would be more productive than coding c++.
Apps should appear just as responsive to the user whereas the developer gets to leverage fast development time of java. Portability might even come for almost free in that case.
This seems to be much better than having to require the user to run a particular java vm. Those are big bloated pieces of software that most users wouldn’t know how to get. This way the issue of bundling vm with installer & managing multiple vms nicely goes away.
I have been developing Java for the last 6 years and best part of it is the portability, scalabilty, and stability. I have to agree I have written very few swing apps but recently in swing. I think client side of Java is in par to MS client activex with JDK 1.4 and above. The future of Java is bright in server and client . I dont think I will do any project in swt even tho I love WSAD as IDE. Our enterprise has been mirating from windows server to linux for past 2 years and it has been a bliss for us in java. Now the most of the desktops at work is changing to Redhat 8.0/9.0 desktop. Java is the best thing in our IT but in some cases we still use c++.
There are of lot good swing apps our there like intellij, thinkfree, jbuilder, limewire, esri mapping tool etc.
Caveat emptor with SWT, it is not truly cross platform like Swing and is NOT 100% Java. It relies on native libraries compiled specifically for the OS it is running on.
I don’t see why native swing would be more portable than SWT. In fact i don’t see it because Java program isn’t really portable(leave commercial-breaks outa game), Java is linux+windows+solaris platform only thing. *BSDs are out of game for few months(years?) till they have fully functional !beta realease of RECENT JRE+J2EE, other OSes the same but even worser.
So considering Apple means nothing here in Europe(nowhere around if you round 0.1% to Zero(yes the smashing pumpkins Zero ;-))
That left us with SWT native libraries need of beeing ported only to linux and windows(because I can’t see reasonable sane solaris desktop). Also in that light ansi C++ looks twice that portable compared to Java application, because modern C++ application using modern libraries compiles on plethora of platforms using gcc unlike java.
Just my 0.0171 Euros.
that currecy conversion is broken, segfault in my C++ code =)
why I should integrate native Windows Widgets in a Java app????
Hmmm….. let me remenber… what was the fun part of Java???
Ahh I got it – write once, run everywhere! And now with native widgets?
Thats a crap design for a Java App. If you want this – go along with C# and .NET! Event the SWT idea in Eclips is its largest show stopper! I for one had already fired the guy who came up with this idea. I still can not get the point why the did this – speed?? *lol* Eclipse is the worst performing IDE around – NetBeans, for example, pure Java, performs much better. And I know what I am talking about. I am a software developer an I work all day with WebSphere Studio Application Develper (shoet WSAD), IBM’s incarnation of Eclipse. The latest version of WSAD, 5.0.1, is about 2.1GB large and an amount of 68000 files in 15000 directorys – and It doen’t got a gui designer yet! This is absolutely overblown. My Systemvolume of my Mac OS X volume with all the Apps I got (Photoshop LE, Corel, all iApps, Onmi Graffle, all DevTools etc…, has about half of the files WSAD has!
From a developers point – it is a shame.
You are not integrating native Windows Widgets in Java with SWT. Granted .. I you do activeX then its Windows. But thats just one of the things SWT can do. Just use the standard widgets – lowest common denominator – then its just as portable as SWING and it looks and feels native.
With regards to WSAD5 – yes.. its big and unless you have a lot of memory in your PC then it will be slow.
WSAD5 does have a GUI designer – you probably just have to look a little harder or rtfm.
Actually. In theory swt is less portable in swing. In practice however it works on much more java vms/platforms than swing does.
There may be one or 2 obscure platforms that swing has over swt, but swt definetly has more and it’s defiently friendlier to use on platforms that it does work.
<p>
AFAIK Swing works on the same platforms SWT does and possibly more. Also, SWT development is far from friendly and in some cases downright nasty. Swing isn’t a picnic but it makes far more sense and is far more extendable than SWT.
Cos Java is a much nicer language, with a clean API (YMMV).
Java application, because modern C++ application using modern libraries compiles on plethora of platforms using gcc unlike java.
No, just like Java, The GNU Compiler Collection(GCC) includes a Java to native compiler (GCJ) and a big old chunk of the APIs. (Alas not AWT or swing yet, but then there is wx4j & SWT).
re: SWING/AWT has less plateforms than SWT.
I’m not too sure if thats true, Kawa ha(s|d) a BeOS port of the AWT (using “lightwight” compements where it could, so not a complete port but one that worked). Plus you can get an opensource port of AWT & Swing for both vt100 terms and X11.
Wasn’t that one of the reasons why Sun sued MS?, for not complying to the Java standard?, for doing things like J/Direct AND at the same time using the Java logo on J++?.
First off – it’s not like you make native calls in YOUR code. The swt.jar will bring in the natives and you code to the java API SWT provides. As for portability, with Win32, Carbon, GTK2, Motif, and Photon bindings I am not sure you can point at a viable platform where SWT doesn’t work.
On the comments made about Swing being more friendly – that is because Swing also provides the upper layer APIs for Document providers and the like. Take a look at JFace (also eclipse.org) which builds much nicer constructs with the SWT widgets.
You are not integrating native Windows Widgets in Java with SWT. Granted .. I you do activeX then its Windows. But thats just one of the things SWT can do. Just use the standard widgets – lowest common denominator – then its just as portable as SWING and it looks and feels native.
Wait, isn’t that what the article is about? Integrating SWT with ActiveX controls? And, by doing so, you make your app less portable. Why IBM would advertise this, is another question. Probably because they like Sun about as much as they like MS.
WSAD5 does have a GUI designer – you probably just have to look a little harder or rtfm.
Which, IMHO, is one of the major reasons WSAD and Eclipse are terrible IDEs. You pratically MUST have training, or at least set aside a significant amount of time, just to learn where everything is. It is not intuitive, information is hidden throughout in perspecitives our what not, and, even on my dual 2.2ghz athlon w/ 1gb mem, is still VERY slow. I much prefer IntelliJ’s IDEA, as, without any knowledge of the IDE, I was able to sit down in front of it, and immediately become productive. But, I’m moving away from the point of this article, so I will stop my ranting about WSAD now 🙂
Wasn’t that one of the reasons why Sun sued MS?, for not complying to the Java standard?, for doing things like J/Direct AND at the same time using the Java logo on J++?.
Yes, but MS put it into the VM. IBM has put it into jar/addon/library, whatever you want to call it. Anybody can write their own java libraries.
I am not sure you can point at a viable platform where SWT doesn’t work.
As soon as you add ActiveX controls, like this article talks about, all the other platforms besides Windows, will not work.