Hi, I'm new to Java and just considering whitch language to use for
server-side of my game. It will be simple Java app running at Linux
listening to sockets and sending messages to clients. No frameworks,
not a web app.
To launch python or pearl app at server you need just to upload file
and run it.
What about Java? Is there need of some kind of deployment tools? Is
there need of configuration? (Java will be installed at server). Where
do I read about how to deploy?
It's about the same as python or perl: you put the code on the server and
run the java interpreter on it.
The biggest difference, of course, is that you have to compile the code to
bytecode first.
There are also some differences in how you arrang the code on the server -
the rest of this post is a bit long-winded, but there's an important bit
at the end!
With python, if your program is in a file app.py, you just do "python
app.py". With java, you don't run a *file*, you run a *class*, and you
have to have set things up so the java interpreter can find the class. If
your code doesn't use a package declaration, then just putting the class
files in the directory where you run java will do the job:
mkdir ~/myapp
cp ~/dev/myapp/*.class ~/myapp
cd ~/myapp
java MainClass
Alternatively, run java elsewhere, and use the -classpath (or -cp) flag to
refer to the directory where the class files are:
mkdir ~/myapp
cp ~/dev/myapp/*.class ~/myapp
java -classpath ~/myapp MainClass
Alternatively, you can edit the CLASSPATH environment variable:
mkdir ~/myapp
cp ~/dev/myapp/*.class ~/myapp
CLASSPATH=$CLASSPATH:~/myapp
java MainClass
If your code does use a package declaration, then the same applies, but
rather than simply being in the location you point java at, the class
files have to be in a folder hierarchy rooted there whose names reflect
the package name. So, if your package is com.gmail.tamagafk.myapp (which
is kind of how we do package names), you would have to do:
mkdir -p ~/myapp/com/gmail/tamagafk/myapp
cp ~/dev/myapp/*.class ~/myapp/com/gmail/tamagafk/myapp
java -classpath ~/myapp com.gmail.tamagafk.myapp.MainClass
If you're using modules in python, you have to do similar things. Not
quite as much, though.
If you're using packages, one thing you can do is have a single classpath
root that you use for all java code, within which the package structure
keeps everything organised, rather than an application-specific root. So,
rather than having a top-level directory for myapp, you might do:
mkdir ~/javaroot
mkdir -p ~/javaroot/com/gmail/tamagafk/myapp
cp ~/dev/myapp/*.class ~/javaroot/com/gmail/tamagafk/myapp
java -cp ~/javaroot com.gmail.tamagafk.myapp.MainClass
In this situation, i would suggest using the CLASSPATH environment
variable, and setting it with 'export' (or whatever) in your .bash_profile
(or whatever). The advantage to this is that you can just do:
mkdir -p ~/javaroot/com/gmail/tamagafk/myapp
cp ~/dev/myapp/*.class ~/javaroot/com/gmail/tamagafk/myapp
java com.gmail.tamagafk.myapp.MainClass
Without having to noodle about with the classpath in any way.
Now, a caveat: if you take that approach, code in one application will be
able to load code from another application. This may be a good thing,
enabling code sharing. But you might also see it as a bad thing, allowing
coupling between separate applications.
Okay, last bit. As well as all this, java supports some things called JAR
archives, which are basically zip files with some metadata. The JDK
includes a tool called jar, which behaves a lot like tar, for making them.
JARs can be used in place of folder hierarchies full of class files: you
make the hierarchy with the class files, JAR it, and put that somewhere
that's in your classpath. This saves you having great mazes of folders in
your deployment environment, and it lets you keep the files for separate
apps separate (in separate JARs), while using a common root (where all the
JARs sit together). A JAR becomes a bit like a shared library in C. Except
it can contain a main() function!
Now, if you perform a certain magic incantation, you can do something even
more amazing, and create an executable JAR: this is a JAR where the
metadata indicates which class is the main class of the app. Then, you
simply tell java to run the JAR, and it works out which class to load.
This makes java behave a lot more like python, where you're running a
file.
To create an executable JAR, you need to tell JAR to include a manifest
file; if it's called myapp.mf, you do (to create a JAR called myapp.jar):
jar cvmf myapp.jar myapp.mf <list of class files>
The manifest file just has to contain one line:
Main-Class: com.gmail.tamagafk.myapp.MainClass
You can then run it like this:
java -jar myapp.jar
And that's it.
JAR files are a nice way of doing deployment, because you pack all the
class files into one file, and you compress them. You can also include
resources, like data, images and serialised objects, and access them from
the program using Class.getResourceAsStream().
tom
