Some relevant background:
My application is a Java app compiled into a .exe via JSmooth. The anticipated user base would likely be a few hundred users, but could grow well beyond that, as it's a community specific application.
How it works:
2 .jar files, one that preforms initial checks, another with the meat of the application.
Ideally, the init jar displays the splash, checks the version in desktop.txt against server.txt, if they differ, it prompts the user to update.
What I need to figure out:
1) What is a cheap, scalable hosting service that I could use as the file host for updates?
2) How can I create an "updater" to actually preform the jar replacement? My current solution is simply writing an updater in Java, but I was hoping for something like the installers people are more familiar with.
All of the research I've done has resulted in lackluster results, as 99% of hosting searches result in site hosting results. I just need an update repository with reasonable security. i.e., decent DDoS resistance and not left wide open to the Internet.
Edit: formatting
Easy to do and very foolish cheap with Amazon S3 or Joyent Manta as both support time-limited signed URLs and headers (which can contain a SHA-1 of the file) to check to see if the update is needed before downloading
On startup your app would check the update URL to see if it has changed. If it has changed, download the JARs. Do this before the app loads classes from those JARs. Updating the updater itself will be trickier so consider that an update might need a new update URL to prevent expiry.
Related
i am currently writing a game on javaFX and i have plans to post it in the website i run in the future (end exploit the Ads while at it). The problem is that after searching around a little it seems there is no way to run a java application on a browser.
Allowing people to run it through the browser would really help sharing the program.
My question is: is there today(2018) any way to run a java application through the web? Though i like java, no browser support seems like a really, really bad idea.
Oh, i also heard of Java Web Start. Although it looks like it is just avoiding the problem (not running in the browser) it seems like a good way to share an application. The problem is that it seems it is (Will be?) deprecated? I am helpless, it is like java isn't even trying anymore...
PS: If it makes any difference my game would be a 2D game with 3rd person view. It will also require some server stuff since players will create "arenas" that others can challenge. I would say my game wouldn't be "simple".
Java Web Start does the job very well—if you are willing to pay for a code signing certificate. (They’re a lot more expensive than regular SSL certificates.) The idea is that a user clicks on a hyperlink on your page, which causes the user’s Java installation to launch your application (possibly after installing it). This requires users to have Java installed beforehand.
If you don’t have the resources or desire to go with a code signing certificate, you can look at https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm. It allows you to create native installation packages for JavaFX applications. The disadvantage: You need each platform to create an installer for it. Meaning, you need Windows to create a Windows installer, OS X to create an OS X installation image, and Linux to create a Linux package. Some may also require signing using native tools.
Java 9 includes the jmod and jlink tools, which are capable of creating a file tree with an executable shell script or .bat file. A major advantage is that you can build such a tree for any platform, regardless of your own platform, if you unpackage the foreign platform’s JDK on your machine. Another advantage is that the user doesn’t need to have Java installed at all. A disadvantage is that the script requires a terminal, unless running on Linux.
Of course, you can just go the manual route and distribute a zip file which contains your .jar file(s), a shell script you’ve written, and a .bat file you’ve written. It’s not elegant, but it’s better than nothing. But it may trip up some non-technical users.
There exist a number of tools which create a native executable from .jar files, but I am not familiar with them (and I prefer to avoid third party tools unless they are truly necessary).
Whatever approach you choose, the answer is the same: You distribute something on your web page which the user downloads and runs. Aside from the download process, the browser is not involved.
What you can’t do is have users run your application inside the browser. That is deprecated, with good reason: It’s a disaster for the browser performance, for the Java runtime, for security, and for the user experience. And Firefox has all but banned plugins, so you’d be locking out a substantial percentage of users.
We have a VPN network and at a central point we have kept a java application (.jar file). We are allowing users of the VPN system to use this application- What are the cons of using this solution?
As for pros -
Easy to update to a new version
Storing the files in relative location helps save files in a central location
EDIT
Is it possible to access the COM ports using JWS since our app runs inside a sandbox?
I think what you describe would work well with Java Web Start - advantages I can think of
reduced bandwidth usage (JWS will only download files if they have been updated, if not it will use a local cached copy).
possibility to use specific JVM parameters.
automatic check of the client configuration (for example, JRE version must be at least xxxx, if not download it).
There are probably more.
It's okay. For a customer project, we choosed this solution too.
Its okay, if you have a good bandwith and, on traffic producing apps, a low latency at runtime.
For a test, I build a Sql-Wrapper, to add a simulated latency to each call to our database. So we're got a feeling for the application at runtime without a real vpn connection.
I have a program that I want to distribute, without giving the source code or database used. It's an sqlite database, and doesn't need to be updated. I tried using eclipse fatjar and changing where to look for the jar, but when I run the program, it just creates a blank database file in the same directory as the jar. I just want one file that I can distribute.
From comments deemed relevant:
..include an XML after tested with a TXT file.
I would, but this database is 80,000 lines long, and has 4 columns. It's only going to get bigger too, with updates to the program, not during runtime.
Put it on a server and have a web interface.
I want to avoid using any internet connection really. If someone wants to decompile the jar, whatever I don't care. I just want it to work from double click, and no extra files laying around.
(deployment) ..usability and neatness is important for me
That makes me think that what is really needed for this is a cross-platform installer. The user gets one file and double clicks it, 'follows the prompts' (if any prompts are required) & it extracts the app. ready for use.
It might create multiple files, but this will be largely invisible to the end user. 'Out of site is out of mind'.
I want to avoid using any internet connection..
I recommend you rethink that. What size does the app. come to when Jar'd? A couple of megabytes? That is nothing in this day and age of internet traffic. That's a 2 minute YouTube.
The ratio of devices having internet connections to machines having (for example) CD/DVD drives to load software is also changing. It is coming to a time when more machines capable of running J2SE have internet connections than have drives. I have a desktop PC and a Netbook that can both run J2SE. Both have an internet connection, but only the desktop PC has CD/DVD drives.
If that is the case (getting to my point) look to Java Web Start to deploy the app. and DB. Very user friendly, with good desktop integration.
it's about 50mb, but the problem is not all end users will have access to internet at all times. Distributing the application can be done through the internet, but I don't want to rely on it for accessing the database or loading the application all together.
That is not necessary. JWS caches the application resources locally. It will check the server for updated Jars, but can be configured to allow launch from the cached copy even if there is no internet connection at that moment. The launch file element to configure that would look something like:
<update check="always" policy="prompt-run">
Don't know whether you can do this with a SQLite database, but Derby supports jar: paths: http://db.apache.org/derby/docs/dev/devguide/cdevdvlp17453.html
Alternatively, extract the database from the jar to the filesystem upon launch and point there.
I think you can do the following:
Package your database on the classpath.
When the app loads, copy the database to some temporary directory (like /tmp)
Instruct sqlite to read it from there (by setting the jdbc url)
Add a jvm hook to delete the file when the app gets closed.
That should work like a charm.
Hint:
Use getClass().getResourceAsStream(); to get the reference of the file on the classpath.
I've got an applet that is rather large (4MB) on a web page used by a few thousand users scattered across a WAN. Bandwidths to these users range from a paltry 128Kbps to 10Mbps.
The problem occurs when a new version of the applet is made available; it is downloaded automatically by all the users browsers effectively chocking the network.
They really hate 'release day' morning around here :)
Is there any strategy to work around this problem?
Edit: I can only serve this applet centrally from one pair of servers. I cannot make any modifications to the hosting or network infrastructure.
Here are some ideas:
Divide your user community into N equal groups, and provide a different applet URL for each for group. Then stagger the times at which each group's copy of the applet is updated.
Put the applet on a server that has been tweaked to lie about the applet's modification date, and use this to (crudely) throttle the rate at which browsers fetch the updated applet.
Push the applet to locations on the local networks of large groups of users. Have the central server issue HTTP redirects so that each browser picks up the applet from a "close" location.
Deploy caching HTTP proxies & autoproxy files on the local networks, and block direct access to the applet forcing the users to get the applet via the proxies.
The last option is probably the best.
Apart from what Stephen C mentions, I'd like to add another strategy that you should consider.
Consider breaking your applet codebase into different modules (archives)
These modules are updated instead of the entire 4MB applet. You can have a special classloader that checks if a new version of a given module is available.
For patches have a separate "patch" archive that loads before any other archives so that any updated classes are loaded from the patch archive instead of the older already downloaded archives.
The java web start already does some of these things to avoid entire updates. You can take a look the link (developer documentation) for a few pointers.
If you can put a .htaccess in the directory you can add expiresByType so that the client doesn't ask the server everytime.
Have you looked at pack200? and (pack200 + .htaccess)
Have you looked at indexed Jar?
Anthony
Internet Explorer has a file download limit of 4GB (2 GB on IE6). Firefox does not have this problem (haven't tested safari yet)
(More info here: http://support.microsoft.com/kb/298618)
I am working on a site that will allow the user to download very large files (up to and exceeding 100GB)
What is the best way to do this without using FTP. The end user must be able to download the file from there browser using HTTP. I don't think Flash or Silverlight can save files to the client so as far as I know they won't cut it.
I'm guessing we will need an ActiveX or Java applet to pull this off. Something like the download manager that MSDN uses.
Does anyone know of a commercial (or free) component that will do that? We do not want the user to have to install a "browser wide" download manager (like GetRight), we want it to only work with downloading on our site.
Update: Here is some additional info to help clarify what I'm trying to do. Most of the files above the 4GB limit would be large HD video files (its for a video editing company). These will be downloaded by users across the internet, this isn't going to be people on a local network. We want the files to be available via HTTP (some users are going to be behind firewalls that aren't going to allow FTP, Bittorrent, etc.). The will be a library of files the end user could download, so we aren't talking about a one time large download. The will be download different large files on a semi-regular basis.
So far Vault that #Edmund-Tay suggested is the closest solution. The only problem is that it doesn't work for files larger than 4GB (it instantly fails before starting the download, they are probably using a 32bit integer somewhere which is exceeded/overflown by the content length of the file).
The best solution would be a java applet or ActiveX component, since the problem only exist in IE, that would work like the article #spoulson linked to. However, so far I haven't had any luck finding a solution that does anything like that (multipart downloads, resume, etc.).
It looks like we might have to write our own. Another option would be to write a .Net application (maybe ClickOnce) that is associated with an extension or mime type. Then the user would actually be downloading a small file from the web server that opens in the exe/ClickOnce app that tells the application what file to download. That is how the MSDN downloader works. The end user would then only have to download/install an EXE once. That would be better than downloading an exe every time they wanted to download a large file.
#levand:
My actual preference, as a user, in these situations is to download a lightweight .exe file that downloads the file for you.
That's a dealbreaker for many, many sites. Users either are or should be extremely reluctant to download .exe files from websites and run them willy-nilly. Even if they're not always that cautious, incautious behaviour is not something we should encourage as responsible developers.
If you're working on something along the lines of a company intranet, a .exe is potentially an okay solution, but for the public web? No way.
#TonyB:
What is the best way to do this without using FTP.
I'm sorry, but I have to ask why the requirement. Your question reads to me along the lines of "what's the best way to cook a steak without any meat or heat source?" FTP was designed for this sort of thing.
bittorrent?
There have been a few web-based versions already (bitlet, w3btorrent), and Azureus was built using java, so it's definitely possible.
Edit: #TonyB is it limited to port 80?
Please don't use ActiveX... I am so sick of sites that are only viewable in IE.
My actual preference, as a user, in these situations is to download a lightweight .exe file that downloads the file for you.
Can you split the files into pieces and then rejoin them after the download?
If you don't want to write java code in-house, there are commercial applet solutions available:
Vault
MyDownloder
Both of them have eval versions that you can download and test.
A few ideas:
Blizzard use a light-weight .exe BitTorrent wrapper for their patches. I'm not entirely sure how it is done, but it looks like a branded version of the official BitTorrent client.
Upload to Amazon S3, provide the torrent link of the file (all S3 files are automatically BitTorrent-enabled), plus the full HTTP download link as alternative. See S3 documentation
What about saying "We recommend that you install Free Download Manager to download this file. You will have the added benefit of being able to resume the file and accelerate the download."
Personally I never download anything using the built in browser download tool unless I have to (e.g. Gmail attachments)
#travis
Unfortunately It has to be over HTTP inside the users browser.
I'll update the question to be more clear about that.
#levand
The problem only exist in IE (it works in Firefox) so while ActiveX would only work on IE, IE is the only one we need the work around for.
#travis - interesting idea. Not sure if it will work for what I need but I'll keep it in mind. I'm hoping to find something to integrate with the existing site instead of having to go out to a third party. It would also require me to setup a bittorrent tracker which wouldn't be as easy as it sounds for this application because different users will have different access to different files.
#jjnguy
I'm looking for a java applet or ActiveX component that will do that for me. These are non-technical users so we really just want to have them click download and the full file ends up in the specified location
#ceejayoz
I totally agree but its part of the requirement for our client. There will be FTP access but each user will have the option of downloading via HTTP or FTP. There are some users that will be behind corporate firewalls that don't permit FTP
I have seen other sites do this in the past (MSDN, Adobe) so I was hoping there is something out there already instead of having to make one in house (and learning java and/or ActiveX)
I say click-once installed download manager, similar to msdn.
But becoming a CDN without a more optimized protocol for the job is no easy task. I can't imagine a business model that can be worthwhile enough to have such large file downloads as a core competency unless you are doing something like msdn. If you create a thick client, you at least get the chance to get some more face time with the users, for advertising or some other revenue model, since you will probably be paying in the hundreds of thousands of dollars to host such a service.
The problem with the applet approach mentioned is that unless you have the end user modify their java security properties your applet will not have permission to save to the hard drive.
It may be possible using Java Web Start (aka JNLP). I think that if it is a signed app it can get the extra permission to write to the hard drive. This is not too different from the download an exe approach. The problem with this is that the user has to have the correct version of Java installed and has to have the Java Web Start capability setup correctly.
I would recommend the exe approach as it will be the easiest for the non-technical users to use.
There are some users that will be behind corporate firewalls that don't permit FTP...
Are users with restrictive firewalls like that likely to be permitted to install and run a .exe file from your website?
Take a look at cURL. This article describes how to do a multi-part simultaneous download via HTTP. I've used cURL in the past to manage FTP downloads of files over 300GB.
Another tip: You can boost download times even more if you increase the size of the TCP Window on the client's NIC configuration. Set it as high as the OS allows and you should see up to 2x improvement depending on your physical network. This worked for me on Windows 2000 and 2003 when FTPing over a WAN. The down side is it may increase overhead for all other network traffic that wants only a few KB for a network packet, but is now forced to send/recv in 64KB packets. Your mileage may vary.
Edit: What exactly is this you're trying to accomplish? Who is the audience? I'm assumed for a bit that you're looking to do this over your own network; but you seem to imply the client side is someone on the internet. I think we need clearer requirements.
Create a folder of files to be downloaded on the server where the document service is running (either using Linux commands or using java to execute shell commands)
Write the file to be downloaded to this folder (using Linux command or Java shell command is OK). Considering the efficiency of program execution, WGet command is used here
Package the downloaded folder as a zip file (using shell command), configure nginx agent, return the access file path of nginx to the front end, and then download from the front end.