Java Studio Creator on Mac OS X is an easy-to-use tool for building Web applications with Java. Read this article to learn how to get started developing with it on the Mac platform. Also, Apple has released Xserve RAID Admin Tools 1.3.2, an update to its remote management software that simplifies setup and monitoring of storage volumes.
Using Java Studio Creator on Mac OS X; Xserve Update
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Another example of write once run anywhere crap that looks exactly like it belongs on Windows XP, not on OSX.
It would really be nice if, for a change, companies would stop being so lazy as to not bother making the user interface compliant with the standards of the platform they are running on. This is what makes me hate Java as an app development language.
You obviously aren’t a developer. This has got nothing to do with Java since it can look completely OS X native. The ‘problems’ in that program like the lack of using ScreenMenu bar and the fact that the tabs aren’t OS X like can be easily addressed.
This does show that the developers did adopt a half-@$$ed approach to porting the apps and not testing it fully on OS X before releasing it.
On the other hand, this tool is meant primarily for developers many of whom don’t really care if the menubar is on the screen or not. Most of us are just happy to have apps that work and this article is about building web apps on Java. If all you can do is criticize the look of the tools being used, then I think they’re doing pretty well.
No, this certainly has a lot to do with Java and its marketed position as the great “write once, run anywhere” environment. Obviously Java has a very useful role developing server components and the like (see WebObjects), but I’ve seen very few java applications where the developer even bothered to follow any HIG or maintained separate versions for a particular platform. Windows != OSX != Gnome != KDE and they all have different HIG specifications, but hey as long as you have Java, or now .net with mono, why bother worrying about any of them 😐
And just because widgets and controls can take on a native appearance does not mean that the app looks and behaves like it belongs on that platform. Non-standard applications are LESS useful on a particular platform than those which follow the interface guidelines because they require users to do thing in ways they aren’t accustomed to. This is why I am annoyed with the Java development mentality that Sun has promoted since its introduction.
I think developers *do* care about their IDE.
My decision to leave Unix for Mac OS was made consciously by me. The decision to use XCode instead of Shell/VI/Emacs/Eclipse/NetBeans was also made very consciously once I got to know the program. The traditional (pronouce: Windows) IDEs just don’t fit _either_ the Unix tool-approach, nor the simple Mac approach.
For people that absolutely have to use a certain IDE Java’s cross-platformness is a good thing, but then those people mostly have a PC at work anyway. I guess almost every Mac user that really cares about his computer’s mac-ness prefers XCode.
What kind of nonsense is that? What is your attitude?
You instantly dislike it because it reminds you of an app you’ve seen on Windows? Honestly, be an adult, if you are an adult.
As a developer, this app looks great! I had no idea it existed and I am now downloading for linux. I’ve been using netbeans to do J2EE development but it leaves something to be desired as I have been using visual studio .net for years. This app looks to compete w/ vs.net, beautiful!
How many people actually care about the placement of the menubar or the look of widgets in an IDE? IDEA is popular yet it’s widgets don’t really look native. That’s the point I’m making. Of course developers care about their tools. If it makes them lose productivity, it’s a bad tool. But if it doesn’t look pretty, does it matter?
Sure, you’re right there.
I don’t very much care how crappy an application looks (I even use NeoOffice, if mainly for .doc and .ppt viewing). To me personally XCode feels just more comfortable and less overloaded (and MUCH faster) than all the Java IDEs, but admittedly I’ve never tried IDEA (heard lots of good things though).
Yeah great, a Sun rip-off of visual studio. Well, that wasn’t at all the point I was making anyway.
My point is that I am sick of applications “ported” over to the Mac that I might as well be running on Windows because that is how the interface is designed. Perhaps you just don’t realize, as Ulrich pointed out, that most Mac users have reasons why they prefer the Mac, and the user interface is a BIG part of that. As I was also pointing out, Java and now .net exacerbates the problems because application developers who use Java don’t even have to give a second thought to their applications interface because once it is compiled it will pretty much run, unaltered, on any platform. While this might make development easier, it sucks for users who get stuck with non-standard applications.
So while this article may specifically be about an IDE (one that is running on a Mac and is most certainly not one that was ported with the conventions of the Mac in mind), my general complaint isn’t just limited to this one example . As you pointed out, it is an exact clone of VS.net (down to the blue and red control buttons on the toolboxes).
You’re sick of applications ‘ported’ over to the Mac? You seriously expect loads of software houses to just create a new source tree just to make their products run on macs when the Mac installed base is the way it is currently? That’s just not being realistic.
It is possible to separate the guts of an application from its user interface so that you can have versions for different platforms that follow the proper HIG standards yet share much of the same code-base. I can’t believe that Linux users (who use gnome or KDE) like to see so many apps that look like they came straight from Windows either.
As much as I tend to dislike Microsoft products, I do commend them for at least putting the effort into making Office for Mac feel mostly like a native Mac application.
Instead of being critical, I’d be glad that you can at least run all Java software even if they haven’t changed the UI. Like Viro said, if it weren’t for the write once, run anywhere there would be no way Sun would invest in creating a separate Mac version.
Well, they wouldn’t really have to invest anything at all as long as it is built to run in the standard JVM. But that is the sad point isn’t it?
That being said, I think you’ve missed the point of Java altogether and I agree with Viro, you’re obviously not a developer.
If I can write an application in Java and run it on any platform which supports the JVM (which is *many* platforms)…then I’ve saved myself that much time, effort, and money, many times over by not having to re-write an application to fit the exact UI guidelines of each of these platforms.
It would even be possible to run it to look closer to the Mac interface if the detected platform were Mac, so it is actually possible.
However, This is pure eye-candy to appease Mac purists, such as yourself, who can’t stand to see it any other way. The application is just as usable and functonal, either way, don’t use it if you don’t like it simply because it isn’t laid out exactly how you like it.
So many idiots so little time.
You want write once, run anywhere that is native on each platform?
http://www.eclipse.org
Eclipse and the SWT windowing tool kit is the answer.
ATTN: Mac Users
Download eclipse for Mac OSX and then let us know how Mac-ish it is….
You don’t need to do anything to get a ‘Native’ look and feel with the exception being apple’s toolbar.
When you are developing Java applications it’s easy to change the look and feel. To get menus out of the window and into the menu bar you need only to set a single system property:apple.laf.useScreenMenuBar=true (by default it is false). Most developers don’t know this, after all how many are using Macs?
Also the default look and feel for Java on the Mac is Aqua. A developer needs to intentionally override this, which many do. Here’s a reference about it from Apple’s web site, http://developer.apple.com/documentation/Java/Conceptual/Java141Dev…
SWT is not the answer. When delivering applications using SWT to clients, say in a corporate network, you would need to have a specific build for each platform that includes the SWT libraries for that platform. In general, while the developer may have SWT installed on his system most users won’t. If you’re a small shop or have a small team trying to deliver applications in a heterogenous environment, Swing is a godsend. Delivering SWT apps just has too much overhead.
Also, Java Web Start is a very handy way to devliver light weight apps. Also using SWT makes delivering Java Apps with Java Web Start problematic.
Now if SWT was integrated into the JVM well that would be a different story.
Interface guidelines are not just about eye-candy, they are about creating a platform-wide standard for application behavior and control layout. So “write once, run anywhere” may make development easier but it shows a lack of caring about the users on that platform. It’s not just about having buttons and scrollbars looking aquafied. There are certain ways that Mac (or Windows or KDE or gnome) users expect applications to behave, and when they don’t they are less useful because the user now have to learn a non-standard way of getting things done. That is my whole point.
Interface guidelines are great things, no question. However, sometimes the user ‘needs’ the app and doesn’t give a rats ass what it looks like just as long as it helps them get something done. In a perfect world we would address the user needs and follow the HIG guidelines, but when you have a constrained time/budget you really most concerned about getting out a working product.
It’s great to debate the user interface/write once-run anywhere stuff. This is for WEB APPLICATIONS. I would assume you’d html/xhtml or the like as the user interface. Eclipse and SWT or whatever is in a different category all together. The article even has a finished product in a web page. HELLO!
* This is for WEB APPLICATIONS. *
We are talking about the IDE, Java Creator Studio, not what is can produce.
* Also, Java Web Start is a very handy way to devliver light weight apps. Also using SWT makes delivering Java Apps with Java Web Start problematic. *
SWT is basically just a 3rd party library, it is almost no different than say, Log4J.
All you have to do is specify the native libraries you need for SWT on each platform. This is in the Web Start docs, eg:
<resources os=”Windows”>
<nativelib href=”native/windows.jar”/>
<jar href=”lib/swt/win/swt.jar”/>
</resources>
<resources os=”Linux”>
<nativelib href=”native/linux.jar”/>
<jar href=”lib/swt/linux/swt.jar”/>
<jar href=”lib/swt/linux/swt-mozilla.jar”/>
<jar href=”lib/swt/linux/swt-pi.jar”/>
</resources>
<resources os=”Mac”>
<nativelib href=”native/macosx.jar”/>
<jar href=”lib/swt/mac/swt.jar”/>
<jar href=”lib/swt/mac/swt-pi.jar”/>
</resources>
What pray tell are the non-standard ways of doing things that the user has trouble getting adjusted to? How is Office for Mac more Mac-like than say an app like Eclipse or Azureus (spelling?) or JEdit?
Having multiple frontends to an application is very well and good, but that’s going to increase cost and this cost is going to be passed on to the end user. The net result is you’ll end up with a more expensive app on platforms that aren’t too popular.
Witness, Mac games already cost on average 33% more (list price £39.99 vs £29.99) than their PC counterparts here in the UK. Sure you can get mac games cheaper, but the same can be said of PC games.
Java works very well here in bringing down development costs. Sure, it isn’t perfect but it works quite well most of the time.
No it isn’t. SWT apps require you to distribute a binary for each platform you’re developing for. Even then, it doesn’t miraculously make your app act in a native way with a fully native interface. Just look at the tabs in Eclipse’s text area. That’s definitely not standard Mac OS X.
But the question we’re asking is “Does that affect the usability of the app?” My answer would be no.
On a tangent, I personally never saw the point to SWT. Since you have to distribute a binary for each platform you’re developing for, how is that different from using a toolkit like wxWidgets or Qt since you end up distributing binaries for each platform you’re targetting? One benefit wxWidgets and Qt has is that they don’t require the JVM and thus are smaller, lighter and run on more platforms than Java ever could.
The of SWT is to use the native interface with Java.
You can take advantage of all the Java libraries but with an application that actually works right for the end user.
And Java CAN run natively with SWT, it’s called GNU Classpath and GCJ. You can compile to a native application, just like a C/C++ app or whatever. Yes, I mean without a JVM.
There are several differences:
* the one menu for the current window (instead of one menu for every window on screen)
* like Unix the tendency to use several windows that you can individually minimize, exposé, or whatnot, instead of one fullscreen window with lots of tabs or subwindows inside; note that this also allows much nicer working if you have more than one screen on your desk!
* palette windows instead of large toolbars on the top of your fullscreen window; these palettes are not like windows, so they disappear when you focus another application and reappear when you are working with that application
* keyboard-shortcuts with the CMD (or Apple) key. Most Java-apps use ctrl instead, which is nice on Win/Unix, but not mac-like.
* for Cocoa-apps: integrated spell checker etc.
Those are what come to my mind. Also most native (i.e. made with Interface-builder) apps look just much better laid-out than even Java-apps with the Aqua-look on them. The proportions match better. It’s hard to explain, but you feel the difference.
Finally managed to download the app :-). It seems to be based on an old version of the Netbeans IDE.
* the one menu for the current window (instead of one menu for every window on screen)
So to get the screen menu bar, just edit the ide.cfg file found in the bin directory and add the line -J-Dapple.laf.useScreenMenuBar=true and you will have the screen menu bar.
* like Unix the tendency to use several windows that you can individually minimize, exposé, or whatnot, instead of one fullscreen window with lots of tabs or subwindows inside; note that this also allows much nicer working if you have more than one screen on your desk!
Safari itself breaks this rule. Plus it’s more a matter of personal preference. Some like MDI, some don’t.
* palette windows instead of large toolbars on the top of your fullscreen window; these palettes are not like windows, so they disappear when you focus another application and reappear when you are working with that application
Palette windows are nice when they make sense (like in Office for Mac). XCode makes use of a lot of toolbars. Large toolbars. Again, if using toolbars is against the HIG, Apple is guilty of breaking it.
* keyboard-shortcuts with the CMD (or Apple) key. Most Java-apps use ctrl instead, which is nice on Win/Unix, but not mac-like.
Agreed. Whole-heartedly. This is a very annoying thing about many Java apps. However, Eclipse doesn’t have this problem. Neither do the latest nightly builds (*not* the beta) of Netbeans. So it is being addressed and it doesn’t look too hard to do.
* for Cocoa-apps: integrated spell checker etc.
Again, only when it makes sense. Safari doesn’t do spell checking when I’m typing this message out for example. Apple would be guilty of breaking their own rules if this was part of the HIG.
All in all, while Java apps aren’t really Mac like, they are close. And the only thing that is a real show stopper is the use of keyboard short cuts. But as has been demonstrated by Eclipse and recent builds of netbeans, this is no longer an issue and the problem isn’t inherent in Java programs.
* like Unix the tendency to use several windows that you can individually minimize, exposé, or whatnot, instead of one fullscreen window with lots of tabs or subwindows inside; note that this also allows much nicer working if you have more than one screen on your desk!
<em>Safari itself breaks this rule. Plus it’s more a matter of personal preference. Some like MDI, some don’t.</em>
Actually Safari’s default AFAIK is to not use tabs. Still, browsing is one case where I use tabs (in Camino) myself.
But actually it makes much more sense to implement tabs on a window manager level — just try out Fluxbox (for X Window), where you can group several windows into one and have their titles stick out as tabs.
<em>Palette windows are nice when they make sense (like in Office for Mac). XCode makes use of a lot of toolbars. Large toolbars. Again, if using toolbars is against the HIG, Apple is guilty of breaking it.</em>
Agreed. With Cocoa (or NextStep) Apple introduced all those toolbars again. I forgot since I have them turned off all the time
Generally I don’t really understand the reasoning behind using toolbars instead of menu/shortcuts, since the icons are mostly undecipherable anyway (with hundreds of them, just look at OpenOffice).
I didn’t know that Safari does not use spell checking. Maybe Apple really need to look into their own use of their own APIs
All in all, the different platforms seem to be converging and as you said, Eclipse has made big improvements.
Again, only when it makes sense. Safari doesn’t do spell checking when I’m typing this message out for example. Apple would be guilty of breaking their own rules if this was part of the HIG.
Safari most certainly does check spelling as you type. Go to Edit -> Spelling -> Check Spelling as You Type.
I don’t think that it is set by default though.
Another very visible example of Mac (and gnome now too) HIG is the location and wording of buttons on windows and confirmation dialogs. “Yes, No, Cancel” is definitely not used the Mac world.
Thanks for the headds up about speel checking. Now I get to see where my speling errors are and setneces like this will now be flagged up.
This is something that I didn’t know about and I’m glad you pointed it out. Thanks.
Thanks for the headds up about speel checking. Now I get to see where my speling errors are and setneces like this will now be flagged up.
Heh heh, class!