3 ms·

Ask HN: Companies still allowing Java on the Desktop?

4 points by virmundi 12y ago

I'm about to start a project that needs offline capabilities. The users will work in the field, with no data access until they return to the office. In the meantime, they will modify a local data store of documents. When they return to the office, the changes will be sync'ed into the common data store (their changes pushed out to the company; other changes come to their data store). For the application, I was going to target the JVM. However, I'm unsure as to the viability of that move given Java's recent security issues. Are companies interested in Java-based apps (I know it has to be a desktop app)? Thanks, JPD

smt88 12y ago
1) JRE's security issues are not recent. They've been common and severe for many years, and I don't see any reason to believe that will change. 2) Most companies are willing to use Java, but that doesn't mean it's part of their provisioning process right now. I'd say it's an uphill battle to target JRE. 3) Web apps can also work offline, but your best bet is to try to end up with a cross-platform, standalone executable. There have always been lots of options for this, but I myself haven't tried to write a desktop app in 10 years and am not the person to tell you what to use. A lot of recent apps (like PopcornTime) seem to web apps running on WebKit. Edit: Appcelerator's Titanium product is an incredibly easy way to write simple, native mobile apps. If your users could carry tablets or Chromebooks, this might be something to consider.
brudgers 12y ago
To be honest, if your application adds value that is obvious to a company's leadership [and that's the goal with B2B sales] then nobody will care that it uses the JVM. By which I mean both that the leadership won't care and that the nobodies in IT who might care will be given marching orders regardless of any animosity. The bigger hang up I see with the JVM is for companies that are .NET based. As with the previous paragraph, that's a market analysis question not a technology one. Finally, the security threats to a mostly offline application designed to communicate with a central server are relatively low in comparison to something based on constant internet connection and web technology. Of course, as always, the people designing a system for the JVM need to know what they are doing. In a market where desktop applications make sense, selecting a language that facilitates use on both the JVM and .NET might be a consideration. That's not to rule out targeting the browser, it's all tradeoffs. Good luck.
danpat 12y ago
If the app would otherwise make sense to be web facing, one option that I've seen work quite well is to develop the "app" as a local, packaged web stack. Users point the browser at "http://localhost:10000/" http://localhost:10000/" This has the advantage of removing the native UI toolkit question. This might make it easier to develop a native executable that's easy to package and distribute.
- pjungwir 12y ago
  Ha, I just did this. We built a VirtualBox VM with Vagrant and Chef then distributed the .box file. I think it worked pretty well, and we got good feedback about smooth installs, although there are a few small things I'd do differently to make updates easier.
Beached 12y ago
As an IT manager for 20+ companies, I can say any application that requires third party dependencies is a pain in the arse 3 years from now. Java is definitely the worse for me. Self contained .exe is the future for third party apps IMO. Whatever you choose, packaged it in a way that its either self contained, or it extracts its dependencies into the application folder and is coded to read from there.
bsg75 12y ago
There are some important Java desktop apps I use because I don't run Windows, and Java is often the platform developers use to develop cross platform UIs. Desktop Java apps are probably here to stay for the foreseeable future.
Spoom 12y ago
Crazily enough, you may be able to do all of this in an HTML 5 / Javascript app running on a server, including the offline / syncing components. This assumes you can get users running a relatively recent browser. https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_... Of course, you may have other requirements not listed here that necessitate a more native environment.