Develop Reference

Java and GUI options

I am pretty capable when it comes creating GUIS in Java using Swing, however I can't help feeling that what I am creating is a little too simple. I am getting annoyed when trying to make quick changes.
If I had more free time I would love to spend time becoming more familar with Swing however at the moment that is out of the question.
So my question for the community is, do you have any thoughts on an alternative way for me to make more attractive GUIs?

This is a very good thread discussing this. Swing is a very capable framework/library, and you can do many things with it and certainly attractive GUIs.
If you like, you can use a GUI designer, such as the one that comes with Netbeans.
If you don't want to stay with Swing, there is SWT, but, that adds your bloat to your code since it isn't standard, and it won't necessarily make your app look better.

I am not saying this is a good idea, but you could use Adobe Air/Flash to create your GUI and then use BlazeDS to communicate between Java and Flex/Air/Flash. It does look better but then you are programming in Flash which some people don't like.
Not saying that is a good idea, but it does work.

Is it possible to port Swing into .Net world?

My question is it possible to port Swing into .Net world? Or a project like this has already been started.
If it is not possible, can anyone please shed some light on the reason?

It won't translate on a line-for-line basis, to be sure, but it can be done, especially if your code is properly layered.
WinForms does a lot of things differently (IMO better, for the most part) that Swing, and WPF is even more different. It can be done, but it won't be easy.

The closest that I have seen is IKVM. It is able to run java code under the CLR, including some AWT/Swing support. The swing support is fairly limited, though, and probably inadequate for any large applications.

Future of GUI development in Java? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Considering that
Sun/Oracle decided to not develop Swing any further after they "invented" JavaFX
JavaFX doesn't really work and some consider it a failure already
the not really platform-independent nature of SWT, the manual task to dispose GUI elements and the necessity to bundle platform-specific libraries
is there another way out?
If I would like to do GUI development on the JVM
with a good API (Swing and SWT are not bad, but they are not really good either.)
which "feels" responsive (still a problem today with Swing and SWT, despite the claims that this is solved.)
which won't be obsolete in a few years
what decision should I make?
Is there even a third option available or a possibility there might be one in the future?
An option
which is fast and responsive (Not Swing's ideology of "If it's not fast, it is the developer's fault")
with native look and feel
with a single library which runs on all platforms
Is this realistic?
Thanks!
=========
To clarify: If I have to start a new software project on the JVM, there are several existing options, like using SWT or Swing, using Swing with third-party libraries like SwingX, JIDE, JGoodies, Flamingo or using application frameworks like Netbeans Platform or Eclipse RCP. Is there a supported/suggested way which weakens the pain normally associated with Java GUI development?

The answer is prefer swing, I think.
since 1.4 there are big progress on awt (sun do that because java fx need awt, fortunately)
since 1.5 big progress in thread managment (SwingWorker and concurrents things)
swing is excellent, responsive (what the problem with developper fault ? ), native l&f, and so on
there are excellent libraries, like swingx, trident, etc, and platform, like netbeans.
Of course it is a mature technology (a little old), but I know nothing else. It will be cobol of GUI development :-)

