Messed up file IO

Question

I apparently did just that and have no clue how. Or why... or what exactly, either.

Allright, here's the setup:

I'm running an OpenDSS Simulation using the OpenDSSEngine.dll and a com4j java interface generated by this process: https://com4j.java.net/tutorial.html

Since I required the OpenDSS Server to be able to run on a different machine, I implemented a client/server (text and object transfer) in java and all was fine...

Now I wanted to be able to run a "workstation mode" (Calling the com locally and directly in my application). Additionally, I wanted to thread it a bit. So I wrote a Runner (Thread, that calls functions) and a Wrapper (processes function calls from runner including the treatment of results).

The wrapper contains an implementation of an abstract class, that will either be the client- (socket communication) or server-side (workstation mode ,com object) implementation.

And now the problem:

Massive EDIT:

After some more testing I can now give a better description of where the exact problem lies.

Initiating the COM-Interface breaks the file IO. The working directory is somehow changed. In a bad way. Calling on any and every java-function turns out the working directory where it should be. Which is where I executed java.

But the working directory for some reason is where the dll stores it's data.

I have verified this, by putting one of the files there and trying to read from it (modified, see first character).

CODE:

// working dirs
Path currentRelativePath = Paths.get("");
String s = currentRelativePath.toAbsolutePath().toString();
System.out.println("Current relative path is: " + s);

String current;
try {
  current = new java.io.File(".").getCanonicalPath();
  System.out.println("Current dir:" + current);
} catch (IOException e2) {
  e2.printStackTrace();
}

String currentDir = System.getProperty("user.dir");
System.out.println("Current dir using System:" + currentDir);

// try read java location

try {
  BufferedReader in = new BufferedReader(new FileReader("1Neues_Netz_EXP_CAPACITY.csv"));
  in.read();
  in.close();
} catch (FileNotFoundException e) {
  System.out.println("Failed: local creation");
  e.printStackTrace();
} catch (IOException e) {
  System.out.println("Failed: local read");
  e.printStackTrace();
}

// COM-Init

OpenDSS.IDSS DSS = ClassFactory.createDSS();

System.out.println("dssinit");

// working dirs, again
    Path currentRelativePath = Paths.get("");
String s = currentRelativePath.toAbsolutePath().toString();
System.out.println("Current relative path is: " + s);

String current;
try {
  current = new java.io.File(".").getCanonicalPath();
  System.out.println("Current dir:" + current);
} catch (IOException e2) {
  e2.printStackTrace();
}

String currentDir = System.getProperty("user.dir");
System.out.println("Current dir using System:" + currentDir);

// try read java location

try {
  BufferedReader in = new BufferedReader(new FileReader("1Neues_Netz_EXP_CAPACITY.csv"));
  in.read();
  in.close();
} catch (FileNotFoundException e) {
  System.out.println("Failed: local creation");
  e.printStackTrace();
} catch (IOException e) {
  System.out.println("Failed: local read");
  e.printStackTrace();
}

// try read COM location
try {
  BufferedReader in = new BufferedReader(new FileReader("Neues_Netz_EXP_CAPACITY.csv"));
  in.read();
  in.close();
} catch (FileNotFoundException e) {
  System.out.println("Failed: dss creation");
  e.printStackTrace();
} catch (IOException e) {
  System.out.println("Failed: dss read");
  e.printStackTrace();
}

RESULT:

Current relative path is: D:\Feustel\Aufträge\OROP\source\04 - Products\OROP
Current dir:D:\Feustel\Aufträge\OROP\source\04 - Products\OROP
Current dir using System:D:\Feustel\Aufträge\OROP\source\04 - Products\OROP

java.io.FileNotFoundException: 1Neues_Netz_EXP_CAPACITY.csv (Das System kann die angegebene Datei nicht finden)
  at java.io.FileInputStream.open(Native Method)
  at java.io.FileInputStream.<init>(Unknown Source)
  at java.io.FileInputStream.<init>(Unknown Source)
  at java.io.FileReader.<init>(Unknown Source)
  at dev_tests.WorkstationModeTest2.main(WorkstationModeTest2.java:76)

dssinit

Current relative path is: D:\Feustel\Aufträge\OROP\source\04 - Products\OROP
Current dir:D:\Feustel\Aufträge\OROP\source\04 - Products\OROP
Current dir using System:D:\Feustel\Aufträge\OROP\source\04 - Products\OROP

Failed: local creation

Line 76 in the exception is the one after the dss initialisation. That's java for you ;)

Here's a link to all the com and opendss files I used.

I will submit this to the guys developing com4j and also to the guys developing opendss.

Of course, I'd be happy if somebody here could tell me, whether that's a problem with com4j or the opendss engine. And wether or not there's a simple way to fix this.

Answer 1

Okay, the OpenDSS dev replied and confirmed the change of the working directory on a process level.

Java doesn't notice this. Maybe that's because java needs the change to happen through it's own interface to notice it. Don't know.

I'm still investigating why the engine forces a default working directory on initialisation. This might be hard-coded in the engine or a result of the automated conversion.

My current solution is to set the datapath of the engine to the java working directory.

Modified init:

// COM-Init
OpenDSS.IDSS DSS = ClassFactory.createDSS();
DSS.dataPath(System.getProperty("user.dir"));

This means that any export of OpenDSS data will dump into the java working directory. Not the nicest of solutions, but it works. I'll probably just clean that away later in the program.

EDIT: I've gotten confirmation from the dev. When starting, the engines tries to find out what it's working directory should be and sets that... On a process level. Why it does that escapes me. I don't know any programming language that would require it, since the operation system already handles this... In addition to this I don't see any reason to include the automated process in the engine...

Anyway, unless the devs change that, this problem will continue to exist for anybody using the java interface.

I'll mark this as the solution until I get news that this has changed...