Java app on windows 8 tablet being killed when screen turns off - java

We had to write a Java application which runs on a windows 8 tablet (not RT).
I would much rather have written it using C#, but we really didn't have a choice.
Basically, we use launch4j to wrap our installer executable JAR in an EXE which then installs the appropriate application files and creates shortcuts on the desktop and in the start menu programs folder to ensure that the user sees the icons on the metro start screen.
The Problem
When the application starts up, it checks if any updates are available via a server, if they are available they are downloaded.
The issue that we've seen is that if the application is downloading the updates, and then we turn off the screen and leave it off for at least 30 seconds, once we turn the screen back on, the application is frozen and does not progress.
We then have to kill the app and start it again.
Providing the screen is not turned off again, the downloads finish and the application works fine.
Is there a way to either keep the screen on, keep our process running or detect when the screen comes back on and execute some code when that occurs?
Any help would be greatly appreciated.

Related

JNLP only starting when Java console is shown?

I have Java version 8 Update 261 on a 64 bit Windows 10 system.
What I did:
downloaded and executed a jnlp file
the application was installed in the Java cache and a desktop icon was created
the application was starting
So far, so good.
Now, after closing the app and double clicking that desktop icon - nothing happens.
However, in the Task-Manager I see that the Java Web Launcher is running. And every further double click starts another instance of it, but on the screen I see nothing.
To get the application running properly again, I can either
clear the Java cache with hook at "installed applications and applets" set:
The desktop icon is removed, the above procedure can then be repeated and works like a charm.
or show the Java console
In this case double clicking the desktop icon works! The Java console opens and after some seconds the application is starting.There's no need to clear the cache anymore.
I understand that clearing the cache can solve manifold issues, but what effect has the simple "show console" here?

How do you write a silently self-starting, long-running, time-triggered Java desktop application without registering it as a Windows service?