You won't find an objective answer to this question, only personal preferences and options.
SWT
My personal preference is SWT. I started using it, when Swing was to bad to be an option. SWT is "just" a layer on top of the native windowing APIs and thus applications written with SWT feel like natively written applications. Those can also be screwed up. No API will ever be safe from bad developers. The performance is as fast as it can get in my experience. If it is not, there is another way of implementing it, where it will be.
SWT's API is very low level which makes implementing basic stuff unexpectedly tedious, but fortunately most typical usecases can be solved with JFace, which improves the situation. And when you use the API for a while you'll accumulate your own util classes. You can become pretty fast in implementing SWT tools.
Since SWT gives you only the basics, you need MigLayout and Nebula widgets to survive. You might like Glazed Lists.
Qt Jambi
Actually I would have liked to include another option besides SWT and Swing for you: Qt Jambi. But Nokia gave up on this, and it is "maintained by an open source community" now. So I don't know about "not being obsolete in a few years".
Nevertheless I am excited by this ongoing discussion. Some people have written an SWT implementation using Qt Jambi as "native" API. They are trying to figure out how to contribute it. Having Qt as an option might enable your "single library which runs on all platforms" for SWT one day, though I wouldn't count on it anytime soon.
But for me your requirement of "a single library" is not such a big issue. Use maven for your builds, add a few lines of configuration and you'll forget about this very soon.
Swing
I can't really compare SWT to Swing, since my experience with Swing is limitted. As a user I don't like most Swing applications, but I did see some beatiful ones.
Nowadays the native look and feel of Swing apps got pretty good, but you won't fool a power-user. Also performance seems to be really good in new and well done Swing apps, but again, this is only from my limitted view as a user.
Obviously there are more 3rd party extensions for Swing than for SWT - just do a Google search. (But then again, if you endure the pain of learning Eclipse RCP you'll get an huge, interesting infrastructure as well. That's not talking about widgets though, that's stuff like EMF or RAP. I am no Eclipse RCP person - I never had enough patience for that...)
A really big advantage for Swing, if you like that stuff, is Matisse, the GUI builder of Netbeans. Qt has also a well done GUI builder by the way.
Summary
If you plan for long term, I don't see more options than SWT or Swing for GUI development in Java. Both are good enough to satisfy most needs if you spend enough time. But they are not perfect. You'll always envy people using other languages for their widgets, implementation speed, tooling, ... If you are not bound to Java, you might even prefer Flash or Qt.

Is Java the best language to develop cross-platform GUI applications? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
For "best" I intend that the code shouldn't need, or need very few, platform specific tweaks.

I strongly recommend Java for cross-platform GUI development. In particular, I recommend the GUI builder that comes with the Netbeans IDE. It's very simple and very powerful. You can point and click and drag and drop to create a GUI, and easily customize the actions which various buttons and other components take.
I much prefer Python as a language, but none of the free tools for GUI development come anywhere close to this, and the same thing seems to be true for the other languages I've used. (I should point out that QT has wonderful GUI developers for various languages such as C and Python, but it's only free when used on open source projects.)
EDIT: QT has recently been relicensed as LGPL, so you're free to use it in commercial applications. The Python bindings for this (PyQT) have not been re-licensed, but another project called PySide has been created to provide Python QT bindings.

I personally despise the whole concept of emulating the native GUI that is where the Java GUIs are rooted. Instead of being at home wherever you go, it makes you a tourist everywhere, often needing an interpreter. The Eclipse GWT is a better toolkit that makes much better use of local resources, but it still holds that people love to write Java code, and hate to use Java applications, think of it: which Java applications you love on your desktop?
Tk is just as ugly and limited on any operating system you choose to run it onto, and the same goes for Qt, in my opinion.
Mono would need a good try, as it is a way to answer the question "why Linux sucks", if you remember that old post bi Miguel de Icaza. Mono comes with a mature set of widgets and Apis and does not try to limit what you can do in order to give you portability.
Silverlight is close to portable and has a great interface definition language, but lacks access to the system, you have to split the application between a server and UI even on the same machine to overcome it.
Adobe AIR is a dog and local system acces is not easy.
If I am able to choose, I tend to avoid GUIs altogether and try to use a web server, even a local web server, and Json, JQuery and all that stuff. I found out that I can have many more choices and am more productive than with native widgets. This combines the strengths of the use of a real language server side and the wonderful disordered geniality of JavaScript in the GUI.

Yes: use Eclipse RCP. You can write not only cross-platform, but e.g. multilingual applications with it. SWT provides the native look-and-feel for multiple platforms and windowing systems.

