Develop Reference

Developing Desktop Application using Java [closed]

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 9 years ago.
Improve this question
I was figuring out on the net, how to create a desktop application with Java. I found I can do it through NetBeans IDE. Is there a better IDE?
Can you suggest me a suitable eBook for learning Java NetBeans?

There are three major IDEs for Java:
NetBeans - https://netbeans.org/
Eclipse - http://www.eclipse.org/
IntelliJ - http://www.jetbrains.com/idea/ (This one is a commercial product.)
Pick your religion.

Actually, you can create desktop application with Java Swing GUI Toolkit, which is a part of the Java JDK, regardless of the IDE. #Lee Meador gives you some to choose from.
Here is a tutorial on making a simple desktop application with NetBeans.
There are also tons of YouTube tutorials for beginners. Search for "Java tutorials" and you'll be all set.

IDE preferences are fairly subjective. Netbeans is not bad. Eclipse is also a good IDE. My favorite one, though, is IntelliJ IDEA. They have a free Community Edition which lets you do a lot of things, but I paid for it to get full functionality.
As far as eBooks for learning about the IDEs, I would suggest just looking on the website of whatever IDE you end up choosing.

Here's how I see things when it comes to IDE's:
NetBeans is fantastic for beginners, but the code it generates for the Swing WYSIWYG editor looks like absolute garbage. If you're okay with keeping the code in NetBeans and not worrying about how the code for you GUI looks, it's an excellent way to go if you don't feel like hard-coding Swing.
Eclipse is a very professional and powerful tool, but it's a bit daunting at times as well, and it's not quite as quick and easy to get things up and running. It has no built-in drag and drop Swing editor (although Google provides an excellent one called the Google Plugin for Eclipse) but it's got far and away the most powerful debugger I've ever used.
I don't know a lot about IntelliJ other than that it's also a good choice for beginners and professionals alike, but I haven't seen as much community support for it. That may just be because I've been an Eclipse die-hard for ages, but that's just how I see it.
What's more important than your IDE choice is that you figure out early on how to use it to its full potential. All three are excellent pieces of software, and all three will help you do whatever it is you want to build. But they can only help you if you learn to use their organizational tools, their editor/template options, their respective debuggers, etc. Honestly, I would say if you have any friends that are Java developers, choose whatever they're using at least for now so you have someone to go to when you don't understand how to use a particular option.

How to choose a Java-COM bridge? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have to create an application which automates Outlook and Word and I want to use Java for that task. (The only allowed alternative would be VB6, so...)
After a quick Google survey I found several libraries, but I'm not sure which one to use:
J-Interop
SWT
JACOB
COM4J
jacoZoom
...
I have no idea how to compare these libraries and make an informed decision. It seems that COM4J is a little bit outdated, JACOB leaks memory (allegedly) and jacoZoom is commercial. Each and every one seems to require a lot of boilerplate code to perform a simple method call. (Which might be unavoidable given the design of COM)
Besides that I have no idea how to choose between one of them. Which one is the best?

We use Jacob in production environment and it works out pretty well. Nevertheless the projects seems to be not very active.
Speaking of which: Activity seems to be an advantage for J-Interop. We tried the project as well and it seems to work out pretty good with even better logging messages. I think we might choose J-Interop for new projects.
COM4J seems to be outdated, you're right.

As a developer seasoned in Java/Linux but ignorant in Windows, here was my experience (August 2015)...
Executive summary:
Go with com4j... with the caveat that:
You may need to build the latest (unreleased) code to get some important recent fixes.
Longer story:
At first, the propensity for code involving JNI to crash inexplicably made me look for a non-JNI solution. J-Interop seemed to fit the bill.
However, as I tried to get j-interop to work, all the Windows DCOM permissions and registry crap made it a total PITA. It's different for different versions of Windows, required changes must be made as Administrator, etc. I don't understand any of this Windows crap and it makes me want to puke anyway.
I then tried com4j and it worked like a champ. This project is very nicely designed. It auto-generates Java interfaces from the DLL's you are using. COM calling convention details are declared using Java annotations on the interface methods, allowing you to tweak these if necessary (no tweaks were necessary in my case).
There are several developers on github who have forked the project and contributed back fixes, which is a healthy sign.
The only caveat is that you may require some of the recent fixes which, as of August 2015, are merged into the project but not contained in the latest release (which is from March 2014).
So you may need to do a custom build yourself, which includes building DLL's in Visual Studio, etc. Even as a Windows hater/ignorant, I was able to do this.

