简体   繁体   中英

Is using Java the proper language/platform for developing a GUI based accounting app?

I know this is partially subjective, but hopefully with enough specifics I can get a good answer.

I am looking to develop an accounting app targeted at a specific market segment (think Quickbooks, but tweaked). Most of the app will be editable tables that are linked with DB data and some basic reporting and graphic functionality.

It must be cross-platform (OS X and Windows).

It will interface with a local DB. (SQLite or Derby or whatever)

Speed is not a "huge" issue. It needs to be reasonably responsive (I'm not familiar with Java speed in comparison to C/C++).

I narrowed it down really to between C++ with QT and Java. I only know a very little amount of Java, but work with C++ regularly. However, Java so far appears to the best overall solution and the amount of books/documentation is enormous which is a plus.

  1. How easy is the integration with Java GUI's and a DB? Does NetBeans make this process easy or should I use Eclipse instead? I'm looking for an experience similar to C# with Visual Studio.
  2. Is the whole "Big Decimal" rounding issue in Java a major issue or is it easy to work around? (sorry if I sound uneducated on the topic, but I really am not familiar with Java)
  3. Is there any real showstopper with Java that I may not be thinking of here or any real strong reason I should use C++ with QT over it?
  4. If I eventually wanted to port some or all of it to the web, does Java on the desktop make it easier for porting later?

First thing I should say is "there is no right answer here".

Java can do exactly what you want. The GUI toolkit, after years of reworking, is very advanced. There are also lots of tools, frameworks, and extensions you can use to make the GUI look very advanced.

Java also has a great DB connection framework. With Object Relational Mapping (ORM) tools (Hibernate and others) it is pretty easy to get data out of a DB, put it in Objects, manipulate it, and put it back in the database. The ORM tools also make it easy to connect data objects directly to the GUI, and use the rules in those objects to protect the data from corruption.

The cross-platform support will help you a lot. The only big sticking point is having a Java runtime on the machine for the files. There are ways around that (the best being have an installer put it there).

There obviously is not one solution, but there are pro's and cons to both solutions, and there even is a third solution: Java with Qt.

First off, my experience with C++ and Qt is already some years old, so might not be that accurate, and my interest in java GUI development ended one or two years ago when I saw the tools for development. I usually work in Java, but not with Swing.

That said, the main difference between Java and C++ seems to be deployment. Java is always dependent on the java environment installed, and C++ is a bit more self-contained. I would give a slight preference to C++ in that respect if you can manage the deployment on two platforms.

As for GUI development, Qt tools were very good and have only gotten better. The framework also matches the GUI process very closely, and is a natural fit for that kind of work. Swing seems to be a bit more low level, and required a fair amount of boilerplate code. And I know of no really good development tools myself though I heard good things of mantisse.

If you think Java is the way to go for deployment or back-end logic, but the GUI tools for Qt are just too good to ignore, check the stackoverflow question about Java Swing or Java Qt . It's worth a read.

In your particular case I'd go with C++/Qt as you have experience with C++, and it's not all that trivial to correctly build a Java Swing application.

  1. I'm not familiar with Netbeans, but I'd done several of Java applications with database access. I found it pretty easy even when I was using gvim instead of an IDE.
  2. What "Big Decimal" issue are you talking about? All computer languages have issues with the mapping between binary and decimal, but if you know what you're doing you can deal with it regardless of the language. Hell, I did engineering applications in FORTRAN-H.
  3. Other than the fact that you know C++ better, there is no reason not to use Java. It fits your requirements well.
  4. Writing something so it can eventually be ported to the web is more a matter of making sure you use Model-View-Controller patterns and keep in mind that your View may end up being something entirely different. That's a design philosophy rather than a language requirement.
  1. Anything with beans in the title I'd avoid, but java works great with DB and GUI.
  2. I'm not sure what you mean, but you might want to make your own money class. Hardly like it's a lot of work, and then it will round exactly as you like.
  3. It's much likelier to actually work properly in Java than C++ but if you have a really complicated GUI the Java GUI stuff is easier to use than most C++ apps for some things but harder for others.
  4. Not really.

No concurrency? It's only on a local database? I find that surprisingly limiting for a new software project. I'm surprised you aren't thinking AJAX browser GUI with web-service back end.

EDIT: Speed is not an issue and you think you might need to port it to the web? Start on the web and save yourself a lot of headaches.

I would suggest Groovy rather than Java. It's sort of Java++, in that almost everything in Java is also in Groovy, but Groovy provides a number of benefits on top of that. The Groovy language provides a number of helper methods. Does math correctly by default (no double math issues).

As far as web vs desktop, you could go with Grails for web, and Griffon for desktop. Again, Groovy based.

For IDE, if you choose Groovy, then either IntelliJ (although to do web, it's pricey), or SpringSource Tool Suite, which is an Eclipse derivative. Basically Eclipse with a number of plugins, including Groovy.

I'm developing a GUI tool in Java using NetBeans, and had no problems so far. Don't depend on NetBeans GUI editor totally, I only use it for designing my dialog boxes and panels. I've experienced that if you go the MVC way, it gets much easier to use NetBeans GUI editor. You can then totally leave the design part to NetBeans. Look into the new SwingSet3 demo , and decide whether Java Swing controls will be enough for you or not (in terms of appearance, and available GUI controls). Also, have a look at SwingX components some of them are really awesome and good looking such as ShadowBorder, TitlePanel etc. I will definitely suggest you to use JXTable for your tables instead of JTable. Given the popularity of Java, I don't think BigDecimal issue hasn't been already addressed. Regarding DB, Java comes bundled with its own feature complete JavaDB , which is really small in size - just 2.5 MB. This will come handy if you don't want to install heavy weight DBMSes such as MySQL. This will also be another level of abstraction IMHO - your clients will hardly see any external DB being used. Never be fooled that being portable means your Java software will automatically work in different platforms. It will definitely need some more efforts but if you work on your initial design, and build your software keeping the different platforms (not only OS but desktop/web etc) on the back of your head, it will be easy to tweak it a little bit to make it totally portable. Go MVC way, it won't hurt. My 2 cents.

If you need cross-platform Java is quite a good bet.

Remember for accounting purposes, use a datatype suitable for amounts. Double/Reals/Floats etc all essentially represent numbers like a binary fraction multiplied with an exponent, resulting in rounding errors. For Java BigDecimal is reported to work well.

This maybe of interest for you

Ajaxswing

though I would like others stated develop it from the ground up as a web application.

Well, if you know C++ well, then that's the number one reason to go with it. QT is a very nice toolkit and you will far more productive with that than you will with Java (as you know C++ well). Also the chances of you making a better app is greater due to that experience.

So, unless you're desperate to get experience with Java (and nowadays that's not so big a plus as it used to be), stick with C++/QT and build up some cross-platform skills.

Personally, if I was going for a new app from scratch, and I wanted to learn something new, it'd be a webapp with some new HTML5/js goodies. The fancy web features are more likely to be the future for apps over thick desktop clients (and friendly on more mobile platforms).

I'd definitely recommend going with C++ and Qt. Especially if you use either Qt Creator or Qt Designer for doing UI layout.

If you need or really just want to use Java (or a JVM language), I'd use Qt Jambi. Either way, Qt is (IMHO) a far superior platform regardless of the language used. If you haven't done any Swing or SWT development before, I'd give you about two hours before you feel like eating a bullet.

To address question 2, Java can be a bit of a pain in dealling with floating point numbers, but it has gotten much better as of versions 1.5 and 1.6. If you do go down the Java path, be sure to you the most recent version available.

The issues involved are explained fairly well in this article: http://www.ibm.com/developerworks/java/library/j-math2.html .

As some others have pointed out a webapp might work fine. I think RubyOnRails is very productive and you can run it on JRuby on both platforms or with any native Ruby. You would have to look into security but it shouldn't be a big problem.

If you don't know Java you could also check out Mono. You can create WindowsForms apps with it and run on both Mac and Windows, or if you go the web route and use ASP.NET on Mono. I still think RubyOnRails will give you a shorter development time than ASP.NET but it is an option.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM