Java Application Installers [closed] - java

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not looking for java-web-start, I'm looking for a thick-client application installation toolkit. I've got a stand-alone application that consists of several files (jar files, data files, etc) and would need to do some pretty standard installation tasks, like asking the user for target directories, have them locate some parts of their system - choose some of the per-machine or per-user configuration options and possibly try to detect some of the machine settings for them.
I'm looking for something which is like the MSI or other wizard driven installation applications. What's a good installer for Java? It would be ideal if it were cross-platform capable (Linux, Mac OSX and Windows).

Not an MSI-Installer but crossplatform: izPack
It's xml-file based with it's own GUI or ant task (whtaever you prefer)

Launch4j -- open source -- http://launch4j.sourceforge.net/
InstallJammer -- http://www.installjammer.com/

If you are looking for an Open Source solution, take a look here:
http://java-source.net/open-source/installer-generators
I have used InstallAnywhere and I think that it is a good solution too.

Although it is not Java-based, about half of our customers use BitRock InstallBuilder to package Java applications. It is cross-platform and supports all the OS that you require (Linux, Windows, Mac). The installer is native, so there are certain advantages to it, such as not requiring a self-extraction step or the need to bundle a JRE, so the installers tend to be smaller in size

AntInstaller enables you to create cross-platform installers where the installation itself is performed using an ANT script. The GUI is configured with an XML config file.
We used it to create quite complex installers. For complex GUIs however, the configuration can get very difficult. The next time I would probably try izPack because it seems to support ANT as well but has nicer GUIs.

I suggest izPack
with
packJacket

The Nullsoft Scriptable Install System NSIS (originally used for winamp) creates really nice installers for windows, and it's very powerful. It has a compiler that runs under linux, but the resulting installer is windows-only, unfortunately.
It's pretty heavy-weight, but worth keeping in mind if you might have to do any vaguely complex or non-standard things during installation.
I have used it since it integrates nicely with my (linux) build system, and I'd want to use packages for installing on linux anyway.

Related

