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
I would like to hear some opinions on hand coding your GUIs as one typically do when using Java or Qt with C++, vs using a gui-designer tool? Examples of GUI designer tools would be MFC GUI-designer, Qt designer, Interface Builder (Apple).
I used to be a fan of hand coding but from recent experience I have switched. The problem I have seen with hand coding is that it is fairly quick and flexible to write the GUIs but once you need to make a change to a GUI written a long time ago it can be very difficult. Finding the right element in big panel can be difficult.
The second problem is that it makes it far too easy to add a lot of logic in the GUI creation and layout code. I have often had to take over maintenance of GUI code which is really hard to reuse because its behavior is mixed with its appearance and mixing layout and behavior often makes the class very large and difficult to understand.
Using a GUI designer tool force a much clearer separation between appearance and logic in my view.
I would always hand-code the GUI design where there is no standard (or de-facto standard) GUI markup language (as with Java). The reason for this is that I have found that usin a GUI builder design tool will tie you in to using a particular IDE. Over time, the best IDE for GUI design and/or writing code will change and each developer should be free to choose whichever IDE they feel most comfortable with.
Where I work at the moment, we have a lot of legacy GUIs which were written using Netbeans Matisse GUI builder (against my advice at the time :-). These are now almost unmaintainable because all of the developers prefer either IntelliJ IDEA or Eclipse as their IDE. It is not realistsic or workable to have developers fire up Netbeans just to modify GUI layout (people don't keep the Netbeans project definitions in sync etc).
Another point is that the total time writing out GUI layout code is probably only 5% of the total development effort of a given project. Even if it takes you twice as long to write the code yourself, this doesn't translate as much of an overhead in the grand scheme of things. And it's a small price to pay for long-term maintainability.
As long as you are clear about separating out GUI layout logic from business logic, I don't believe anything suffers as a result. No-one here uses GUI builders any more!
I do it by hand, it's a lot easier to shuffle things around and re-use panels inside the application (some panels can appear in several places).
Using a designer works when you're in a team the artists are supposed to do the GUI.
Finding the right element in big panel can be difficult.
?? I've never seen that.
I feel strongly that you should use an interface builder instead of hand-coding a GUI. As in the question mentioned it's a much cleaner separation and once something has to be edited it's much easier.
The Qt Designer got this feature to create a class out of a .ui file1), but I think that not using this feature is the best way, as this creates just more coded that shouldn't exist at all. The speed issue of creating the window from a .ui-file is negligible because the window has to be loaded only once.
This is PyQt, but something similar is possible in C++:
class SelectDateDialog(QDialog):
def __init__(self):
QDialog.__init__(self)
uic.loadUi("resources/SelectDate.ui", self)
Essentially this has the same effect as including all your UI-code into the __init__() method, but the UI is almost completely separated from the code.
1).ui files are XML files that describe a user interface
Funny enough it has gone the other way round for me. Talking from Winforms perspective, the code generated by the designer is quite noisy, with maybe a quarter or half of all the property settings really necessary. Making pretty big controls is also more of a temptation when working with a designer. Changing some hierarchy of controls in the Winforms designer is quite a nightmare in my eyes.
In my last project I have created additional APIs to set up splitters in forms, dockmanagers, menus, toolbars etc. in a declarative fashion. These are such that they will further enforce separation of concerns.
I also try to rely much more on auto-layout features which admittedly are a lot nicer in WPF but can also go some way in Windows Forms.
I would strongly advice you to use Interface Builder on OS X. Doing it by hand is fine if you want to learn, but you're going to save yourself a lot of headaches by using it on actual projects. It really is quite powerful.
As for Java and C++, it depends on what you're doing and on what platforms. For simple applications you can get away with never seeing the UI code. However, for complicated applications and rich clients, you typically have to do some of the code by hand.
If you are designing a business application with lots of entry forms and tabular data, writing code for your UI is both faster and more maintainable than using an UI designer. In those kinds of applications, there almost never need to precisely place one element at predefined place on screen, while on the other hand, there is a lots of repetition and design conventions that can simply be extracted into separate methods.
Take for example an Eclipse or OpenOffice preferences dialog. There are a bunch of categories and a bunch of different options to set for each. If you have to make something of that size, hand designing each screen is a mundane task. Much better approach is to write code which will generate UI elements on-the-fly, from provided domain data, according to some conventions and defaults.
I don't see how using a designer facilitates better separation, nor how that perceived separation would help with anything, given that you already keep your business logic out of the UI.
And, finally, if you're using Java, be sure to check out MigLayout. It works with Swing and SWT, its' syntax is very concise and clear, and it has a debug mode that's unbelievably useful.
It depends on the situation, really. I think both have their place, and I usually use a hybrid approach.
There are always some things that the GUI builder can't do (for example setting the color to a UIColor constant in Interface Builder). On the other hand, most of UI work is pretty mundane (for example adding static labels).
I prefer to do the mundane stuff in the GUI builder, and the more interesting stuff in code.
Also, I occasionally find myself editing the XML produced by the GUI builder (Interface Builder and glade in my case) by hand.
I tend to think the right answer depends on the culture of the target platform. On OS X, Interface Builder is such an integral part of the tool chain that it's difficult to avoid it.
In Java (awt or swing), the reverse is really true. There is no toolchain support for this.
Really, the way you can tell, is the way the tools produce their outputs. Interface Builder produces .nib format files which are specific to the way Cocoa puts controls on the screen. It understands what is essentially an interface markup format. Java has no such similar concept. Everything is a compiled class, and therefor its much more difficult to get convenient results.
GTK+, when combined with glade, seems to strike a reasonable balance between the two.
Nothing prevents from mixing the two approaches. I often make the main layout of a form in a GUI designer (because it's quick and you see what you're doing), and put there one or more panels which are then populated with code. This is especially useful when the GUI must adapt to specific situations - for instance, if the GUI must change according to what hardware is connected.
In any case, the most important thing is indeed to keep GUI and application logic separate.
My view on this:
1. Hand-coded GUI code is much more reusable
2. Layout issues are simpler with designers
Hand coding can be good if you want some non-standard features included in you UI. You have more flexibility, but you will need to invest more time to create a good interface, because Java/C++ are language not mean to target UI design.
On the plus if you have a revision control you can look at the history of changes, something that can't be done with a designed that uses a binary format, or an xml format which is not RCS friendly.
Today most of the available tools to visually design an UI have missing some features. They are not flexible enough, some features can only be attained coding them. Also in some cases the generated code is not really human friendly, and if you modify by hand you may no longer be able to continue using the designer.
But the designed can be really a time saver if the design is simple, and we can hope designers will be improved in the future, but I will not hold by breadth.
My conclusion is if you need flexibility today you will have to code by hand the interface, if you want something simple and fast then designer is the best choice.
Perhaps in the future the designers will be more powerful, or perhaps there will be new languages specialized in the UI design which will be more suitable for use in C++/Java, something like XUL or XAML.
Related
Recently my ad-visor asked me to see if I could build a simulation framework which can be used for implementing + testing some new distributed computation paradigms.
I looked into some open source frameworks - and found that there are quite a few simulation frameworks available and most of them are based on component oriented software design principles. I looked up this topic on the internet and found that this was sort of the thing in the late 90s and early 00s but has now kind of faded away from the high point. Does anyone has some good books to suggest on what exactly it is? Now having some exposure to Java - I also noticed that I might have already have used some of component oriented software concepts (e.x - I have created simple wysiwyg document editors using Swing's text apis, so I am aware of concepts such as - Views, StyleContext, StyleDocument etc. etc.) - though I explicitly didn't take notice of the techniques.
Any pointers to beginner books/tutorials will be greatly appreciated. I just want to create some small app to see if any of this at all makes any sense.
To build a flexible simulation framework you may want to look at a functional programming language, such as Scala, as by design it works better for this since you can then either design a DSL (Domain Specific Language) to help abstract out writing the simulators, so others can focus on their research instead.
For an example of someone wanting to use Scala for a simulator you can look at Howto design a clock driven multi-agent simulation.
For an interesting page with a .NET reference that compares OOP with Component Oriented programming you can look at this blog: http://www.elenkist.com/bushido_burrito/blog/?p=11.
Before you get too wrapped around a language or technology, design out what you want to do, how you want the user to interact with your framework, then decide on the best approach, rather than trying to pick an approach and forcing your solution to work within those constraints.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I need to have an at-home project now that I'm working on Python/Django at work. I'd like to learn something new, so I was thinking of checking out Java.
What's the most well respected web framework for deploying Java web apps?
The only reason I'm not checking out ruby on rails is because of how similar the ORM and other parts are to Django.
Alternatively, does anyone think I should take a look at seaside/smalltalk? Can anyone explain why I should?
Haskell is something I'll consider if anyone can make a good argument for it. I'd need a web framework and database access library to go along with it though.
I'd consider factor/forth if I wasn't so accustomed to the stack paradigm via x86/asm. I'd be willing to hear any counter-arguments to this as well.
See also: http://www.reddit.com/r/programming/comments/9v3uf/asm_c_python_perl_lisp_scheme_programmer_looking/
With that range of skills, why don't you learn something more outside your comfort zone, like carpentry or painting, or any of hundreds of other skills that have little to do with your field.
At some point, all languages are the same and you'll get scant benefit from learning another.
Whereas, with something totally different, you will become a much more well-rounded individual. I, for one, like painting and golf, even though I'm not that good at either of them - when I asked my golf instructor what my handicap was, he said it was an inability to hit the ball straight :-)
I find that I enjoy doing stuff I'm not accustomed to since it's a genuinely new experience. Learning another computer skill is a easy thing to do after a while and hence the pleasure from doing it is reduced.
Don't get me wrong, I like to keep up with developments in the field but, for the most part, the brand new technologies give nothing to my career since most work I do is on stable technologies. You may be in a different situation.
Haskell is pretty popular these days as a mind-bender, though it may not hurt as much for you if you already know Lisp and Scheme. It's purely functional, so there are no side effects to anything. You have to use monads to print text and do other things that require a certain order. It's also completely lazily evaluated, so you can make infinite lists in Haskell and not have to worry about memory consumption.
The Haskell Platform may not be fully complete, but is intended to be a portable set of libraries for Haskell. It's list of packages includes some for CGI handling and (X)HTML generation.
Sounds like you're into web programming, so smalltalk/seaside is a great one. IMO everyone should learn smalltalk even if they never use it, and seaside is a really different web framework than what you are used to. Django, fer instance, is all about REST, while the seaside philosophy basically says "to hell with REST."
And if you've never coded in an image based environment there's just something about it that seems... natural, magical even. Lots of IDE functionality that originated in smalltalk have been implemented in file based language IDE's, but it always feels like an unnatural grafting, where those same features feel as if they simply belong there in smalltalk.
Check out Pharo. Give it enough time to get used to the fact that there's no menu bar and see if it doesn't grab you.
I do suggest Java. When I was looking for a job, I noticed lots of openings for Java developers, so there's a lot of it out there, and you might someday have a chance to use your Java skills.
And then you should try out Scala. Scala is a sort of Python-ish language that uses functional programming to make very scalable programs. Unlike Python, in Scala you do need to declare types of things. Scala runs on the Java Virtual Machine so it can be used in Java shops.
http://www.scala-lang.org/
It's possible I'm just giving you this answer because these are the next two languages I intend to learn, myself.
You probably should also spend a little time playing around with Javascript. Javascript was sort of intended to be a "stealth Lisp" and I imagine you would pick it right up.
http://www.crockford.com/javascript/javascript.html
http://bc.tech.coop/blog/030920.html
And heck, have some fun with it. Write a game or something!
From your list I'd say you are due for a completely object oriented language.
You could check out Ruby, but I'd recommend JavaScript since it offers a lot of interesting things you probably wouldn't expect, like support for closures, higher-order functions and prototypical inheritance - plus it's kinda fun and becoming very popular.
I'd need a web framework and database access library to go along with it though.
If all your programming is based on web frameworks and SQL databases, you will only be solving the same problems with different syntax if you switch languages.
Build something using a different data model - Prolog, Conceptual Graphs, RDF, Linda/JavaSpaces, XQuery, HDF5, ASN.1, or a different network model - XMPP pub-sub, SNMP, a zero-config mesh or a swarm of ZigBee enabled Arduinos.
Maybe look at languages like Oz, Io or Erlang/OTP, which are distributed rather than primarily monolithic like the ones you mention.
What about the Java Spring framework?
http://www.springsource.org/
Or maybe NHibernate?
http://en.wikipedia.org/wiki/NHibernate
At the end of the day its up to you. As I only listed two out of many. When I am programming a static language professonally... I try to learn a dynamic or scripting language. And vice versa.
Also, I try to learn something totally different or outside my realm... maybe even Powershell or Korn shell or ActionScript.
What's the most well respected web framework for deploying Java web apps?
There is no single web framework more respected than others. Struts2, Spring MVC, Stripes or Wicket (which is event based) are all good candidates (I personally like Stripes). But you'll need a bit more for the persistence (Hibernate or JPA) and for the glue (Spring).
Grails (Groovy on Rails) is another good option.
Alternatively, does anyone think I should take a look at seaside/smalltalk? Can anyone explain why I should?
Well, I guess that learning Smalltalk can't hurt but I don't see a good reason to choose Smalltalk over a moderner language like Java. Regarding tooling, I don't know anything in this field except VisualAge for Smalltalk but, personally, I'd really stay far away from it.
Haskell is something I'll consider if anyone can make a good argument for it. [...]
Looks like I'm not the right guy for that.
I'd consider factor/forth if I wasn't so accustomed to the stack paradigm via x86/asm. I'd be willing to hear any counter-arguments to this as well.
Same as above.
I would have suggested mastering Lisp (in some relevant dialect) so even if you have Lisp and Scheme on your resume, it might be worthwhile to REALLY learn deeply. See http://www.paulgraham.com/avg.html for reasons why.
Otherwise Prolog might interest you. It is related to SQL but for programming instead of communicating with an organised set of data tables.
If you want to target web technologies I only have experience with Java. Here the newest Java Server Faces (JSF) allow for using Ajax to update pages, and Google Web Toolkit allow for very rich component based web pages. These might be juicy enough to interest you enough to learn enough Java to find them fun :)
I don’t see C# and the .NET platform on your list. And I am surprised no one mentioned it yet.
I have worked in C# for 5 years. I have looked at some Java code but I have never coded in it. I believe that Java is somewhat similar to C# enough so that if you become proficient in one I think you could pick up the other is a matter of a few days.
One idea might be to create your own language / compiler. The one I would like to create (or see created) would be an Assembly Language level compiler with an object oriented syntax that would be very much like Python… but make it typed language. You could start with the basic raw binary types db, dw, dd, and then add on to these … The functions and methods could have assembly language freely mixed in the high-level code. Now, that would be a fun project, I think ?
Definitely try Haskell or Smalltalk or Forth.
I would say Smalltalk would be most useful while Forth would get you away from the x86 asm and C bullshit. There's more than one way to code close-to-the-hardware stuff.
Why don't you try OCaml? And if you ever happen (sadly) to return to .NET world - you will have knowledge of F# in your baggage.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm working on getting an Introduction to Groovy presentation ready for my local Java User's Group and I've pretty much got it together. What I'd like to see is what you all think I just have to cover.
Remember, this is an introductory presentation. Most of the people are experienced Java developers, but I'm pretty sure they have little to no Groovy knowledge. I won't poison the well by mentioning what I've already got down to cover as I want to see what the community has to offer.
What are the best things I can cover (in a 1 hour time frame) that will help me effectively communicate to these Java developers how useful Groovy could be to them?
p.s. I'll share my presentation here later for anyone interested.
as promised now that my presentation has been presented here it is
I don't know anything about groovy so in a sense I've qualified to answer this...
I would want you to:
Tell me why I would want to use Scripting (in general) as opposed to Java-- what does it let me do quicker (as in development time), what does it make more readable. Give tantalising examples of ways I can use chunks of scripting in my mostly Java app. You want to make this relevant to Java devs moreso than tech-junkies.
With that out of the way, why Groovy? Why not Ruby, Python or whatever (which are all runnable on the JVM).
Don't show me syntax that Java can already do (if statements, loops etc) or if you do make it quick. It's as boring as hell to watch someone walk through language syntax 101 for 20min.
For syntax that has a comparible feature in Java maybe show them side by side quickly.
For syntax that is not in Java (closures etc) you can talk to them in a bit more detail.
Remember those examples from the first point. Show me one, fully working (or at least looking like it is).
At the end have question time. That is crazy important, and with that comes a burden on you to be a psuedo-guru :P.
I'm not sure about how the Java6 scripting support works but I'm fairly sure it can be made secure. I remember something about defining the API the script can use before it's run.
If this is the case then an example you could show would be some thick-client application (e.g. a music player) where users can write their own scripts with an API you provide them in Groovy which allows them to script their app in interesting and secure ways (e.g. creating custom columns in the playlist)
I'd go for:
Closures
Duck typing
Builders (XML builder and slurper)
GStrings
Grails
I'd mention the following things in addition to what has already been stated:
GDK - extensions/additions to existing JDK classes
Interaction between Groovy and Java code (basically a non-issue)
Compiling Groovy code to Java .class files
XML parsing and mechanisms for accessing document content
One thing I like doing with Groovy is implementing an interface defined in Java as a map from method names to closures. It's a cool thing you can do with Groovy, but probably well beyond an introductory presentation though.
Include an example of how making Java code more groovy takes away soooo much code. Wait for them to pick their jaws up off of the floor before continuing. Scott Davis has a simple example at the beginning of Groovy Recipes that takes 35 lines of Java or 3 lines of Groovy.
You should definitely show them how to create a quick Grails application. Two domain classes that are related. Build a basic CRUD app. Explain that tables are being created behind the scenes using GORM(Hibernate). Then explain that you can create a war file and deploy it as you would any other Java war file. You can also add Grails/Groovy to an existing Java/JSP project so it doesn't require a huge commitment or paradigm change.
Groovy/Grails is simply Ruby/Rails for Java people. I'd cover the plugins for Netbeans/Eclipse too. Groovy/Grails are just now getting full support in the major IDE's.
Finally, if you can find a good diagram that shows how Grails is built on top of Spring, Hibernate, Quartz, Sitemesh and Groovy, I think people will understand that there is a treasure chest waiting to be unlocked.