I'm starting a fairly complex Swing application that heavily graphics-oriented with about 1000 separate jpegs, 30+ different forms, and timers keeping track of the rate of user-interactions throughout.
My question is from a practical programming perspective, after I've already written a storyboard for the entire project and got it approved by the client, where's the best place (code-wise) to begin programming this massive project and in what order should I program the elements?
(Example Answer: first begin coding the declare and init statements of all the necessary pieces, then write skeleton versions of all the methods, then deal with swing design and layout manager (gridbag), and then deal with Events and Listeners)
Thanks for the advice everyone, oh and btw I really love StackOverflow!
You're describing a "waterfall" development approach - completing some level of the program first, then completing the next level etc. It's indeed one possible approach, but many people find it so called tracer bullet approach better; first make something functional, then learn from it, adjust what's needed and proceed. It's especially useful if you're working with a client, because by showing prototypes you can get feedback and avoid misunderstandings.
I'd pick up a book on TDD and even if you're not going to write automated tests, it will be full of good advice on how to approach your project.
After that I'd pick a single piece of functionality that slices all the way through your application vertically and implement that end-to-end. This should allow you to get any infrastructure/frameworks in place and spot any gotcha's that may get thrown up out of your design.
If your client has the time free, show them each piece of functionality along the way and make sure that every piece you do adds some value to the product.
--EDIT
In addition I'd take a look at using a graphical designer for your screens instead of using the GridBagLayout. That will just waste time and can quickly become a maintainence nightmare when changing screens. I personally prefer the ones that work in a resource file type way, where the screen is essentially "compiled" and you just load it into your code
I prefer writing the UI so, that first I write (using TDD) the backend classes which implement the behaviour of the UI, without any dependencies to the presentation of the UI (i.e. without Swing or any other UI library). After that I write a thin presentation layer with an UI library, where all the event handlers etc. delegate to the UI backend (they should be just one-liners without any logic). The benefit of this is that you can easily write tests for the UI, which in turn makes it easier to change and maintain the UI. See the links at http://martinfowler.com/eaaDev/ModelViewPresenter.html for more details.
At a higher level, first implement the features which will produce the most value to the users. Try to get something to show as early as possible, so that you can get feedback from the users and improve any deficiencies in the UI. You can fake most of the background services (for example the database and business rules), so that the UI can be used, even though it does not yet really do anything.
I think mad-j has the words of wisdom.
Don't concentrate on the 'all'... identify sections/components/modules and deliver those. Then move on to the next and the next. This is called Iterative and Incremental Development (a response to the weaknesses of the waterfall model)!
This will also allow you to create tools and frameworks which should make your development easier and faster as you move along.
This will allow you to show your clients functional parts early. But a word of advice! Your client will more than likely keep changing its requirements, changing the GUI, changing its mind, etc. I've seen entire projects fail due to these continuous changes. It is out of the scope of this question to mention any more on this, but please be aware that it more than likely will happen and be prepared to deal with it!
If you and the client have functional parts, they can be tested immediately rather than testing one huge system.
By completing functional parts iteratively will probably allow you to work at every layer, on most API's using most tools and technologies. The advantage of this is that it will allow you to identify the complexities early. It is those complex areas that render this following statement true:
The first 90% of the code accounts for
the first 90% of the development time.
The remaining 10% of the code accounts
for the other 90% of the development
time. --Tom Cargil
Identifying, acknowledging and understanding those complex areas will allow you to manage your risks and alter your efforts and resources more effectively.
Good Luck,
Jeach!
As mentioned by MrWiggles, you may want to look into using a UI builder.
If you're looking at writing many forms, and it looks like the form data can match nicely to some javabeans, you may want to think about creating some framework panels first.
If you can create some simple base classes that take care of the wiring (syncing the fields to the beans and vice-versa), it'll save you a lot of work.
You may even want to set up some panels that will "auto create" fields based on beans. Just pass in a bean and the panel creates itself. The trick there is specifying layout for the fields, and dealing with fields that have fixed values, validation, etc. (Fixed values can be dealt with using javabean property editors - see http://javadude.com/articles/propedit/index.html.
If you're set on using Swing (eclipse RCP is nice, btw), you might want to look at the Swing Application Framework (https://appframework.dev.java.net/). If not using it directly, it may give you some ideas on how to set up bindings.
Hope this helps a bit
Are you really sure of Swing? Eclipse RCP is much better and flexible starting from EMF and going on
Anyway with Swing, first I'll prepare an XSLT template of all: common code routine and other common pieces of common to bring then them in abstract and interface classes, ORM patterns you use.
Then I'll design a common UI scheme, this "xslize" too.
After all with ANT XSLT processor I'll prepare a complete build procedure upon your specs.
P.S.
I made similar projects for simple web and swing cruds just before 2001, and if you use some peculiar UI designer you can also nest or write with xslt every specs without putting dirty code in your ui raw concepts, so when I make/add remove features on all or singular piece of code, 30 seconds maximum for full rebuild of ALL, of course you must "XSLIZE" all using also many xslt overrider/import.
Related
Suppose I have to develop a Desktop Application using Java SE. I have finished writing User requirements document. In this document, I mentionned the functionnalities of my futur application. I analysed the needs of the user and established What the ideal application has to perform.
Now, I have to conceive the architecture of the application and ddetailled conception of the app. This is what I don't know how to do ?
I have an idea, which is as follow : elaborate a use case diagram, then for every use case, make an sequence diagram finally produce a class diagram from which I can generate the code.
Is this correct ? How about using a database management system at which level I add the use of DBMS ? from the first uml diagramme ?
please any help is a welcome.
Well you know the functions you will implement and you know the requirements. While at this point you should know or infer some database requirements you don't have the whole picture yet. If you want to do an iterative software development you can start with whatever you feel you got more to progress with, then go back to your other tasks and work in increments. Because you are doing an iterative process you will be erasing bits here and there, polishing your work as you go.
To work sequentially, you'd finish all the analysis documentation before doing design, and that before touching code. Initial databases can be generated from java classes (beans), so that's when that comes in.
Under your chosen methodology the wiki link you provided lists what it is expected to be done in order. For the part of high level design, which you claim to have problems with, you'll want the appropriate UML diagrams, use components for modules/software architecture.
Because it is high level design keep it high level, don't delve in details. eg for a videogame: Graphics, Audio, Network, etc, and how they will interact (Interfaces), don't define anything smaller, no classes, no methods, main packages/libraries can be done. For hardware architecture you may use a deployment diagram I guess, have each cube represent the hardware of the boxes that will run your code, you aren't prepared for deployment but you can make changes to your initial proposal next iteration if you need.
Database design is at the end, but the wiki specifically tells you to only define tables, don't define columns yet. You will define that in the low level detail phase.
I have just been asked by my company to rewrite a largish (50,000 single lines of code) Java application (a web app using JSP and servlets) in Clojure. Has anyone else got tips as to what I should watch out for?
Please bear in mind that I know both Java AND Clojure quite well.
Update
I did the rewrite and it went into production. It's quite strange as the rewrite ended up going so fast that it was done in about 6 weeks. Because a lot of functionality wasn't needed still it ended up more like 3000 lines of Clojure.
I hear they are happy with the system and its doing exactly what they wanted. The only downside is that the guy maintaining the system had to learn Clojure from scratch, and he was dragged into it kicking and screaming. I did get a call from him the other day saying he loved Lisp now though.. funny :)
Also, I should give a good mention to Vaadin. Using Vaadin probably accounted for as much of the time saved and shortness of the code as Clojure did.. Vaadin is still the top web framework I have ever used, although now I'm learning ClojureScript in anger! (Note that both Vaadin and ClojureScript use Google's GUI frameworks underneath the hood.)
The biggest "translational issue" will probably be going from a Java / OOP methodology to a Clojure / functional programming paradigm.
In particular, instead of having mutable state within objects, the "Clojure way" is to clearly separate out mutable state and develop pure (side-effect free) functions. You probably know all this already :-)
Anyway, this philosophy tends to lead towards something of a "bottom up" development style where you focus the initial efforts on building the right set of tools to solve your problem, then finally plug them together at the end. This might look something like this
Identify key data structures and transform them to immutable Clojure map or record definitions. Don't be afraid to nest lots of immutable maps - they are very efficient thanks to Clojure's persistent data structures. Worth watching this video to learn more.
Develop small libraries of pure, business logic oriented functions that operate on these immutable structures (e.g. "add an item to shopping cart"). You don't need to do all of these at once since it is easy to add more later, but it helps to do a few early on to facilitate testing and prove that your data structures are working..... either way at this point you can actually start writing useful stuff interactively at the REPL
Separately develop data access routines that can persist these structures to/from the database or network or legacy Java code as needed. The reason to keep this very separate is that you don't want persistence logic tied up with your "business logic" functions. You might want to look at ClojureQL for this, though it's also pretty easy to wrap any Java persistence code that you like.
Write unit tests (e.g. with clojure.test) that cover all the above. This is especially important in a dynamic language like Clojure since a) you don't have as much of a safety net from static type checking and b) it helps to be sure that your lower level constructs are working well before you build too much on top of them
Decide how you want to use Clojure's reference types (vars, refs, agents and atoms) to manage each part mutable application-level state. They all work in a similar way but have different transactional/concurrency semantics depending on what you are trying to do. Refs are probably going to be your default choice - they allow you to implement "normal" STM transactional behaviour by wrapping any code in a (dosync ...) block.
Select the right overall web framework - Clojure has quite a few already but I'd strongly recommend Ring - see this excellent video "One Ring To Bind Them" plus either Fleet or Enlive or Hiccup depending on your templating philosophy. Then use this to write your presentation layer (with functions like "translate this shopping cart into an appropriate HTML fragment")
Finally, write your application using the above tools. If you've done the above steps properly, then this will actually be the easy bit because you will be able to build the entire application by appropriate composition of the various components with very little boilerplate.
This is roughly the sequence that I would attack the problem since it broadly represents the order of dependencies in your code, and hence is suitable for a "bottom up" development effort. Though of course in good agile / iterative style you'd probably find yourself pushing forward early to a demonstrable end product and then jumping back to earlier steps quite frequently to extend functionality or refactor as needed.
p.s. If you do follow the above approach, I'd be fascinated to hear how many lines of Clojure it takes to match the functionality of 50,000 lines of Java
Update: Since this post was originally written a couple of extra tools/libraries have emerged that are in the "must check out" category:
Noir - web framework that builds on top of Ring.
Korma - a very nice DSL for accessing SQL databases.
What aspects of Java does your current project include? Logging, Database transactions, Declarative transactions/EJB, web layer (you mentioned JSP, servlets) etc. I have noticed the Clojure eco-system has various micro-frameworks and libraries with a goal to do one task, and do it well. I'd suggest evaluate libraries based on your need (and whether it would scale in large projects) and make an informed decision. (Disclaimer: I am the author of bitumenframework) Another thing to note is the build process - if you need a complex setup (dev, testing, staging, prod) you may have to split the project into modules and have the build process scripted for ease.
I found the most difficult part was thinking about the database. Do some tests to find the right tools you want to use there.
I have to make some animated design with lots of pretty effects and color gradients in a SWT compliant way ...
I assume what I try to mean is not clear as water so I'll try to explain more...
I have an RCP application in which I need to have a special page whose content is fed by a class that sends it either beans or strings (or postcards or whatever, it can have to get almost anything) and has to make a nice presentation of all that it gets by building artistical representation of it and animating the whole.
The artistic transformation here is not the problem (I'll handle it and let all freedom to my artistic sick mind) but the problem is to find any framework or plugin that is able to build pretty animations and all the stuff in a SWT shell...
You can use Timing Framework or Trident. Both of them based on the notion of changing bean property values, which would work for SWT or Swing.
You'd have to read about them to see which one you like more. For simple effects Trident looks easier, but it should be your personal choice.
I'm not sure whether this could help or not
http://www.eclipse.org/nebula/widgets/stw/stw.php
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 9 years ago.
Improve this question
What mechanism do you prefer for building a GUI: from scratch or using GUI-building software?
If the question is about GUI development using Swing then IMO it is best to code everything manually without a WYSIWIG tool.
In order for a manual UI design/coding to be efficient a really good layout manager should be used. MigLayout is one of such layout managers. Since I've started using it I have never looked back at WYSIWIG tools -- a sheet of paper, a pencil, MigLayout and you get a full control over your design and code.
Also tools like Balsamiq simplify making GUI mock ups for quick prototyping if the paper and pencil approach is not suitable.
My personal opinion is never use visual editors. Until there is a single standard for GUI-building in Java you will find yourself tied to an IDE. The best IDE for building Java GUI has switched around quite a bit in the last 10 years (I wonder how many projects were hit by a massive maintenance overhead from switching away from JBuilder for example).
For most applications, the actual layout of GUI code is probably something like 5-10% of the total amount of time you are likely to spend writing the app as a whole. Therefore even halving this by using a designer is not really saving you very much in the grand scheme of things.
Taking this together with the lack of flexibility and more complicated maintenance, it's almost always better just to write the GUI by hand.
I actually enjoy building GUIs with the NetBeans GUI Builder; the thing is, it is fairly customizable - it allows you to change the code used for auto-generation and the auto-generated code [no pun intended] (which is necessary for custom components), it also allows "easy" event-handling and binding. And NetBeans GUI Builder is not restricted to GroupLayout but rather allows you to choose which LayoutManager to use (a somewhat hidden setting in the form's properties dialog).
But it is not always the best choice; as others already said: MiG Layout is a good choice when you need to have full control of your application, knowing every single JLabel, every JButton etc.
I must confess I prefer Netbeans' GUI builder for the ease of use and WYSIWYG view.
But I also think that it does not even matter if you have created the GUI-Code by hand or with a GUI-Designer; adding Controls / custom Components dynamically works with both, doing this and that works with both etc.. The only thing that matters is that it works.
(From my point of view I do not see a point in coding a GUI manually if it can be done faster with a GUI-Builder, as I do not see why one should bother coding it by hand without some kind of benefit)
I use GUI builders to rapidly prototype designs and stuff like that. But when it comes down to building the actual production GUI, I code it from scratch. I'm not morally opposed to GUI builders, but I prefer the greater control over my code I get from writing it by hand.
Like any code generator tool, IMHO, you shouldn't use a GUI builder until you at least understand the concept - in this case, the Swing layout managers are particularly tricky.
If you give me the choice between NetBeans and by-Hand I'd definitely choose by-Hand. I was never really convinced by the NetBeans GUI builder's approach. At least the last time I used it, it relied on some proprietary sidecar files...
Look at Visual Editor for for Eclipse
You will still want to understand what the editor is doing for you.
You need to know how Swing works to be able to make things work properly. Nothing like building by hand to learn that :)
THEN the Netbeans GUI builder is rather nice.
Edit: I would strongly recommend going through the Java Tutorial Swing Trail - http://java.sun.com/docs/books/tutorial/ui/index.html
Both - use a WYSIWYG editor to get the ball rolling, but at the end of the day you'll need to manipulate your controls and in some cases create them programmatically at run time. Eclipse has a variety of free editors as plugins. Go to eclipse.org and look through the plugins listing.
Depends on your requirements. Some GUI building software work really well with simple applications, however, if your client requires many custom components the third party GUI builders may not work.
Also, it depends on the amount of forms and the complexity of them. If you need to build a form for each table in the database, for example, a third party GUI builder may be faster and cheaper.
In my experience, it really varies from project to project.
If you want a complex gui, then use something like netbeans to build it and create all of the events. If you're looking for a fairly simplistic gui, then building one by hand is still an option.
My company uses Netbeans for GUIs and eclipse for the regular programming.
We have looked but we haven't found any other (free or at least cheap) tool that does GUIs as good as NetBeans.
I used to write them from scratch with a plain text editor...
That depends what the reasons you're making the UI for,
I found that there are two reasons to make UI:
First is for clients, in these cases you want to UI to be polished and to handle really well in projects like this the core or essence of the project is the UI itself.In these cases it's usually the best to hand-craft the code for your UI because it's probably non-trivial code.
Second reason is usually quick & dirty UI where the core of the program is something else and the UI is created usually for Control aspects on your main application and you are the main client. In these cases the best thing to do is make the UI as quickly as possible as you don't want to "waste" time working on it and its more legitimate to use WYSIWYG editors.
I always find a GUI builder to be a good idea to begin with and then I end up in a situation where I am wasting my time fixing things to my own ways rather than that of the IDE and making them actually suit. And don't get me started on the messy code that GUI builders generate! Hence, it's often more efficient to build from scratch; at least for me...
I prefer hand coding the GUI myself so I can have complete control. For complex layouts I will use JGoodies Form Layout. Their syntax for specifying the layout makes it easy to draw the GUI on paper then transfer this to code.
I tried the Netbeans GUI builder and was impressed by how easy it was to use. Then I looked at the code it generated using GroupLayout and decided that by going that way you were basically locking yourself into Netbeans which was something I did not want to do.
I started by coding it manually using Swing. Now I use WYSIWYG editors, but I think it's important to know what's behind the editor. Also you might need to update the code manually, WYSIWYG editors often can't do exactly what you want.
Having created Java GUI's extensively, I can assure you the process is quite often painful. I'm well aware that Java's strength does not lie in it's GUI, but I'm surprised that a decent free interface builder tool hasn't been released.
Sometimes I'll use Eclipse's Visual Builder tool for quick and dirty mock-ups. It's code generation is a bit scary IMHO. I believe Netbean's Visual Editor is the best available at the moment (for free anyway); however, I find myself hand rolling GUI code for consistent cross-platform layouts. If your disapointed with these free GUI editors (like me), quite honestly, just use a layout library (like MIG) and just do it yourself. It'll be slow at first, but you'll have a lot more control and less editor newonses.
It really does depend on what you are trying to accomplish with the GUI. When I was tossing together ideas for a Computer Science class and testing functionality, the Netbeans WYSIWYG editor was great since it automatically generates a lot of the code for you. However, I found you tend to get better control with doing it by hand (in Java) than learning Netbeans.
I tried to use Eclipse's Visual Swing plugin, but on some occasions, the code it generated just disappeared, and I was left with a screen full of errors. In all the GUI apps I write, I use Netbeans, even though I hate the code generated when using GroupLayout. However, if layout code is not your concern, I think you'll be very pleased with the development speed it offers you. The only thing you'll have to do is implement the event logic and other logic you may require.
Eclipse's Visual Editor is a great choice, because the code that it generates is very straightforward and there's no hidden magic. Plus, you can make changes by hand and the editor will reflect them.
I test-drive the model of the UI, so that I have the functionality of the UI enclosed in a class that is completely decoupled from the GUI library and can be easily tested in isolation. Then I create a thin wrapper layer on top of the model, so that the GUI's event handlers are mostly one-liners that delegate to the UI model.
I've been using mostly IntelliJ IDEA's GUI builder (using the JGoodies Forms layout manager). It has been quite handly for laying out components in a static layout. But I think that for example with MiGLayout it's quite easy to write the GUI layout code by hand, so a GUI builder is not necessarily needed, and it helps to avoid tool lock-in. And dynamic layouts will anyways need to be written by hand.
But before writing any code, I first design and test a paper prototype of the UI, so as to have a clear vision of what needs to be done.
If you aim to create the final Java GUI, I recommand the Eclipse plugin named "Jigloo GUI Builder", which can generate clean and maintainable Java code.
If you just want to create the GUI quickly for review, you can try the UI prototyping tool like "ForeUI".
There's nothing wrong with using a GUI Designer when :
You understand what the IDE does and what it generates, how to customize the IDE output
You understand the code actually generated by IDE
Understanding at least the basics of Swing is important. Imagine the following scenario which happens just too often.
Q:"I have 10 years of experience writing swing applications"
A:ok
Q:How would you debug this code
A:Oh wait, there's no Netbeans form file??? You guys are not high tech!
Q:Hum.. you don't understand it?
A:Of course not, it's like machine code, you need to refractor it all and use an IDE!
I find that GUI builders can often complicate things and I'd rather know what was going on when the GUI was built than just use the variables created. I think because I don't know everything about Swing and layout managers as well, I am afraid to generate code that I have no conception of or don't know truly how it works.
When I was doing simple scripting using AutoIt that I knew would only be used on machines that had big enough screens I would use the GUI form editor. However, with commercial applications and those which may run on machines with any specifications I would generally shy away from GUI builders.
That said I think my decision may be influenced by my lack of knowledge regarding layout managers and maybe in the future I will start to embrace them more, as I can see nothing wrong with using them when you have a full understanding. Unlike some programmers may state, it is only a lazy way of building a GUI if you use the software with lazy intentions, and not for efficiently as the applications were written for.
To answer the original question directly, 99.5% of the time I will write the GUI from scratch!
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 7 years ago.
Improve this question
I find the nature of this question to be quite suited for the practical-minded people on Stack Overflow.
I'm setting out on making a rather large-scale project in Java. I'm not going to go into specifics, but it is going to involve data management, parsing of heterogeneous formats, and need to have an appealing interface with editor semantics. I'm a undergraduate student and think it would evolve into a good project to show my skill for employment -- heck, ideally it would even be the grounds for a startup.
I write to ask you what shortcuts I might not be thinking about that will help with a complicated project in Java. Of course, I am planning to go at it in Eclipse, and will probably use SWT for the GUI. However, I know that Java has the unfortunately quality of overcomplicating everything, and I don't want to get stuck.
Before you tell me that I want to do it in Python, or the like, I just want to reiterate why I would choose Java:
Lots more experience with algorithms in Java, and there will be quite a bit of those.
Want a huge library of APIs to expand functionality. ANTLR, databases, libraries for dealing with certain formats
Want to run it anywhere with decent performance
I am open-minded to all technologies (most familiar with Java, perl, sql, a little functional).
EDIT: For the moment, I am giving it to djna (although the low votes). I think all of your answers are definitely helpful in some respect.
I think djna hit better the stuff I need to watch out for as novice programmer, recognizing that I'm not taking shortcuts but rather trying not to mess up. As for the suggestions of large frameworks, esp. J2EE, that is way too much in this situation. I am trying to offer the simplest solution and one in which my API can be extended by someone who is not a J2EE/JDBC expert.
Thanks for bringing up Apache Commons, although I was already aware. Still confused over SWT vs. Swing, but every Swing program I've used has been butt ugly. As I alluded to in the post, I am going to want to focus most on the file interchange and limited DB features that I have to implement myself (but will be cautious -- I am aware of the concurrency and ACID problems).
Still a community wiki to improve.
Learn/use Spring, and create your project so it will run without a Spring config (those things tend to run out of control), while retaining the possibility to configure the parameters of your environment in a later stage. You also get a uniform way to integrate other frameworks like Hibernate, Quartz, ...
And, in my experience, stay away from the GUI builders. It may seem like a good deal, but I like to retain control of my code all the time.
Google-collections:
http://code.google.com/p/google-collections/
Joda Time for all date and time manipulations.
One of Hibernate or iBATIS to manipulate data in a database
Don't forget the IDE: Eclipse, Netbeans or IDEA if you have some cash and like it
Apache Commons has a lot of time saving code that will you most likely need and can reuse.
http://commons.apache.org/
A sensible build and configuration platform will help you along the way, Ant:
http://ant.apache.org/
or Maven (preferably):
http://maven.apache.org/
Especially as the size of the project, and the number of modules in the project increase.
There's getting the "project" completed efficiently and there are "short cuts". I suspect the following may fall into the "avoiding wasted effort" category rather be truly short cuts but if any of them get you to then end more quickly then I perhaps they help.
1). Decomposition and separation of concerns. You've already identified high-level chunks (UI, persistence layer, parser etc.). Define the interfaces for the provider classes as soon as possible and have all dependent classes work against those interfaces. Pay a lot of attention to the usability of those interfaces, make them easy to understand - names matter. Even something as simple as the difference between setShutdownFlag(true) and requestShutdown(), the second has explicit meaning and hence I prefer it.
Benefits: Easier maintenance. Even during initial development "maintenance" happens. You will want to change code you've already written. Make it easy to get that right by strong encapsulation.
2). Expect iterative development, to be refining and redesigning. Don't expect to "finish" any one component in isolation before you use it. In other words don't take a purely bottom up approach to developing your componenets. As you use them you find out more information, as you implement them you find out more about what's possible.
So enable development of higher level components especially the UI by mocking and stubbing low level components. Something such as JMock is a short-cut.
3). Test early, test often. Use JUnit (or equivalent). You've got mocks for your low level components so you can test them.
Subjectively, I feel that I write better code when I've got a "test hat" on.
4). Define your error handling strategy up front. Produce good diagnostics when errors are detected.
Benefits: Much easier to get the bugs out.
5). Following on from error handling - use diagostic debugging statements. Sprinkle them liberally throughout your code. Don't use System.out.println(), instead use the debugging facilities of your logging library - use java.util.logging. Interactive debuggers are useful but not the only way of analysing problems.
Don't discount Swing for the GUI. There are a lot of good 3rd party Swing libraries available (open source and commercial) depending on your needs e.g.
JGoodies Form Layout
SwingX
JFreeChart
Use logging framework (i.e. Log4J) and plan for it. Reliable logging system saves a lot of time during bug fixing.
For me big time-savers are:
use version-control (Subversion/Git)
use automatic builds (Ant/Make/Maven)
use Continuous-integration (Hudson/CruiseControl)
the apache-commons-libraries are very useful
Test Driven Development
Figure out the functionality you want and write tests to demonstrate the functionality. Then write just enough code to pass the tests. This will have some great side effects:
By writing just enough code to satisfy your requirements you will not be tempted to overbuild, which should reduce complexity and make your code cleaner.
Having tests will allow you to "refactor with confidence" and make changes to the code knowing you're not breaking another part of the system.
You're building quality in. Not only will you have assurance that you code "works, but if you really want to use this code as a sort of "resume" for potential employers, this will show them that you place a lot of value on code quality. This alone will set you apart from the majority of the developers out there.
Aside from that, I would agree that other big time savers are Spring, having an automated build (Maven), and using some form of source control.
For data persistency, if you're not certain that you must use SQL, you should take a look at alternate data-storage libraries:
Prevayler: an in memory database systems, using developing ideas like "crash only components", that make it easy to use and very performatic. May be used even for simple applications where you just need to save some state. It has a BSD License.
BerkleyDB Java Edition: a storage system with different layers of abstraction, so one can use it as a basic key-value storage (almost an in-disk hashtable) to a fully transactional ACID system. Take a look at it's licensing information because even some commercial software may use it for free.
Be aware that they have trade-offs when compared with each other or with a standard SQL database! And, of course, there may be other similar options around, but these are the ones I know and like. :)
PS: I was not allowed to post the respective links because I'm a new user. Just google for them; first hits are the right ones.
You can save time between restarts by using JavaRebel (commercial). Briefly, this tool allows you to write your code in Eclipse and have the code changes picked up instantly.
Spring Roo can not only get your project quickly kickstarted (using a sound architecture) but also reduce your ongoing maintenance. If you're thinking of using Spring, servlets, and/or JPA, you should definitely consider it. It's also easy to layer on things like security.