• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Java.io, Jars, and Windows Task Scheduler

 
Greenhorn
Posts: 27
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is regarding the quirky behavior of running jars with Windows Task Scheduler where the application uses java.io.

I have many tasks set up in Windows Task Scheduler, some of them run node scripts, some of them run java jars. They all run according to the specified triggers without problem, except for a task which uses this one unruly jar. The task in question is configured correctly, no differently than any of the others which run successfully (and the other jars also produce logs, and read and write files with one minor difference noted below).

The specific problem is Task Scheduler reports "The operation completed successfully." but the application appears as if it hadn't started (logs and output file missing). And it's very confusing because it will produce the desired results infrequently but normally it does not. Event Viewer offers no insight into any possible problem sources.

I've been scouring the internet to find other people who've had similar problems with jars and Task Scheduler. And that led me back here to the good 'ol Java Ranch. Specifically, this topic
https://coderanch.com/t/570071/engineering/schedule-jar-file-windows-task

The OP noted the jar runs when java.io is not used and my problematic jar had java.io imports in the main class (my other jars which ran without issue did not have any java.io imports in the main class). The few lines of code using java.io were moved from the main class to another class and all imports deleted. The application started running again, producing the logs and output file. But why, I ask?

Can anyone offer any insight as to what is possibly going on? Is there a known quirk running jars in Task Scheduler when using java.io in the main class? Is there some type of conflict between the JVM and Windows?
 
Saloon Keeper
Posts: 2806
367
Android Eclipse IDE Angular Framework MySQL Database TypeScript Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I sounds like to the resolution for the problem in the other thread was to specify the working directory for the application; presumably a location where the application would have permissions to perform the java.io operations.  Have you tried that already?
 
David Gillette
Greenhorn
Posts: 27
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ron, thanks for responding.

Yes, I did specify the working directory, as well as double and triple check all of the task settings to make sure everything was set up correctly. Permissions are set up correctly. It's all good. The other tasks which run jars are set up the exact same way and they don't have the same problem, and they do very similar things all on the local machine - reading and writing and web stuff. Event Viewer doesn't show any abnormalities. It's very confusing. The only major difference is java.io code and imports in the main class of the jar in question.

I should note that this problem is resolved. I didn't make that extremely obvious in the first post. The resolution was to remove all of the imports and java.io code from the main class and place them in another class.

There may be no easy answer to this. But I'm trying to find out what may be causing this. Maybe the resolution didn't work at all and my machine is playing games with me. If it's one of those things where the only insight I could get out of it is "it works now. note it and move on", that's fine. I can deal with that. But my hope is this is not uncommon and there is a way to understand why this is happening so I can build better, more stable, applications.
 
Ranch Hand
Posts: 71
4
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

David Gillette wrote:The resolution was to remove all of the imports and java.io code from the main class and place them in another class.


Well, I highly doubt that some along those was even the issue in the first place.
First of all: Any imports are resolved at compile time and replaced with fully qualified class names - so it's only a help for the compiler where to search for classes wich in turn grants us as developers the convenience of not have to type full class names each time but only the name of the class without any package. When you look into a class file you will always find all references are fully qualified class names with thier package names. So, importing something or not doesn't change the resulting class file at all.
Next: As it was mentioned in the linked thread: it's most likely an issue with the working directory and permissions - and most likely some was changed when code was moved from main class to another class. It doesn't magically change how Java behaves only cause you move code from main() into any other place - it will still produce the same bytecode wich is executed the same way by the interpreter. So, this lead to clearly what you might see as a potential issue isn't what it's causing it but something other that got changed along the movement.

But, for god's sake, I tested it on my local Win7 system. I created a simple jar wich just access a file given by an absolute path and ran that from task scheduler - worked without any issue. It even worked accross mounted CIFS/SMB share on a linux system. So, it's clearly neither anything about imports (as they get resolved at compile time) or any class in java.io package. The only other thing that's now left are try to access files from a relative path in wich the user has no write permissions. I guess this "mytery" can easy be solve if you provide old code when it was in main() vs new code after moving - can't be anything other than a wrong path relative to a wrong set working directory.
 
Sheriff
Posts: 24761
59
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd agree with all of that, except that the OP claimed that the original "bad" version worked intermittently. So to me there's still a bit of a mystery.
 
David Gillette
Greenhorn
Posts: 27
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kristina,

Thanks for the thoughtful reply and taking the time to try to reproduce this.

I understand the import statements could not have caused the problem. I suppose that was just a poorly worded explanation on my part. But as Paul noted, the mystery still exists. Here's why: I can firmly assert beyond any doubt the few lines of java.io code were merely moved out of the main class and nothing was changed other than that (that and the single line calling the new class) and I have other tasks doing approx the same thing operating as expected. As far as permissions go they are setup correctly. The application is running under the correct credentials and reading and writing is happening on that user account in a directory where the it has full rights. It's craziness, I know...

I don't think it's fair to ask for insight without providing code or environment details. So I'm going to create a mockup, reproduce the problem, and then I'll post the code, environment details, and task scheduler settings so hopefully this can be reproduced on another machine.
 
Paul Clapham
Sheriff
Posts: 24761
59
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good luck with reproducing the problem; glitches which happen intermittently are the devil to reproduce. I think there's even a good chance that just removing the Task Scheduler entry and replacing it might have fixed the problem. Or recompiling the Java code without any changes and replacing it in Task Scheduler.
 
Do not threaten THIS beaver! Not even with this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!