COM4J still seems to be active - it has been moved to Github and has a new homepage:
http://com4j.kohsuke.org/tutorial.html

J-Integra by Intrinsyc Software http://j-integra.intrinsyc.com/ is your best option. It hides the complexity of having to know an unfamiliar programming language. It isn't dependent on JNI so you don't need to know JNI. J-Integra is also actively maintained and supported and Intrinsyc offers a pure 64-bit version for those people wanting to run in a pure 64-bit environment.
Intrinsyc offers free trials so you can test it out and see if it works before committing to any purchasing.
Companies like HP, IBM, SAP, and Oracle use it so you know its going to be fast, stable and well supported.

Appears bridj can do some COM interop as well: https://code.google.com/p/bridj/wiki/COM#Example

Java plugin framework choice [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We're trying to determine how to implement a simple plugin framework for a service we are implementing that allows different types of calculators to be "plugged-in".
After reading a number of posts about Java plugin frameworks, it seems like the most common options are:
OSGI
"Rolling your own" plugin framework
The Java Plugin Framework (JPF)
The Java Simple Plugin Framework (JSPF)
OSGI seems to be more than we need.
"Rolling your own" is ok but it would be nice to reuse a common library.
So we're down to the JPF and JSPF. JPF doesn't seem to be in active development anymore.
JSPF seems very simple and really all we need. However I haven't heard much about it. I've only seen one post on StackOverflow about it. Does anyone else have any experience with JSPF? Or any other comments on this design choice?
Update: There isn't necessarily a correct answer to this.. however we're going to go with Pavol's idea as we need just a really, really simple solution. Thanks EoH for the nice guide.

(Disclaimer: I am the author of JSPF, so better take my comment with a grain of salt ;-)
The main reason I started with the JSPF was because I had the same problem as you have now: I was looking for a simple solution to make my thesis-project 1) extensible and 2) give it a more or less clear code structure.
The reason why I haven't decided to use an existing framework was because most of them were so heavyweight to start with, that I got lost in reading documentation and was almost forgetting my original task. So, according to your statement
We're trying to determine how to
implement a simple plugin framework
for a service we are implementing that
allows different types of calculators
to be "plugged-in".
I'd think that you could give JSPF a shot and see how far you come within one or two hours.
However, the final decision also depends a bit on what exactly you want to achieve, and the specific circumstances.
I have heard positive results from a number of individuals who have been using it to structure their projects or load plugins in their projects. On the other hand, I also know of one person in our department who discarded it again because he didn't feel it was mixing well with his programming style.
So, to answer your question briefly (and surely in a biased way), I would use
OSGi for projects and teams
which are large and have many people working on it
that justify the overhead of setting up the infrastructure
in need of the specific services offered
JPF for projects and teams
of medium size (?, honestly I am not sure about the project / team size they are targeting)
which are in need of more structured facilities to organize their code, like XML configurations, detailed plugin lifecycle management, extensible plugins ...
JSPF for projects and teams
of small size, following an agile paradigm
that just need something that works out of the box, without the need of configurations or setup
willing to sacrifice some features for simplicity
I hope you find the plugin framework most suitable for your scenario. And, no matter what you try, I would be happy to hear about your results.

If you are planning to have just one (or only a few) not very complex 'extension points' than perhaps a well-defined SPI and a piece of configuration might be sufficient. No need to use a plugin framework.
By piece of configuration I mean some mechanism to find your plugins. For example something like META-INF/services/ or simply listing your plugins in a configuration file.
More details (upon request):
SPI = Service Provider Interface, an "implementer-side equivalent of an API". To learn more try searching for a difference between API and SPI. However in this context it is just a fancy term for an interface to be implemented by your plugins (i.e. defines the contract for your plugins).
A nice, short article "Creating a Service Provider Interface" by Ethan Nicholas describes how to create your own SPI in similar way as it is done in several part of the Java Platform itself.
META-INF/services/ can be seen as a more generalized approach to creating SPIs. More information can be found in the respective section of the JAR File Specification.

If you need a really simple solution, try jin-plugin. It is a minimalistic plugin framework for Java and PHP.

What is a MUST COVER in my Groovy presentation? [closed]

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.

Java Desktop application framework [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 9 years ago.
Improve this question
I am working on designing and building a desktop application. I am thinking about using eclipse or netbeans for the base of this application. However, I have never built on either of these platforms. I am personally leaning to using netbeans because it seams like that platform is an easer learning curve. But, I wanted to ask people that have actually build on these platforms before which one is easier to use?
My personal definition of easer is as follows:
Easy to get started with
Consistent and logical API
Good documentation
Easy to build and deploy
Thanks very much,
Josh

I can't say enough about the Eclipse RCP platform. I would recommend it for any Java desktop app development.
It's free, has great tutorials, and allows cross-platform development of rich desktop applications that use native OS windowing toolkit, meaning that your application will look native in any platform. It also has a clean API that stays out of your way, and makes deploying to any platform a piece of cake.
If your interested check out this book: http://www.amazon.com/Eclipse-Rich-Client-Platform-Applications/dp/0321334612

Easy to use: I have experience developing on Eclipse and I have to say it's not easy to understand its development model. Sure for basic stuff it has some wizards that make easier, but for something a little more complex it's just difficult. I don't know about Netbeans, but I heard its easier.
Consistent API: I think Eclipse wins in this aspect. It runs over OSGI (brings some complexity though) and has plugins extensions for pretty much everything. It seems to be the platform of choice for plugin development, so I can assume it's reliable.
Documentation: Eclipse wins by far. The help from eclipse site is excelent and the mailing list has plenny of users questions.

I have used Eclipse as a framework base but it was mostly just using SWT-- we didn't really use much of the RCP.
It really depends on what you're writing, but from what I have learned from using Eclipse it is really only suited for writing an app that involves you editing data using various views (just like editing code).
Anything more random that than can cause you to start pushing the framework in a direction it wasn't designed and causing massive fail.

You'll use Swing to develop your application because any other windowing framework is useful only if you have a previous knowledge or the appropriate background.
You can rely on http://www.javadocking.com/ to streamline you application.
If your application requirements are highly focused on the user interface, maybe you can look in another direction like Adobe Air.

RCP has a bigger learning curve, but once you learn the basics the Eclipse IDE itself supports building RCP applications very well. I have only built a plugin for NetBeans (not build a full-fledged application), and the learning curve was lesser than for the RCP application. The book Eclipse Rich Client Platform: Designing, Coding, and Packaging Java(TM) Applications provides a detailed introduction to building RCP applications.

Please see some of the open source applications at http://www.eclipse.org/community/rcp.php before opining that RCP is only for building a text editor. Thanks.

I have a similar task and I am also considering different frameworks. I have some experience with Eclipse (~4 months developing RCP) and now Netbeans (played around for a couple of days). IMHO these frameworks are too complicated. You just end up debugging into Eclipse-specific plugin loaders trying to figure out why you get a ClassNotFoundException or a NullPointer. The same story with NetBeans: somehow somewhere somewhat reads out xml config files and creates UI from that, cool, as long as you follow the tutorial. And of course you can't develop and Eclipse-based RCP using some other IDE, NB is also very jealous about its usage (unless you do some hacks like I did).
What I'm lacking is a clear way to debug my threads from main to action performed. Instead I'm always told what I have to do to avoid exceptions. And so I have to keep my fingers crossed each time I'm trying to pull something new. And it never works out the first time.
Now I thought about the features I need and I looked out for smaller projects that aim at specific functionality like plugin management eg. And there are plenty. Just compile a list of the functionality you need and start adding smaller frameworks by integrating them into your project. This also makes sense since your project should consume less RAM in the end.

Introduction to Eclipse RCP.

I've done a little work with both, but only on relatively simple applications. Both seem to have roughly equal capabilities. I personally prefer the Netbeans platform as it makes more sense to me.
You should also consider JSR-296, the Swing Application Framework. It provides a basic framework for building Swing Applications, managing application resources, state, etc, but without as much "baggage" as Netbeans and Eclipse. Netbeans IDE has a number of tools for building applications on the SAF. See https://appframework.dev.java.net/ for more info.
Without knowing more about your application, it's hard to point you at the appropriate strengths/weaknesses of the two platforms.

If you really want to avoid crossplatform maintainance then work with Swing. This buys you all platforms. RCP requires native libraries for each platform.
We have had good experiences with Swing.

I would use eclipse RCP when you really need a platform to built on top, not just "widgetery" like swing or swt. RCP is rock solid and consistent, modular and very flexible. Once you master it, you get huge benefits. Being a platform it give you the most commonly used things - preference, configurations, automatic updates, layout management, branding and things like that. You build a product, not an app. But learning curve is pretty steep in the beginning.
Swing on the other hand is not a platform, you will re-invent the wheel by writing your own things I mentioned above. But yes, swing is faster to learn and get started. I think it fits better for smaller applications with shorter life span.

Look some of the open source applications at http://www.eclipse.org/community/rcp.php before opening that RCP is only for building a stuff.