Develop Reference

Want to make a application like one license per user in java

I want to make a executable jar which can run in only one machine.once it is run in any machine it can not be run in another machine.
Means i want to make one license per user type application.
I want to make this application using Java.
Any help on this would be appreciated.
Thanks in advance.

Yes, it's easy. Just grab your hardware informations and generate a hash. This will be synched on each start with a server. It will return a hash which can only be decrypted with the hardware. Then you can create a flag which is available by runtime that it'S "licensed"

Another option:
Remember that JAR files are actually ZIP files, with a different extension. You can store other resource files inside a JAR file, and I believe there is a Java API for retrieving those resource files (I don't remember how that API works). So:
When your customer orders a copy of your application, make them supply hardware information (perhaps give them a little application which harvests the data). Build a JAR for them which contains a resource file, with a hash of the hardware information in that file. When the application starts, retrieve the hardware information and hash it, and compare with the hash in the bundled resource file. If they don't match, exit.

Is .jar file protected by reading/editing?

I am currently creating some little Framed application in java.
When we clean an built a main project with netbeans (therefore creating a jar file), does it create a secured jar file ?
What I mean is that mine contains some tables with keys and I don't want that future users can be able to watch these key logs.
So is the code totally hiden ? In case not, how can we "protect" jar files please?
Thank you in advance for your help, please let me know if I wasn't clear enough.
EDIT : I am currently under windows 7

It isn't at all protected. It's just an archive (built on ZIP) of .class -es and other resources, metadata, etc.
You could try and obfuscate java bytecode with tools like Proguard. That would give you some protection, that is - it would make reverse-engineering more difficult.

My suggestion would be to encrypt the files that have the sensitive information, before you jar them. Let the application decrypt them when it needs to use the data. Use a ramdom-looking encryption key so people will be unlikely to figure it out by listing the strings in your class files.

Although this does not prohibit someone from viewing the contents of the jar file there are mechanisms that provide tamper evidence and prohibit someone from creating an additional jar that appends methods to your package.
This is called signing and sealing.

Keeping history of items without using a database in java

I have a small java utility application which performs tasks on remote computers. This app will provide user with a dropdown/combobox where they can enter ip address or hostnames for the computers they wish to connect to. It would be nice if the users could have a history of items/hosts they had connected in the dropdown.
I thought that I can create a file inside the distributable jar and use it to maintain the history. But writing to a file inside the jar seems to be impossible? The alternate approaches would be to use text files, databases etc located outside the jar. But this is not quite I would like to do as my utility app is only one file and I would like it to be completely independent of any external files. Also its not nice to have a text file stick around your jar file or create a text file each time your app is run.
Considering this case what options can I use? Are there any apis that can help in storing or keeping history?

Why don't you store this info with an hidden file in the user home directory? Many application do the same thing.
You can get the user home directory in this way
String userhome = System.getProperty("user.home");

I'd recommend keeping some .dat file somewhere associated with the JAR. Could be in same directory, or in the user's home (as #dash1e recommends) to avoid any permissions issues. I think you'll find that's the simplest solution.
Another option would be to use a Java-based database solution which could be bundled into your JAR (see Apache Derby, et al). Note that this would create files somewhere, but you wouldn't have to worry about the file-level management, as you'd just be interacting with it as a database.
One final option, if you really insist on avoiding having to maintain your own file, would be to use the Java Preferences API which provides an OS-agnostic way of storing data on the system in some obfuscated location. This is arguably a bit of a misuse of the goal of this API, but would accomplish what you're asking for.

How to store high score inside a jar file

I am developing a small game in Java and I am shipping it as a single Jar file. I want to store the high scores/best times for that game somewhere. Instead of storing it in a separate file, I would like to store it in the application itself (inside the Jar) so that its not lost. Is this possible at all ? If so, how to do it programatically.

Java does not give you tools to modify the JARs which are currently run. If you really want to do it, you have to guess the location of the JAR by yourself (which might reside on a read-only filesystem) and modify it the same way you would modify any archive file.
Bottom line: it's a very bad idea, don't do it! See this question for a much more reasonable solution.

Nothing is impossible, but storing it in the jar file would make it very complicated. You might also end up with unwanted side effects like "Permission Denied" errors when the jar is owned by another user. Virus scanners might get nervous when they see jar files change without reason, etc....
I would look to the Preferences API for storing this kind of info.

I think it is a bad idea to try and store anything in the jar file. Another option is to have a web based service offered to the people playing with your game. The game could connect through a web service to your hosted server and then store everything centrally there. Not sure if it is exactly what you want but it's just an idea. It would also allow people to compete with each other.

Java JAR file is a ZIP-Archive, so you could possibly access it with standard ZIP-Tools and just extract one hisghscores.txt file, modify it and then pack it back again.

How make working directory files available to WebStart application?

We have to make a Java application demo available on Internet using JWS. It goes pretty well; all that's missing is making working directory files available for the application.
We know about the getResource() way... The problem is that we have different plugins for the same application and each one require different files (and often different versions of the same files) in their working directory to work properly. So we just change the working directory when we want the application to have a different behavior.
Currently, the demo is packaged in a signed jar file and it loads correctly until it requires a file from the working directory. Obviously, the Internet users of this demo don't have the files ready. We need a way to make these files available to the WebStart application (read/write access) in its working directory.
We've thought of some things, like having the application download the files itself when it starts, or package them in the jar and extract them on startup.
Looking for advices and/or new ideas. I'll continue working on this... I'll update if I ever find something reliable.
Thank you very much!

I said I would share what I found in my research for something that would fit my needs. Here's what I have so far.
I have found that the concept of current working directory (CWD) does not really make sense in the context of a Java Web Start (JWS) application. This had for effect that I stopped trying to find the CWD of a JWS and started looking for other options.
I have found that (no, I didn't know that) you can refer (using getResource()) to a file in the root directory of a JAR file by simply adding a '/' in front of its name. ("/log4j.properties", for example.) The impact of this is that I can now take any file which is only referred to in a read-only manner in the root of that JAR file (which is really only a ZIP file). You can refer to any file in the root of the JAR file using AnyClass.class.getResourceAsStream. That rules out the problem with read-only files required to run the application, at the cost of a switch in the code telling whether the application is run from a valid CWD or from a JWS context. (You can very simply set a property in the JNLP file of the JWS application and check if that property is set or not to know where to look for the file.)
For write-only files (log files in my case), I used the property , adding a directory with the name of the application: <user.home>/.appname and added log files to it.
Read/write files (which I don't have in my case) would probably simply go at the same place than write-only files. The software could deal with uploading them somewhere if needed, once modified, I guess.
That's the way I deal with the problem for now.

Note there is a service you can explicitly ask for, to get file access to the computer (unless you go all the way and ask for full access (which requires signed jar files)).
Then you need to determine where these files need to go - basically you have no idea what is where and whether you may actually write anywhere. You can create tmp-files but those go away.
Would a file system abstraction talking to the JNLP-server do so you store the users data on the server?