I'm making a game, in Java, that has these following important features:
1) Connects to a remote Server (which i made), and will check for updates and install them if necessary
2) is NOT A SINGLE .JAR FILE (ie. has multiple .jar's and other things, such as .png, .wav, etc)
3) JAVA WEB START IS NOT AN OPTION, AS I WANT TO MAKE THIS ALL MYSELF
keeping the things above in mind, i have run into a problem. i have no clue how to implement a multiple "patch" update system. currently i have 1 .txt file, that the server reads from, and sends the files listed in the .txt to the client, which then moves them into place. The problem is, that is only useful for maybe 2 updates. I'm looking for a more useful, long term solution, and i need some help. here are some of the things i've thought of:
1) have a zip folder named after each version (problem: how would the client get ALL of the most updated files
2) have a .txt file INSIDE of each jar containing the version (problem: cant do that with png's or wav's, and i dont know how i would read the txt file to begin with)
i really need some help, i've tried googling it, i've thought about it for going on 3 weeks now, and cannot think of anything.
QUESTION: how would i make a game/program update with multiple patches?
Firstly, the best solution by a long, long way is to use Webstart / JNLP.
But if you insist on not using it (for whatever reason then) then it is technically possible. However:
It is messy and complicated.
It will either be very inefficient ('cos you have to load the entire program each time the user), or the user has to trust you enough to install your program with permissions that will allow it to install random stuff on his machine without notice.
The way to do it is to split the game into a launcher part and an application part. The launcher needs permissions to write and delete (non-temporary) files, and fetch stuff from the internet. It "calls home" to find out the latest version(s) of the application files, and then downloads and installs them. It has to cope with all sorts of error conditions, and it needs to make sure that nothing can trick it into installing bad stuff on the user's machine, etcetera, is someone spoofs your update service.
Of course, JNLP takes care of all of this, and lots more besides. People are going to be more willing to install the JNLP infrastructure that yours ... which might be insecure, or actively nasty (for all they know). (I for one wouldn't install a self updating application on my machine unless it was supplied by a company with impeccable credentials.)
I think you need here JNLP framework.
JNLP provides followed things:
allows to user to download jars from server
on launch verifies if application need to update
runs on local JVM
Actually, every java application you can convert to JNLP. Just to sign on all jars that your game contains, create executable jar from your game and create single Web page from where you can download your game
Related
I am maintaining a Spring Boot project. There is this code:
BufferedReader reader = new BufferedReader(new FileReader("./setting_mail_sender.txt"));
Where should the file be located in this case?
In 'the current working directory'. And where is that? Who knows!
Whomever wrote that code messed up. It's not a good idea to use the CWD for anything in any java code unless you specifically know you want it. And generally, that's only the case when you're writing command line tools in the vein of the various tools you find in your average linux distro's /bin dir - a rare occurrence, given that the JVM isn't really designed for that kind of thing.
There are 3 different best practices for 'data files' depending on the nature of the data:
Static, unchanging data - as much part of your app as your class files are. These should be loaded with MyClass.class.getResource("name-of-resource.txt") and shipped the same way your classes are. For example, inside the jar file.
Config files. These should usually be in System.getProperty("user.home") - the user's home dir; /Users/yourusername on macs, /home/yourusername on linux, C:\Users\YourUserName on windows. Best practice is to ship a 'template' version of the settings file if relevant in the jar file, and upon detecting that there is no config file present at all, to write out the template (and you load the template in via MyClass.class.getResource). If a template is not a good idea, something in a similar vein. Bad practice is to have the installer do this, and have your app be broken or leave the user having to peruse complex documentation to (re)create the config file. A different way to do it right is to have a config page in your app (a window, menu bar setting, web app thing - something with a user interface) where you can change settings and the config file is simply the way you store that data.
Changing data files. For example, you ship H2 (an all-java database engine) with your app and it needs to write its database file somewhere. This is a bit tricky; user home is not the right place for such data files, but you can't really 'find' the dir where your app is installed either. Even if you can, on non-badly-designed OSes, apps usually cannot (and should not!) be able to write to that location anyway. The location where this data is stored should definitely be configurable, so one easy way out is to require that the user explicitly picks a place. Otherwise I'm afraid you're stuck having to write per-OS code - find /Users/myusername/Library/Application Support/yourappname on mac, which is the right place. As far as I know there is no library to do this right.
None of them involve 'require that the user start the app with the right CWD'. There are good reasons for that: It can be hard to configure, and it's not something users think of to configure. For example, when setting up a java app as a recurring task in windows, you can configure the working dir for such a process, but it's not something that's usually considered as crucial configuration. When running a java app from the command line, who knows what the working dir is. You'll end up with an app that usually works, except in some circumstances when it magically doesn't, and most of your users have no idea that the difference between the magic run that works and the one that does not, is the directory they were in when they started the java app.
If you can edit that code, do so - figure out which of the 3 different kinds of data this is about (sounds like the second bullet: Config stuff, so should be in user home, and the app's name should be part of the file name) - and fix it. for example, that should be:
try (var in = Files.newBufferedReader(Paths.get(System.getProperty("user.home"), "myapp-mail.conf")) {
}
This solves a whole bunch of problems:
Uses try-with to avoid resource leakage.
Reads from user.home, avoiding current working directory as relevant setting.
Actually uses UTF-8 encoding (whereas your code will, at least until java 17, do 'platform default'. It's somewhat unlikely you want that, as it means your config file is not portable; copying it from one computer to another may break things. You presumably don't want this.
If errors occur, the error messages are improved (one of the downsides of the 'old' file API).
If you can't change this code, figure out what the CWD is; put the files there, and ensure that, however you start this spring boot project, you always start it from that directory. If you can't change this code but you can run some code in that JVM, you can print it: System.out.println(Paths.get(".").toAbsolutePath()) will show it to you.
I have just written a Java program that I now need to publish. I want to make the software easily updatable, and I therefore need your advice. The program will be used by people with minimal technical knowledge, hence usability is absolute key. The program is not open source.
The situation is this:
First time users download a zip-file containing one .jar-file and two folders that should contain the program output files (.xml-files and .png-files). I want to make it as easy as possible for the user to update the .jar (replace it with another .jar, not necessarily at run time). To my help I have a simple web-based Wordpress site that the user will view as the source of the program.
I'll list the possible solutions I've come up with:
1 (fallback solution). The user have to manually go to the Wordpress site where I'll put a separate direct download link (from Google Drive) for the .jar-file. The user then has to manually replace the .jar in the existing folder with the new one.The drawback to this is that it requires too much work from the user, and they program probably won't get updated very often.
2. Alongside the Program.jar in the zip-file the first user downloads, I place another Program-Updater.jar. This new .jar's sole purpose is to, when the user opens it, download a new version of Program.jar from the web and replace the existing one.This is better than the previous option because it requires less work, even though it's not automatic. The drawback is that I need one more .jar which can confuse the user, and most importantly I have no way of updating the Program-Updater.jar.
3. Java Web Start.I've tried reading up on how this works, but I'm wondering if there is a way to get it to work. One possible problem is that I can't really access the host, and to be able to set up the .jnlp the correct way I think you need this. I'm also wondering how the program's file structure would be (is the .jar even placed on the user's computer?) and if this could confuse the user. Also how to make it always work offline.
4. Suggest your own solution!
Any input on this matter would be greatly appreciated, and I'll gladly give more info than I already have.
Cheers
Getdown was the way to go; it is extremely easy to use.
I'll put the .zip on Google Drive with a direct download link to it on my Wordpress site.
The files used by getdown are placed in and downloaded from my public git repo.
I have an application that has an applet that does two simple things:
Download an executable jar file from our server (if the user doesn't already have it) to an specific folder in the user's PC
Execute the jar file with the corresponding parameters
This jar file monitors an Office file for changes and send it back to our server.
The problem is the war Chrome is creating with Java with this NPAPI thing. So I have until September to think of an alternate technology or stop the Chrome support.
Do you think of some other way to achieve the same result? Just download and execute. Doesn't seem that hard =(. Can HTML 5 do that?
EDIT
I was looking into Java Web Start and became a little happy. It appears that it can do what I want: executing a up to date jar file passing parameters. But I never worked with JWS, so I have some doubts:
Is it possible to pass parameters to it? I read about some JSP files that you can configure to do that, but I'm still unsure.
Theoretically, it should start automatically from a browser link, am I right? I tried this site:
https://docs.oracle.com/javase/tutorial/deployment/webstart/running.html
and it didn't work that way. I had to mark "always open files of that type" on Google Chrome. Is there a way for automatize it?
Thanks again!!
From what I know there are at least two things that allow you to stick with Java.
Webstart
Install4
Webstart is provided by Oracle and allows you to download Java program from the web and execute them. Update mechanisms exist, so you can always provide a current version.
Install4J (or any other installer for Java applications that offers an update mechanism) provides an installer which enables your customer to install an application which afterwards will be kept up to date by the integrated update mechanism. But Install4J comes at a price, there might be freeware / open source alternatives. Install4J and its alternatives are often discussed here on SO, you might want to check here.
I think the FileAPI of HTML5 is limited and can not access arbitrary files because a sandbox prevents this. You might check SO again for details about that.
I have developed a command-line (read: no GUI) Java application which crunches through numbers based on a given dataset and a series of parameters; and spits out a series of HTML files as resultant reports. These reports hold a large amount of data in tables, so in order to give the users a easy and quick overview of the results, I utilized the JUNG2 library and created a nice graph.
Here's where it gets interesting; since I would like the graph to be interactive it should be deployed after the application has run and files are generated, whenever the user wants to view the reports. I decided to go with an applet based deployment, however I am not too happy with the current setup due to the following reasons:
I want to make the software as simple to use as possible (my users won't be tech-savvy, and even tech-intimidated in most cases). I would really like to distribute one JAR only, which forced me to put the applet with everything else it needs in a package in the same JAR as the main application.
The applet and the main application need to communicate the results, so I create a xML-based report which is used to hold information. As long as the files are on a local machine and are not moved around it all works fine. Unfortunately I also need the files to be moved around. A user should be able to take the "results" folder to a USB stick, go anywhere plug the stick to another computer and be able to use the report as he/she likes.
For the time being the applets are implemented with the following html code:
<applet code="package.myapp.visualization.GraphApplet.class"
codebase="file:/home/user/myApp"
archive="myApp-0.2.6-r28.jar"
width="750" height="750">
<param name=input value="results/test_name/results.fxml">
</applet>
As you can see this applet will not work if the parent folder is moved to another location.
As far as I know I have a couple of alternatives:
a) Change codebase to point to an URL on our webserver where I could put the jar file. This however creates the problem with permissions, as the applet will not be able to read the results file. Alternative is to upload the results file to the server when the user wants to visualize the graph, although I am not sure if that's a good option due to server security and also if it could be made so that upload happens automatically without bothering the user.
b) I can use a relative path on the codebase attribute, but then the whole folder hierarchy needs to be intact upon copy. This could be a last resort, if I cant come up with a better way to do it.
c) change the deployment method (would like to avoid this alternative to not spend more time on the development phase)
Any ideas? Am I missing something? How could I tackle this problem?
Thanks,
I'm not sure I entirely understand your use-case, but from what I do understand, I would suggest this:
Dump the applet for an application launched using Java Web Start. Have the JNLP file declare a file association for the fxml file type. When the user double clicks an fxml file, it will be passed as an argument to the main(String[]) of the JWS application.
A sand-boxed JWS application can gain access to resources on the local file system using the JNLP API. Here is my demo. of the JNLP API file services.
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.