As a novice to the world of Java programming, this question has always boggled my mind. I first believed that all Java files were compacted into applets and then ran, but I soon realized that this isn't always the case. Could someone explain to me how we actually interweave our Java applications into a real product of everyday life?
TL;DR: How do we implement our code for practical usage?
It depends on the application. There are many options depending on how you want your users to use your app. Usually it's packaged as a jar or a specialized jar (war, ear).
In theory, you could zip the raw directory structure with your .class files in it and provide a shell script/instructions that run the java command for the user. I don't recommend this because it's kind of unprofessional and requires you to maintain a shell script for each OS you want to be able to run the program on.
Jar files are used to package libraries but you can also have a manifest file in it that says, "When someone double clicks/executes this, run this class". That class can start up a GUI or be a headless task that responds to the parameters, etc.
You can have applets, like you said. These programs are run in the user's browser.
You can have a war file, which is a way to package a web application. You give this to a web server and it knows how to deploy it so that you can visit the web pages. An example web server/container is tomcat or jetty.
You can have an ear file which can contain other war files inside it. This is used for applications that need other parts of the javaee functionality (ejbs, jms queues, etc.). An example of an application server is jboss or glassfish.
There's also java web start apps. These are apps you can run by visiting a webpage, but they get downloaded to your computer and run on the user's computer (instead of on the server's backend, like in a war/ear).
There's also javafx. I don't know anything about that though. By skimming the FAQ, it appears to be Java's answer to Adobe's Flex. You configure UI components with an xml configuration. I'm not sure what format JavaFX apps use, but it does say, "Deploy on the desktop or in the browser".
As Sotirios Delimanolis mentioned in a comment below, you can build these files with build systems like Ant or Maven. You can also build them "by hand" with the tools that come with the java/javaee sdk. For example, you should have a jar command in your path if you installed the sdk. Here are some details of these build systems:
Maven
High level (you tell it what to build, not how to build it)
Much more than just a build system. It also has dependency management, etc.
Opinionated (it uses convention over configuration, each config file generates 1 artifact, etc.)
Ant
Low level (you tell it how to build things)
Flexible
Config files can do whatever you want, build as many artifacts as you want
Easy to learn
SDK tools
Always up to date. EG: Very rarely, maven/ant may not be able to set a configuration option
Difficult to remember commands
Very low level
By itself, not repeatable (EG: unless you build a script, you will have to type the jar command yourself each time)
Applets never really caught on and are very rarely used nowadays.
Simple applications can be deployed as "executable" JAR files , which are basically ZIP archives with additional metadata that tells the JVM which class contains the main method to run. They can be run on the command line using the -jar option, or in most desktop environments by double-clicking (this requires a JVM to be installed as well).
Desktop applications can be deployed via Java Web Start or installers like IzPack or Install4J, but Java desktop applications are not very common either.
Most Java software nowadays runs only on servers (web servers or app servers). They are typically deployed as WAR or EAR files, which are also ZIP archives containing classes and other resources. These applications then run inside a server component following the Servlet or EJB standards.
If the application is mean to run on a client, it is packaged as an executable JAR, then further packaged as an Application Bundle (Mac), maybe wrapped in an exe (Windows), or paired with an executable script that will launch the JAR and set any required VM arguments.
If it is part of a web application, then it will be packaged as a WAR or EAR and placed into the appropriate location on the web server.
If it is simply a library, then it is usually packaged as a JAR (non-executable) and distributed as such for integration into larger projects.
applets and then ran, but I soon realized that this isn't always the case
Actually, applets are rare nowadays and their use is discouraged.
Create an executable jar, a war which is dropped into a web server or a library that is used by another project that is one of the previous two.
Related
I am starting a Play Framework project which is using a specific dll (bought from a company to do some specific operations) loaded with System.load command.
My question is: how this will run when I will deploy it on cloud?(for instance on cloudbees)?
I understand that locally is working (I am on a windows 7 env. and dlls dependencies can be resolved) but how this will be solved when putting the project in production?
Maybe this questions sounds stupid but I simply don't have the specific knowledge on this area:).
For production environments, Play generates a WAR file (a Java Web Application). You have to configure the project in order to include the DLL into this WAR file. Moreover, you have to be sure that the production environment (cloudbees) is Windows based. In other case, it won't work out.
Hope I can explain this clearly. I am creating a desktop application that has dependencies on other external jar files. For example, my application is Spring-based so there are some SpringFramework jar files that I will need in my application.
I am using Java WebStart to 'launch' this desktop application. (As to why I am doing this is that I need to execute this customised desktop application via the website that we are building).
However I ran into troubles when I executing my desktop application by clicking on the jnlp description file. It gives errors stating that there is no class definition for some of the classes that my desktop application is using. I then realise that my desktop application when packaged as a JAR file, it didnt include my other JAR dependencies with it. Hence the reason for the error.
I guess, I could include the external JAR dependencies in my desktop JAR file but this would make my desktop JAR file quite large. And this will be then make the download of my JAR file slow due to the large JAR file since clicking on the JNLP descriptor file will always source from the desktop JAR file from the server. (unless I can 'tell' the JNLP descriptor not to download if there is no new version on the server.)
Anyway, I was thinking if this is an acceptable approach where my desktop JAR file will not include the JAR dependencies but only references to it. When my desktop application launches, it will check if these dependencies are available on the desktop, and if it is not available, it will call another JNLP descriptor that will download the external JAR files and copy them to a pre-determined location that my desktop application references. Will this work? or is there a simpler solution to my problem?
thanks
The JNLP file should include references to both your main file but also all needed libraries. This is standard functionality and you should do it that way.
Note that you should have a time stamp in your file names to avoid cache problems when updating code.
You need to have your JNLP reference the additional jars you have. Yes this will take slightly longer to download, but as long as you are not including a bunch of jars that you don't need this should not take very long. Web Start is smart enough to not re-download jars that have not changed on subsequent start ups of the same application. I have Java Web Start applications that have several large jars and this works just fine.
As far as putting the extra jars on the user's machine, I would not advise this. If you are going to do that, then there is not much of a point to use Web Start and you might as well install the entire program on the desktop.
The other answers covered most bases, but just thought I should add that it might make sense to mark the extra Jars as download='lazy'.
I am in the unfortunate situation where I need to deploy and upgrade packages and config files on machines with no root access and no ability to use or install a package manager. Are there any neat solutions that allow creation of custom install packages?
I am open to custom compiles of some software in a custom location on the servers if it helps the situation.
Im almost at the point where I might end up having to write my own java package management system :(
In case its relevant some further information. The installer needs to install and configure the following:
Apache Tomcat
WAR files into Apache Tomcat
ActiveMQ
Some JAR files with some corresponding Cron entries
This sounds a bit perverse. Why do you need to "deploy" Tomcat / ActiveMQ to (lots of) machines that you don't have root or sudo access to?
Anyway, I don't see the need for a custom installer to do this (* see note below).
The yum --installroot /home/whatever <package> should install <package> in a non-standard location. If you cannot use yum or whatever, you should be able to download a binary ZIP or TAR file and unpack it. And once you have installed / unpacked whatever, you can leap in and edit the configuration files using the relevant app tools ... or a text editor. Tomcat can be installed in any directory you feel like, and run using your own login account if you need. I imaging ActiveMQ is the same.
Deployment of a WAR file is simply a matter of copying it to Tomcat's webapp directory.
Creation of a cron entry is simply a matter of running the crontab(1) command.
And if you have to go through this process lots of times, you could write some shell scripts to do the repetitive work for you.
(* Note - there are a couple of possible roadblocks.
You will need root/sudo access deploy a startup file for Tomcat, etc to "/etc/init.d" to get it to start automatically when the system boots. There is no easy way around this. The "/etc/init.d" directory is only writeable by root.
If you want manually launch Tomcat to run on ports 80 / 443, you will need root/sudo access to launch it. Again, there is no easy way around this. Only a "root" process can listen on port numbers less that 1024.)
Take a look at InstallJammer. You can develop graphical or console-based installers for both platforms from a single project. They won't require root unless you need them to.
InstallBuilder is the tool we use to package Bitnami stacks including the Java ones like Alfresco which include JRE, Tomcat, etc. and do not require admin privileges
At the moment my build process consists of repackaging the war file with all required java libraries under WEB-INF/lib and then copying the war file to development/demo/production server to be redeployed by tomcat.
The packaged war file's size is about 41M and it has at the moment something like 40M of external java libraries. There has to be a better way. How have you solved this issue?
My development machine is a windows box with Eclipse as my IDE and Ant as my build tool. The servers are all linux boxes with Tomcat 5.5.
Should I maybe add the jar files to the war package at server side?
I can see what you are saying, and have had the same frustration with some of our webapps, but for consistency sake, I would suggest you keep things as they are. If copying the libraries to the tomcat/lib directory you may run into issues with the system classpath vs. the webapp classpath.
By keeping things as they are you are sure you are deploying the same stuff in development/demo as you are in production. Life sucks when you are manually tweaking stuff in production, or you have some crazy error because you forgot to update XYZ.jar from version 1.6 to 1.6.1_b33 in production and now it's behaving differently than what you believe is the exact same code on demo.
When working with something vital enough to have dev/demo/production systems, I think consistency is much more of an issue than .war file size.
We use the rsync tool for this (in our case, using cygwin under windows) to copy the deployments to the servers (which run linux). We use exploded WAR/EAR files (i.e. a directory structure called MyApp.war rather than a zip file called MyApp.war), rsync will only transfer the files that have changed.
In general use, rsync will transfer our 30-40 megabyte exploded EARs in about 5 seconds.
Tomcat has a shared/lib directory, which is the proper place for global application dependencies. However, these will be visible to all applications, which will affect dependency management and may have consequences for things like static variables. I'm not sure if you can configure anything better in Tomcat.
An alternative is to switch to a more sophisticated web container. For example, WebSphere Application Server Community Edition (a blue-washed version of Geronimo) supports per-asset libraries. Other free and commercial servers support this, too. I know WebSphere Application Server does and I'm pretty sure you can do it in Glassfish.
#McDowell, when mentioning those J2EE servers, you should precise that they are J2EE servers(servlet container + the rest).
Like #digitaljoel, I suggest to keep things like they are. It looks like you haven't done much web application deployment yet. The issues that you'll have are not worth the price(version conflicts, deployment errors, etc.).
Can you add the non-changing Jars to the Java Library Path on the server side, and only include the regularly changing Jars in your WAR?
you could include the external java libraries in the Tomcat/lib directory. That way they stay on the server.
You could just deploy as a JAR file, replicate your deployment environment locally and just copy over the files that have changed and the jar itself. The pathing is the only real issue.
Or you could look into setting up an EAR.
I work with the 'exploded web application' in the development servers, and occasionally in production as well. The deployment process (based on ANT) updates the JARs in WEB-INF/lib with our packages. Only in the development server, we activate Tomcat reloading which takes care of restarting the application when something changes. You should assign some extra permanent memory to these Tomcats and have a way to restart the server, as the reloading may crash Tomcat from time to time.
I know it's a weird configuration, but I can't understand how constantly repackaging the 30MB (and growing) of our typical application could do any better. May one day the development descriptor allow for external references to libraries which the container may download and cache. ??
Excuse my poor English.
What you need is a version control tool and a build process.
Use CSV,SVN,GIT or whatever fit you to keep your source under control.
use a build tool to build your application : Maven,ant,...
Now, when you want to deploy your application on your server ,you just have to commit your updates on your computer,update your source on your server,build your application and deploy it from the server.
This way , the server will just have to load your modifications and it should be much faster.
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.