Java Control Panel Proxy Settings - where are they stored? - java

I have... a situation. Imagine you have many, many PCs (Windows 7 to 8) that run a Java Application which is started by using a .jnlp. Now finally there has been a version-jump from java 6 to 8 (took way to much time), and suddenly this application wont start any more (can't parse first jnlp, javaws tells me).
To solve this we have to insert the correct proxy-setting inside java-control panel (wasn't necessary with the old version).
So... doing this by hand is a task that most users can't perform (sadly their level of knowledge isn't sufficient), but doing ths by myself at all PCs would take... uh... a really long time.
So we decided to create a little batch-file, that does perform all the stuff necessary (installing latest jre, clearing cache and so on) which just has to be runned once at every users PC. In Theory.
We were able to place all steps necessary in that .bat, except for setting the proxy at the java control panel. I wonder if this is possible at all. The javaws arguments don't contain such an argument, and I wasn't able to find a physical storage whatever inside the jre or the java cache.
And I can't use these -dHTTP.xxx.... flags for that .jnlp file I'm afraid, because that java webstart is the one that need to know the correct proxy-settings, not the application.
So is there a way to change the proxy setting you can access with the java control panel by some command line argument or something like this, enabling myself to complete this "all new" script?
Greetings, ConfusedMerlin

Java control panel settings are located in %userprofile%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
to add proxy you can use something like
(
(echo(deployment.proxy.bypass.local=true)
(echo(deployment.proxy.type=1)
(echo(deployment.proxy.http.host=10.10.10.10)
(echo(deployment.proxy.http.port=10)
)>>"%userprofile%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties"
though if there are already set proxy you'll need to replace the data.

Related

Run an application made on java(FX) on a webpage

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.

Automated updates for Java applications [duplicate]

I would like to implement a java application (server application) that can download a new version (.jar file) from a given url, and then update itself at runtime.
What is the best way to do this and is it possible?
I guess that the application can download a new .jar file and start it. But how should I do the handover, e.g. know when the new application is started and then exit. Or is there a better way to do this?
The basic structure of a solution is as follows:
There is a main loop responsible for repeatedly loading the latest version of the app (if required) and launching it.
The application does its thing, but periodically checks the download URL. If it detects a new version it exits back to the launcher.
There are a number of ways you could implement this. For example:
The launcher could be a wrapper script or binary application that starts a new JVM to run the application from a JAR file that gets replaced.
The launcher could be a Java application that creates a classloader for the new JAR, loads an entrypoint class and calls some method on it. If you do it this way, you have to watch for classloader storage leaks, but that's not difficult. (You just need to make sure that no objects with classes loaded from the JAR are reachable after you relaunch.)
The advantages of the external wrapper approach are:
you only need one JAR,
you can replace the entire Java app,
any secondary threads created by the app, etc will go away without special shutdown logic, and
you can also deal with recovery from application crashes, etc.
The second approach requires two JARs, but has the following advantages:
the solution is pure Java and portable,
the changeover will be quicker, and
you can more easily retain state across the restart (modulo leakage issues).
The "best" way depends on your specific requirements.
It should also be noted that:
There are security risks with auto-updating. In general, if the server that provides the updates is compromised, or if the mechanisms for providing the updates are susceptible to attack, then auto-updating can lead to a compromise of the client(s).
Pushing a update to a client that cause damage to the client could have legal risks, and risks to your business' reputation.
If you can find a way to avoid reinventing the wheel, that would be good. See the other answers for suggestions.
I am currently developing a JAVA Linux Daemon and also had the need to implement an auto-update mechanism. I wanted to limit my application to one jar file, and came up with a simple solution:
Pack the updater application in the update itself.
Application: When the application detects a newer version it does the following:
Download update (Zipfile)
Extract Application and ApplicationUpdater (all in the zipfile)
Run updater
ApplicationUpdater: When the updater runs it does the following:
Stop the Application (in my case a daemon via init.d)
Copy the downloaded jar file to overwrite current Application
Start the Application
Cleanup.
Hope it helps someone.
I've recently created update4j which is fully compatible with Java 9's module system.
It will seamlessly start the new version without a restart.
This is a known problem and I recommend against reinventing a wheel - don't write your own hack, just use what other people have already done.
Two situations you need to consider:
App needs to be self-updatable and keep running even during update (server app, embedded apps). Go with OSGi: Bundles or Equinox p2.
App is a desktop app and has an installer. There are many installers with update option. Check installers list.
I've written a Java application that can load plugins at runtime and start using them immediately, inspired by a similar mechanism in jEdit. jEdit is open source so you have the option of looking to see how it works.
The solution uses a custom ClassLoader to load files from the jar. Once they're loaded you can invoke some method from the new jar that will act as its main method. Then the tricky part is making sure you get rid of all references to the old code so that it can be garbage collected. I'm not quite an expert on that part, I've made it work but it wasn't easy.
First way: use tomcat and it's deploy facilities.
Second way: to split application on two parts (functional and update) and let update part replace function part.
Third way: In your server appliction just download new version, then old version releases bound port, then old version runs new version (starts process), then old version sends a request on application port to the new version to delete old version, old version terminates and new version deletes old version. Like this:
This isn't necessarily the best way, but it might work for you.
You can write a bootstrap application (ala the World of Warcraft launcher, if you've played WoW). That bootstrap is responsible for checking for updates.
If an update is available, it will offer it to the user, handle the download, installation, etc.
If the application is up to date, it will allow the user to launch the application
Optionally, you can allow the user to launch the application, even if it isn't up to date
This way you don't have to worry about forcing an exit of your application.
If your application is web based, and if it is important that they have an up to date client, then you can also do version checks while the application runs. You can do them at intervals, while performing normal communication with the server (some or all calls), or both.
For a product I recently worked on, we did version checks upon launch (without a boot strapper app, but before the main window appeared), and during calls to the server. When the client was out of date, we relied on the user to quit manually, but forbid any action against the server.
Please note that I don't know if Java can invoke UI code before you bring up your main window. We were using C#/WPF.
If you build your application using Equinox plugins, you can use the P2 Provisioning System to get a ready-made solution to this problem. This will require the server to restart itself after an update.
I see a security problem when downloading a new jar (etc.), e.g., a man in the middle attack. You always have to sign your downloadable update.
On JAX2015, Adam Bien told about using JGit for updating the binaries.
Sadly I could not find any tutorials.
Source in German.
Adam Bien created the updater see here
I forked it here with some javaFX frontend. I am also working on an automatic signing.

Simple and flexible method to run java as a windows service

I read SO q&a about launch java as windows service wrappers, but can't find/choose product, suitable for my requirements :
Wrapper reads all java launch parameters from config file. In registry must be only commands to run wrapper itself - path to exe and maybe path to config. Always grant admin rights to change app parameters in registry is not comfortable.
Working dir and path to application also must be in config. I want to place all wrapper files deep into program, because user not intrested in it.
No dependencies(.net, python, etc). I don't want to extend requirements of my program.
Free for every windows OS, include win64.
Simple and lightweight. Size of my program with all 3rd party jars is 12Mbytes. I don't want to add 20Mbytes wrapper.
Automaticaly restart if app process dies.
Preferably single exe files for all windows platform.
I try and lookinkg throught different wrappers and tired a bit. Best suitable till now is:
jslwin (http://jslwin.sourceforge.net), but i don't know how mature it is(version 0.99). Also parameter lists in config is a bit complex(need to edit parameters quantity).
winrun4j (http://winrun4j.sourceforge.net), but i don't know how mature it is(version 0.45). Also it needs a special class for working as a service.
Also i try or look throught:
YAJWS (http://yajsw.sourceforge.net/) too big (30mb), can't make it work with custom files layout.
Advanced Installer (http://www.advancedinstaller.com) too big (50mb).
nssm (http://nssm.cc/) store launch parameters in registry(no config)
winsw (https://kenai.com/projects/winsw) .net required, stops after process dies
commons-daemon, procrun (http://commons.apache.org/proper/commons-daemon/index.html) store launch parameters in registry(no config), can't understand this product, i think it's complex.
jsmooth (http://jsmooth.sourceforge.net) complex and old(last update 2007)
javaservice (http://forge.ow2.org/projects/javaservice/) old (last update 2006)
runasservice (http://runasservice.sourceforge.net/) requires .net
windows rktools - sc, instsrv, srvany (http://support.microsoft.com/?scid=kb%3Ben-us%3B137890&x=16&y=7) - store launch parameters in registry(no config)
jwrapper (http://www.jwrapper.com/) seems not what i need. It packs java program in exe file with JRE. It's not about windows services.
firedaemon (http://www.firedaemon.com/) not free. And maybe it's not what i need.
launch4j (http://launch4j.sourceforge.net/) cool ability "search or download java". Maybe i add something like this to simplify installation, but it is still not about subj.
Java service wrapper (http://wrapper.tanukisoftware.com/) not free for win64.
Tell me please which wrappers suits my needs? Or maybe i think wrong about wrappers above and some of them suits my needs to?
I have had similar issues over the years. Its not that they all are inferior, its that they are all pretty hard to integrate nicely with your own project.
You may want to check out stork: https://github.com/fizzed/stork
It'll help create launchers for your Java console or daemon apps, and they will work across all major platforms. There is also a maven plugin in case you wanted to tie it into your existing build process.
I'm not sure if JWrapper will fulfil all the requirements like 1 and 2 in the way that you want it since rather than you dictating how it does the launch and where it puts things etc JWrapper instead handles that stuff in its own way but it does produce executables for win/mac/linux and more importantly it does support windows service installation as well as macos and linux daemon installation:
http://www.jwrapper.com/guide-installing-a-service.html
The service support though is for paid licenses, the free version doesn't currently support it.
Disclosure: I work for JWrapper

Java IDE for working over Remote Desktop

I have recently found out that anything Swing(NetBeans, IDEA) is excruciatingly slow to paint the UI over Remote Desktop(RDP).
Can you guys give me any suggestion for something that will work properly over RDP?
Actually, contrary to everything I've seen - mostly the "Dsun.java2d.noddraw=true", which is mentioned in a number of places, it is actually setting it to false that fixed the drawing issues(for me at least). Go figure.
RDP is optimized for native Windows apps and, regrettably, newer versions of RCP (like Vista/Win7's default RDP) is even more hostile to non-native apps than older (XP/Server 2003) versions. Here's a good link:
http://devnet.jetbrains.net/thread/280673
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4204845
One workaround is to get a screaming fast CPU/graphics board, tons and tons of memory and a super high-speed network connection :)
Another is to:
Select "32-bit true color" in your Terminal Services settings
Select "Modem"
Reduce screen resolution (heck, use 1024x768 if possible)
Here are some additional tips:
http://www.codinghorror.com/blog/2006/04/remote-desktop-tips-and-tricks.html
Try setting "Dsun.java2d.noddraw=true"
http://ubuntuforums.org/archive/index.php/t-1129187.html
http://www.mindfiresolutions.com/Solving-DIRECT-DRAW-ddraw-problems-in-Java-Swing-730.php
I am launching a java swing application from Linux, and display it as a Windows frame thanks to MobaXterm.
If you haven't done it already, please have a look at the following documentation :
https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html
Using -Dsun.java2d.noddraw=true did not fixed my issue, but setting xrender to true did.
So here's the code I used on Linux :
export _JAVA_OPTIONS='-Dsun.java2d.xrender=true'
java -jar my_java_application.jar
Maybe it's not only Swing that paints slow over Remote Desktop. However, Eclipse is based on SWT, based on native widgets, so it is not Swing.
You should give JavaWIDE a try. It is an IDE designed for access to a JDK without it installed on a system, with a built-in storage system so you just need access to the internet. It's not exactly a program for accessing everything on the computer but it will do a good job with your programming. It may take a while however, as the compiling is done on a separate server.

Fake X11 display?

I have a Java program using AWT which I would like to run on a headless system. The display for the program does nothing other than display stats. When the program finishes, it exits. There is no user interaction on the display. The program creates an output file which I use in my build system.
Is there a way to get the Java program to run without an X11 display configured? Can I force Java to run the program without trying to display anything? I do not have access to the source code (it is just .jar file), so I can't make modifications to the source.
Any thoughts on how I could get this to work?
The underlying question here is how to run Java applications without an X server; providing a "fake" X server is only one option. In Java 1.4 and up, you can do the following:
java -Djava.awt.headless=true
This allows applications which use AWT to run on headless systems even without an X server.
Xvfb can do what you ask for. I've not used it myself, but here is a link to wikipedia: http://en.wikipedia.org/wiki/Xvfb
You can use a vncserver.
vncserver :1001
export DISPLAY=localhost:1001
java..
The added advantages is that you can actually view the gui
using vncserver 'just in case'
Could also run Xvnc in a low resolution and color depth.
As mentioned by Charles Duffy the traditional method is to tell Java to go headless.
Note that you can always mount the jar in Eclipse and use jad+jadclipse to see what it actually does, and perhaps even override a class if you need to by putting another class-file in "front" of it in the classpath.
A facility that might be relevant if the program uses Java2D is that newer Java versions use optimizations in the X11 server to render faster. This alone might be a reason to devote an X11 server attached to a high performance graphics card to your graphics processing.
I've used with great success in the past the PJA libraries, they don't seem to be maintained anymore, but then again, just just want to run...
I was able to get headless mode in OpenJFX with the command line arguments
-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw

Categories