JAR executable pros and cons [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been using JAR files to export my projects in my Java subject at school. I noticed it's portability (assuming the computer in use has Java installed). However, with that fact, why haven't I seen developers distribute Java programs using a JAR file? What are the pros (besides portability) and cons (aside from using C++) of using the JAR executable?
There are two components to the question. The first is shipping a JAR and using no installer. The second component to the question is the pros and cons of a using just a JAR on the machine once the executable has been deployed. I'm starting to suspect that the OP was asking about the first component. My answer tries to answer the second component.
Pros
Less work. Don't have to make an executable for each platform you want to support.
Cons
If the user doesn't have java installed it can't tell the user why it can't run. An exe can also download java for the user.
If your app requires a specific version of Java it may run with the wrong version. A a native executable can locate the correct one and use it. This point isn't as important as it used to be since Java 6 has been around so long.
Can't have an customized icon for the executable on Windows.
You can't control startup options such as the maximum memory that your app can use. For most apps this is ok but sometimes you need more memory.
A JAR cant be used for a Windows service. There must be an exe wrapper around it (jsmooth has this).
Another alternative to producing an executable is to use JNLP. A web page can check for java before it forwards the user to the .jnlp file.
I'm hoping that the advantages are pretty obvious. The biggest disadvantage I've run into is when there are additional dependencies that are required that aren't included in the JAR. A MANIFEST can be included to set the classpath - but this requires that all of the dependencies exist with pre-defined names in a pre-defined location. This can be worked-around with a loader script (to set the classpath, etc.) - at which point not everything is contained in the single JAR anymore, and most of the advantages are lost.

Netbeans 7 vs Eclipse 3.6 for Java, git and vim [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Both of them have a lot of features and are very popular, but which is better?
To reduce subjective answers, please answer this points:
Code Refactoring.
Unit testing, debugging.
Git support.
Vim support.(available plugins and their quality, eclim, jVi).
Easy of use(theme support, formatting, configuration, other plugins).
Maven and Ant support.
Web development(glassfish, groove, grails, spring).
Desktop app development.(swing, gwt, swt).
Mobile development(Android support and other platforms)
Game development(which engines have better support, for example Jmonkey uses Netbeans).
Bonus question: Support of other languages Python, PHP, C++ and.
For every point that IDE does well, you can give it +1, so in the end:
Netbeans 8
Eclipse 7
Conclusion: Which one is better overall and which you would choose for:
Desktop development.
Web development.
Additional question:
Which IDE is being used in major companies?(Google uses eclipse, Oracle use Netbeans)
Note, these are largely my personal opinions; don't take everything too literally.
Eclipse, NetBeans and also IntelliJ IDEA are all very good and capable IDEs. In the end, it doesn't really matter which one you choose; they are all more than good enough for serious professional software development for Java SE and Java EE. I've used all three.
IDEA was tradionally known as the IDE with the best refactoring tools, but the current versions of Eclipse and NetBeans also have very good refactoring tools.
IDEA has built-in Git support. Don't know about Eclipse and NetBeans.
NetBeans and IDEA have very good built-in Maven support. For Eclipse, you need a plug-in (for example m2eclipse) and in my experience it's not as well integrated as in NetBeans and IDEA.
When you get the Java EE package of NetBeans, you get a bundled Glassfish server with it, which is very easy to use. I'm sure that with Eclipse and IDEA you can configure them to use Glassfish too, but it's undoubtedly going to be a little more work to setup than with NetBeans.
NetBeans has a great Swing GUI builder. Eclipse doesn't have a built-in GUI builder, but you can get Google WindowBuilder Pro which supports Swing, SWT and GWT.
The official Android SDK etc. comes with a set of Eclipse tools. IDEA also has support for Android development, but I don't know how good it is.
Last time I tried, the support for other languages than Java (for example, JavaScript) was better in NetBeans than in Eclipse.
As far as I know, Eclipse is still the number one most used Java IDE, but NetBeans and IDEA are also very popular.
For Scala development, IDEA has the best support at the moment in my opinion. The Scala team is working on an Eclipse-based IDE for Scala, but in my experience it is less stable than IDEA's Scala support. For NetBeans, there is a Scala plug-in but only one person seems to be working on it; last time I used it, it was buggy, slow and had memory leaks.

Is there a 'best' Java RAD - for al Android/Linux/Windows? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What's cross-platform for those, flexible, easy to develop and debug, and offers good cross-platform GUI development?
Good support for ODBC database is a plus and support for GIS database is a major plus.
Android does not use the same UI system as desktop Java. There is no common GUI tool amongst them.
As for Windows + Linux, both IntelliJ and NetBeans have a halfway decent Swing UI builder.
As mentioned by Yann, there are no cross-platform RAD system that cover both Android and Linux/Windows Java. Android is not really a Java-based platform; the Android SDK converts the Java bytecode to the more optimized Dalvik VM bytecode. For this reason, you may even find that even non-GUI java code does not "port" (I've run into a couple of such issues).
There exist some libraries that attempt to provide cross-platform access to the graphics layer such as libgdx, but none that will allow you to create "one-size fits all" GUI code easily. In general, though, you wouldn't want to do that either - the UI concepts are very different on a small touch screen and a large mouse-controlled desktop.
From a development point of view, any development environment that comfortably allows you to split the project into an Android project (for the Android stuff), a desktop Java project (for the desktop specific code), and a Java library project for the common functionality (keeping in mind the minor differences) that can be shared between both projects will do.
Currently only Eclipse provides a RAD environment for Android (as far as I know), but there is nothing to prevent you building the Android GUI part in Eclipse (importing the common code as a library) and doing the desktop project in a different environment if you prefer Netbeans or others for that.
Good and reasonably priced rad for android, basic language, native compile is Basic4Android google it, it was released a few weeks ago.
How about http://www.wavemaker.com/
and http://openxava.org/ ?
That comes quite close IMHO
and both are open source.

Which os is better for development : Debian or Ubuntu? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Are there any real differences between them?
I want to program in java and python. And of corse be a normal user: internet, etc
Which one will give me less headaches/more satisfaction ?
And which is better for a server machine ?
Thank you
Since Ubuntu is based on Debian, development is almost exactly the same for both. They're both quite suitable for server machines. The fundamental difference is that Debian follows a Free software ideology, while Ubuntu sacrifices that purity for practicality when no Free equivalent exists for important proprietary software.
If you choose Debian, you will have a choice of distribution series ("unstable" / "testing") that may get you newer releases of pre-packaged software a few months sooner than Ubuntu. Unless your development projects require bleeding-edge kernel or support libraries, this probably won't matter to you at all.
If you choose Ubuntu, certain proprietary software might be easier to install because it will be available through package repositories. For example, nVidia's proprietary video driver. That's not to say you can't make such things work on Debian; they will simply be easier on Ubuntu.
I personally choose Ubuntu, for these reasons:
Ubuntu has a free multi-platform build farm and software hosting system called Personal Package Archives. (Only to be used for freely redistributable software, of course.)
The Ubuntu bug reporting/tracking system is far more user friendly than Debian's.
Software packages I develop are guaranteed to work (with no extra dependency testing) for Ubuntu users, of which there are many.
I'd seriously consider switching to Debian on my workstation if they offered a PPA equivalent. I don't use Ubuntu-centric stuff like Unity desktop anyway, and I no longer need nVidia graphics drivers (I finally got tired of their deeply broken OS support and switched to an AMD card). I already run Debian on my servers.
Both use Debian packages and Ubuntu is based on Debian but is more user friendly. Everything yo can do on one you can do on the other. I'd recommend Ubuntu if your new to linux on a Desktop. Though when it comes to servers I'd recommend Debian as it has less stuff "taken out" basically.
java and python would most likely run the same on both.
With Ubuntu you get additional space of support and active community, and perhaps larger user base.
So if and when you face a particular problem, chances are with Ubuntu, the solution will appear faster.
(although, whatever works on this should work on the other as well in theory)
Ubuntu is the more user-friendly of the two (I think Ubuntu is actually one of the most newbie-friendly Linux distros), so if you are new to Linux, Ubuntu is the way to go. Otherwise, the packages are mostly the same except for branding, so it's pretty much your choice.
In Ubuntu it is a bit easier to install packages for Java development, but it doesn't really matter that much. Remember that Ubuntu is based on Debian, so it works the same. Ubuntu just adds more user-friendly GUI's.
Neither is better. They both support the same tools and libraries. They are both linux. Anything and everything you can do on one you can do on the other.

Best technology for adding plugin support to a J2SE application? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm writing a J2SE desktop application that requires one of its components to be pluggable. I've already defined the Java interface for this plugin. The user should be able to select at runtime (via the GUI) which implementation of this interface they want to use (e.g. in an initialisation dialog). I envisage each plugin being packaged as a JAR file containing the implementing class plus any helper classes it may require.
What's the best technology for doing this type of thing in a desktop Java app?
After many tries for plugin-based Java architectures (what is precisely what you seem to look for), I finally found JSPF to be the best solution for Java5 code. it do not have the huge needs of OSGI like solutions, but is instead rather easy to use.
OSGI is certainly a valid way to go. But, assuming you dont need to unload to reload the plugin, it might be using a hammer to crack a nut.
You could use the classes in 'java.util.jar' to scan each JAR file in your plugins folder and then use a 'java.net.URLClassLoader' to load in the correct one.
If you are "just" needing one component to be pluggable, it's enough to simply instantiate the classes based on meta information, e.g. read via a classloaders META-INF/ information from the various jars that are on your classpath or in a certain plugin directory.
OSGi on the other hand provides means to structure your whole application. If you already have a large Desktop application that needs one part pluggable, this would be a steep learning curve. If you start blank with what will be a Desktop app, OSGi provides means to modularizing the whole application. It's about "isolation of components" and independence of modules.
Apache Felix provides a nice start if you want to go down OSGi lane. It might look complicated and heavyweight, but that's only because one is not used to that level of isolation between modules. It used to be so easy to just call any public method...
Did you think of using OSGi as a plugin framework? With OSGi you are able to update/replace, load or unload your modules on demand.
One approach I'm considering is having my application start up a lightweight OSGi container, which if I understand correctly would be able to discover what plugin JAR files exist in a designated folder, which in turn would let me list them for the user to choose from. Is this feasible?
I also found this article by Richard Deadman, but it looks a little dated (2006?) and mentions neither OSGi (at least not by name) nor the java.util.jar package

Categories