So as I understand it, there is currently NO truly cross-platform high level language & GUI toolkit right now.
Java is cross-platform, GUIs in both SWT and Swing can look good, when you really try hard to tweak them pixel-precise and provide modifications to the look to supported platforms. There are currently some good GUI designers, but nothing as great as OpenStep 15 years ago.
QT is now LGPL'ed so long as you only link to it dynamically. Well but QT has its own set of problems and is a superset of C++. You have to compile against QT-hacked compiler, not the generic C++ one.
didn't try the wxWidgets, but from the looks of it, it can work, but is NOT high level toolkit at all!
There seems to be an option to write in C# and opensourced .NET and run it via Mono in other platforms than Windows... Didn't try, but it seems to me, that is just porting Microsoft on other platforms.
There is GNUstep, but for now it looks for me, like it is only developped by some opensource geek fans. It would be really interesting to see the OpenStep stack outside of the Mac OS X, but for now this looks to me as not viable.
Even Java, while it is self-contained, does not currently provide great GUI designer capabilities. I used the GUI designer tool once when starting to learn how to code with SWT, and now I find myself coding it by hand, which is really not bad, but it really should not be necessary. But that was few years ago, I will have to try again.
You can of course create your cross-platform application core and service code in one language (Java, or C/C++ if you want speed), creating something like a server or unix tool and just connecting to it from the GUI that you create on each desired platform using its own tools. The result is that the GUI is platform native, taking advantages of the features of the platform, and should be fairly simple to create for each desired platform. (Cocoa on Mac and .Net on windows provide rich features for the platform they are native to).
We will have to look into the robustness and matureness of such ideal solution. It should have good commercial and comunity backing and be fairly evolved right now, so as the future implementations of such tools will provide us with more than the mere LOWEST COMMON DENOMINATOR for all the supported platforms, but to leverege the cross-platform tools to include and adopt well-designed concepts and rich features native to the relevant platforms and distribute them cross-platform.
Only than can be cross-platform development truly viable and adoptable in great numbers.
Suggestions?

Java is certainly nice, but I've been doing just fine with Python and Qt via PyQt4 lately. I find that I get things done faster than I did in Swing or SWT, too.
So far, no platform-specific tweaks have been necessary, and Qt4 widgets look nice on different platforms. The Qt GUI builder is very nice, and using Python has enabled easy integration with some other cross-platform frameworks (notably VTK, scipy-cluster, and some SWIG-wrapped objects for interfacing with files output from a performance tool).
Note that Qt is not free unless you use it on open source projects.

As long as someone defines "platform independence" correctly, Java is the best.
Some people argue that C# is the best, but those people seem to misunderstand the term
"platform independence" ;)
Note: I refer to the fact that C# is ported to Linux/Unixes only as long as Microsoft and Novel keep up their treaty. The community itself would never be able to maintain such huge platform as .NET

These days there are many languages that allow you to create cross-platform GUI applications efficiently. Java, Python, Tcl/tk, C#...
I think you need to define the requirements of your application a bit more, for instance:
Will the UI be Web-based, or desktop-based?
Is the application going to be a large or a small?
Will it feature some sort of "extension" feature (e.g. plug-ins)?
Will it function over a network, and is it likely to be distributed/load balanced?
The list can go on forever, work out the defining points about your application, and start researching the language based on the whole.

I would also consider Mono as serious contender for platform independence and a good IDE tool.
Java's performance sucks on the desktop. Just check http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx

For native binaries, wxWidgets is a convenient solution.
I would tell you that is even better than Java for the user experience side. Even though you can make the presentation layer look pretty much the same for all platforms in Java, they all look like Java. On the other hand, wxWidgets make the user feel like a platform specific build (and it is, indeed), but you can use the same code to compile for several platforms (at least the major ones).

I would think that it depends on what kind of platforms you plan on targeting. Java will have the most platforms with a VM. However, if you just want to use Windows and Linux, you can use C# (using mono on linux).

