javaexe based program does not run normally on Windows 8.1 - java

I created a program using javaexe, a wrapper for Java programs that allows them to be launched by an exe file. This program contains a service part, a taskbar part (they send messages one to another). The program purpose is to send SMS and the list of the SMS sent is available from the taskbar icon.
The program has been working since a few years on a Windows XP computer, but I would like to launch it from my Windows 8.1 laptop computer, and when I launch the EXE, the splash screen is displayed, the service is installed, but the icon in the taskbar does not appear, and the serviceInit method does not seem to be run.
Where does the problem come from? My computer uses Windows 8.1, with Avast! as antivirus and the Comodo firewall. I obviously tested my program having disabled these 2 security programs (Avast! and Comodo) but there is still the same problem.

I use also JavaExe for an interactive service and I tested it on Windows 8.1 Pro (32bits)
with JRE 1.7 and 1.8....and it works fine, manually and automatically (after reboot) : the service running and the taskbar running also and communicates.
My .exe isn't fixed to run always as admin. When I install the service, I right-click and run it "as admin".
But, if I fix the .exe to always run as admin, I just double-click on .exe to install the service, but the taskbar doesn't run automatically after reboot : Windows 8.1 block the applications that automatically run as admin when the user log on.
I tested also the examples of JavaExe (example8 and 23) and it also works.
Have you the same problem with JavaExe's examples ?

Related

JavaFX application "Unable to invoke method" / "Unable to launch JVM"

We've got a JavaFX 2 application developed in NetBeans 8.0.2, being packaged for deployment with WiX 3.9.1208, but we are having a problem on a few seemingly random machines.
After installing, when attempting to run the application, a dialog box is shown with the name of the executable and "Unable to invoke method" in the title. After clicking OK, the same box is shown again but with "Unable to launch JVM" in the title.
We are bundling Java 8u45 32-bit with the MSI, and everything seems to work on most machines, but we have had the above issue a couple of times on users machines, across WinXP, Win7 32-bit and Win8.1 64-bit running on a Mac in Parallels. Doesn't seem to make a difference whether Java is already installed on the users machine or not, and we can't figure out what could we causing the problem.
We haven't customised the WiX deployment in any way, just used what was out the box to start with, and we have very little experience in deploying Java applications.
We've been unable to reproduce this issue on any of our setups. Thanks in advance for any ideas on what could be happening!
Regards,
Richard

OSX Blocking JNLP Launch Java1.8U40 - Anyone Know Why?

We deploy our application as a JNLP launch file and/or as a webpage applet.
I have a customer that updated his MAC OSX system to the latest Java Version 1.8_40. After upgrading the JNLP launch stopped working. It seems to start Java (flashes blue java logo) then stops. No Exception is thrown. I suspect yet another OSX security hurdle.
We adjusted his OSX Security settings to trust our application.
We adjusted his Java security to trust our site.
We also adjusted the Safari preferences to allow the application to run unrestricted ("unsafe mode").
The application is signed with a code signing certificate.
The customer can use the Applet launch method using the safari Java plugin.
All other customers (OSX & Windows) are generally fine.
If this is a new MAC Java issue I'd like to get ahead of it.
Anyone else out there see this? Any clues about what is causing the issue?
Our guess is that the cause of this bug has been backported to 8u40. We find that the application cannot get focus once the new blue Java splash screen is shown. We can also reproduce this on all the demo webstart apps on Oracle's own site, so it isn't our code.
You can confirm this bug by running your webstart instance with -Xnosplash to skip that splash screen. Unfortunately you cannot add that parameter to the jnlp file.
We can only reproduce this problem on OSX 10.10 (Yosemite).
A workaround (if you can control the client Java settings) is to add "-Xdebug" in Java Control Panel -> Java -> View... -> Runtime Parameters.
Update: the bug has been fixed and backported to 1.8u40. Oracle have also silently updated their downloads to the new build (1.8u40b27) as can be seen here I don't know that people already running 1.8u40 will get an update automatically.
When i add '-Xdebug' in the Java Control Panel as a Runtime Parameter it works for me.

Developing Java desktop applications on Microsoft Surface Pro/Pro 2

I have a working Java SWING-based desktop application, and I'm being asked if it can be run on the Microsoft Surface Pro or Pro 2. As I understand it, these are using stock Windows 8/8.1 and will be able to run any Windows app normally, is this correct?
Are there any caveats or special considerations when running my app on these devices?
Edit: If it matters, the JRE would be distributed together with the application, so installing Java isnt an issue.
... will be able to run any Windows app normally, is this correct?
You will be able to run Java programs, but only in Desktop mode after installing the JRE. Java 7 Update 10 added official support. See Java on Windows 8 FAQ.
By default, Java is not installed on the Surface Pro. There is no java.exe or javac.exe when attempting to run from the command line. You have to go to Oracle and fetch it.
I was able to install the JRE on my Surface Pro. The package was installed in C:\Program Files (x86)\Java\jre7\bin. After the install, java.exe -version worked from the command line (after fixing PATH). The install also included an IE plugin, and it appears to have worked with IE 10 from the tablet. I was also able to install the x64 JRE. I did not try to install the JDK.
There may be something offered on the Windows App Store, too. But I don't use the store, so I don't know.

stopping execution in netbeans doesn't stop jvm (under mac osx)

I'm used to run (for testing purposed) java applications from IDE. Start, verify, stop execution in output window in Netbeans. This works flawlessly under linux and windows but under mac osx for reasons beyond me the despite execution being stopped (red stop button greyed out, etc.) the java process persists in the background.
It this some inherent property of mac osx? (most of the applications stay running but I would assume that when I stop java from IDE it should basically kill it)
It is a bug in NetBeans way of launching apps - https://netbeans.org/bugzilla/show_bug.cgi?id=232322

Java web start doesn't launch

On my Windows 7 x64 machine, I'm having problems launching my remotely deployed Web Start app (the Web Start app launches correctly on another PC as expected). In IE or FF, I click on the web start launch link, the JNLP is downloaded, it seems to get executed and nothing happens. I see javaws.exe processes running. I don't see a java.exe running.
I don't know if it's related but I also can't get the java console to run. In the Control Panel Java applet settings, I have have enabled "Show console" and "place Java icon in the system tray". I don't see the Java icon in the system tray either.
I'm running Java 1.6.0_21 (32 bit). I'm able to run Netbeans so the it appears as if Java is installed correctly on my machine. Why isn't web start working?
A firewall on my corporate joined domain was the problem. It was preventing web start as well as other types of apps from working correctly or even launching. Opening ports resolved it.
Are you absolutely certain that your Windows browser is binding the JNLP suffix to the javaws executable?
If you download the file, and double click, does it open correctly? If not, then right click, and investigate what is presented under Open With...
I had the same symptoms when I switched JNLP specifiction to 6.0. So I simply solved it by going back to 1.5, which I think is default in NetBeans, at least up til 6.7.
<jnlp spec="6.0+"...

Categories

Resources