I'm trying to build a report-building tool (which has a UI written in JavaFX) that has the following features:
When the system (re-)boots, it should auto-start in the background (without showing the UI)
It should have an icon in the system tray
The UI should only show when the user clicks on the system tray icon
A report should be generated either once a day/week/month, at a specific time, automatically
It should "snooze/sleep" in the interim period and use minimal resources while it awaits the next trigger time
It should show a toast pop-up / Windows notification / whatever when a new report has been generated
(The bold ones are the real problems, the italics are maybe solvable--given some resources I found--and the un-formatted one I have a work-around for, namely to place it on in the Startup folder in the AppData folder of the users' machine.)
But the clincher is the following: due to my company's policies, I'm NOT allowed to build register it as a Windows service. Also, converting it into a web service, placing it on a server, and using Control-M (or a cron expression) are also off the table. (That's a long story for another day.) I'm not sure how to implement it and I've been stuck on this for a bit.
I've taken a look at Quartz, this other StackOverflow question, and some other resources on how to run the Java app in the background, but most resources tell me to add it as a Windows service and I keep hitting a brick wall. Also, I don't know how much of an effect the application would have on the users' machines if I ran the application in the background with the solutions mentioned in the other StackOverflow answer. I need to have a minimal processing footprint in the interim period.
I'm also unsure of how to package the application as an EXE. For now, I'm going to turn it into an executable JAR. (Any help on this would also be welcome.)
I'm open to any suggestions and ideas and even other resources to look at for further reading. Anything to help me out here is welcome.

Netbeans RCP application not working outside the IDE when built as OS independent zip

I am building a statistical analysis application on Netbeans RCP for solving tests faster and with less effort https://github.com/PaulMaxAvalosAguilar/Statistikos-Klubas.
The thing is very simple:
1.-There's a module called TrabajosViewer which uses the nodes API to display workspaces where you can organize your samples with some meaningful name, first you create a workspace and then you add some data to it.
2.- You open editor top component which calculates some descriptive satistics stuff for all the sample you entered
3.- All stuff you need for a test is done! Samples are stored in an embedded H2 database(datos module) and results are calculated each time you click on a TrabajosNode.
However when I was testing the app I had to add the following sample:
https://1drv.ms/t/s!AkZmosJJMvdIu3c_IiVkD6JAVVgk (3344 elements); as the app had multithreading capabilities everything was fine, except that after building a release as OS independent zip the app froze from the swing Top Component which was very rare as that wasn't happening on inside Netbeans IDE. I think it has something to see with the build script since I built a Gradle version an everything worked fine https://github.com/PaulMaxAvalosAguilar/Statistikos-Klubas2
If you have an app - any Java app really, not just NetBeans RCP - and it freezes then what you want to do is obtain a thread dump. The thread dump will almost always give the clue as to why there's a freeze.
Java has 5 or 6 different ways to obtain a thread dump for a running application (just google it). Out of these methods, the one preferred is the so-called Ctrl-Break method because it is the one which gives most information. The downside of the method is that you need to have started your application from a console window. But if you can consistently replicate the freeze, then I don't think that's a problem for you. Here's what you would do if you are on Windows:
Start cmd.exe
From the command window, start your application, e.g. bin\sillyapp64.exe.
Wait for the freeze to happen on your application
Now press Ctrl-Break in the command window. This will give you a thread dump printed into your command window.
Upload the thread dump as part of your question. (or host it somewhere if it is too big)
Instructions for Linux/MacOSX are similar albeit in step 4 you would instead send your process a QUIT signal using the kill command.

Swing app freezes in dual screen windows 7 environment when moving app to top right hand corner of second monitor

I built this Swing app to help my girlfriend get a particular job done faster. On my dual monitor windows system, the app and the Operating System freeze when moving the app to the extreme right hand side of the second monitor. Windows recovers, but the app does not. Has anyone experienced this sort of issue and know how to solve it? Below is the github link to the source code.
I tried to also provide a screenshot of the frozen app and the OS but it is difficult to take one when the OS freezes.
The app works fine on her Mac.
https://github.com/johndeverall/BehaviourCoder

restart java.exe from an applet

I have an applet packaged with a third part dll (from JTwain). My applet scans documents from the TWAIN compatible default printer. The applet fails on a paper jam and won't recover. The user navigates away from the page and the applet is destroyed. When returning to the page it fails again. Closing the browser (which kills java.exe process on the pc), and then returning to the page clears the problem and everything works.
I want to restart everything without requiring users to close down the browser. I've added a GUID query string to the URL's from which the applets resources are loaded - so I know nothing is being cached. I've checked in the windows task manager and there is no process created by the dll, it's all happening within the main java.exe process. I tried wrapping the scanning process in a thread so I could interrupt it in the stop or destroy methods (just in case the applets thread weren't stopped when the applet was destroyed), but that didn't work.
Any suggest would be greatly appreciated. Ideally I'd like some way to restart java when the applet unloads (but I doubt that's possible).
UPDATE
I've spent a couple of days trying to identify what causes the applet to fail. I still don't know :(
When the paper jam occurs something (not my code), is producing a couple of popups. The first alerts the user of the jam, and can be closed by clicking the OK button. The second says 'reading from device' and hangs. It cannot be close with the red, close window, icon in the top corner - I kill it from the task manager and windows asks to send a report regarding the 'non-responsive program'. I assume these popups are produced by the dll. And given that the second hangs, my assumption is that a thread started by the dll has hung while retaining a lock on some component of the TWAIN application. I get
com.asprise.util.jtwain.JTwainException: Failed to open the specified data source:
Source: TW-Brother MFC-9970CDW LAN Thrown
..when I try to access the scanner.
I'm at a bit of a loss as to how I can get more information. I'm testing my applet on a windows virtual pc (so as to use ie7), and don't have a method for step debugging in this environment. (And it's crashing on third party code for which I have no source anyway)
I see only two practical options here:
Use an API that handles paper jam without problems. Of course, that is easy to say (get robust API), harder to find.
Launch the app. free floating using Java Web Start. If it freezes up, the user can kill it and click the link for another instance in a new JVM. Or the applet might also call BasicService.showDocument(URLof.jnlp) if it can detect a problem with the DLL and is not itself frozen.
Of course, you should also report the bug to the ..Asprise(?) developers. The optimal solution would be to have the problem fixed at its source. Anything we do here is a 'workaround'.

Categories

Resources