Based on your definition, no. Even wit the newest graphical libraries you can expect to do a bunch of testing on different platforms.
Flash would probably be the best. Wide spread and better at looking the same across different platforms.

Java Developer looking for a 2nd'ary language to play with [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is best language to learn next to Java?
Criteria for this secondary language are:
High potential of being the "next big thing". e.g. If the market for Java open positions hypothetically dies/dwindles, what is the next programming language that will have a bigger market for open positions? Another way to frame this question is: If I own a small company that implements solutions in Java, what is the other language that I should use?
Can produce web applications.
Can produce desktop applications.
Easy and fun to learn.
Wide range of available libraries and frameworks (free or open source) that enhance and speed up your solutions.

Python almost meets all of them, but I don't know about being "the next big thing", but hey, Google uses it, and I think its popularity is raising.
It's a scripting language, btw.
I use it for web applications (using django), and you can definitely create desktop applications with it (although I haven't done that myself).
It is easy and fun! (although this is quite subjective, but it's tons easier and "funner" than Java)

For employability: Any of the .Net languages, probably C#. Then you're well set for most potential customers.
For stretching yourself: something functional (F# to cover .Net too?), or something Lisp, or Smalltalk - was once the next big thing but it probably never will be again, but still a language that changed signficantly my approach to programming in other languages.

If you are expert in java, you will probably really enjoy groovy.
It is backwards compatible with java and has a lot of the nice features of ruby and similar dynamic languages. It also has what is shaping up to be a nice rails-a-like in grails, and a good object-relational mapping framework in GORM.
What is really nice about it is you can mix and match groovy classes and java classes. So if you find yourself forgetting the groovy syntax, you can just drop into Java. And of course you can get at any Java library from it. At the same time you can benefit from groovy's really concise idioms for things like Beans properties.
(By the way it meets all your criteria listed above, too)

Learn a language that will probably not be the Next Big Thing™. Learning a new language usually means learning new concepts (unless you learn one that's very similar to another one you already know).
Learning new concepts has great advantages, no matter which language you program in, so it's a pretty good thing to do.
If you limit yourself to a language that's going to be the Next Big Thing™, then chances are that you'll find a lot of familiar concepts and only relatively few new ones (the IT world is conservative like that).
Learn something that looks interesting to you. Not only will you be able to learn faster, if it's interesting, but you'll also have more fun doing so!

How about Scala or JavaScript? Functional paradigms will stretch your thinking further and will be of benefit whether they are "the next big thing", or not.

Go for a different paradigm : functionnal, lisp, haskell, ocaml, erlang, scala, etc.

If you don't have any religious issues with Microsoft, I would argue for C#.
The only downside I can see is that it's not cross-platform. Otherwise it fits your requirements as far as I can see

Your criteria fairly closely matches Python and Ruby, they both have a growing market base in Web development, and are fully capable of producing desktop applications as well. Whilst they are fairly closely matched, Python has a slightly larger library of re-usable code modules, whilst Ruby's strength leans more to it's well-established frameworks.
As a side-note, You should ensure that you don't stop at 2 languages. Start learning a second one, then pick up a third and even fourth as you progress. Learning new programming languages becomes a more trivial task as the general learning curve evens out.

I must second Gilles here; to learn a different paradigm is very rewarding, and functional programming is [not unlikely to be] the Next Thing.
Erlang is great both in flexibility, ease of use (once you grasp the basic ideas) and - the best of all - it it very well suited for the high parallelism of future and current hardware. It also covers all your five criteria, though it might be more of a "server" language than a "desktop" language.
If you are interested, I suggest the book Programming Erlang by Joe Armstrong.

Personally, I'd go with Ruby and focus on running your Ruby scripts under JRuby. this way you get the expressiveness of Ruby with the JVM running your code. I've seen Rails and Merb running under Glassfish. Might seem odd, but you get all the nice instrumentation of Glassfish with your Ruby code. Things like JMX, RMI, etc. work well with JRuby.

Squeak by Example