JVM To resolve absolute linux paths to a directory while running on windows

[Ramya Chowdary]

We've this existing application in which all the paths are absolute Linux paths ( like /home/pratap/conf )
I want to run this app on windows without changing those paths. So I would be copying all the files in a directory assigned on my windows machine.

For Ex:
/home/pratap/conf --> D:/linuxmapping/conf

/home/pratap/logs --> D:/linuxmapping/logs

/home/pratap/conf/springfiles --> D:/linuxmapping/conf/springfiles


Is this work done before ?

I've looked into JDK and JVM Source, and figured out that, java.io.File class uses Native FileSystem.
So, I can change the FileSystem C++ source of JVM, but that needs re-building the openJDK.


But, I've figured out that java.io.File ( Other classes like FileInputStream uses File) can be changed and repacked into their jar.
This is far easier, but I am not sure What're the other places that I need to change too.

[Steve Luke]

Why are you willing to modify the JVM and possibly corrupt/break a whole lot of things rather than change your paths? What you should do is not provide the paths as hard-coded strings. Instead, provide them in a configuration file or environment variable.

[Ramya Chowdary]

It is an existing application with hundreds of configurations files with hard coded paths.
I got no say in converting this paths to relative paths, or using a Linux Desktop OS like ubuntu for development.

So, For development, the practice is write the code in windows using IDE, and build it.
deploy it in linux and validate what you wrote.

So, To increase productivity, I can only see this approach.

[Steve Luke]

The problem is that you would be changing a very key part of the JVM. The consequences will be vast and unpredictable. The environment would be unstable. I would strongly recommend pushing back on the requirements to allow you to either make the application platform independent or allow you to develop on the target environment. If the application is designed to run only on Linux, write it on Linux. If you don't have the resources to get a dedicated Linux box, get a VM. Oracle Virtual Box is free and has some pre-built development stacks that might help you get started.

[Ramya Chowdary]

Thanks for your alternative solutions.
I do consider your suggestion about the JVM.

If you don't have the resources to get a dedicated Linux box, get a VM.

It is more because of IT Polices, enforcement of Group polices on linux.

Oracle Virtual Box is free and has some pre-built development stacks that might help you get started.

Thanks for the suggestion, But not sure of virtual box for day to day usage in development.

Can you/anyone look at java.io.File customization, that should not be much of impact.

[Steve Luke]

Pratap koritala wrote:Can you/anyone look at java.io.File customization, that should not be much of impact.

Not I, but I won't speak for others. This is the wrong way for you to go, and I will not volunteer to go down that route.

[Martin Vashko]

I'm really not sure it is feasible, but perhaps some directory remapping could be done using POSIX for Windows.

[Ramya Chowdary]

It is not possible to run the linux Java using Cygwin.

[Henry Wong]

Pratap koritala wrote:
But, I've figured out that java.io.File ( Other classes like FileInputStream uses File) can be changed and repacked into their jar.
This is far easier, but I am not sure What're the other places that I need to change too.

You can actually put a jar file, earlier in the search path than rt.jar -- so no need to "changed and repacked into their jar". Take a look at the "-Xbootclasspath/p" option.

On the other hand, the Oracle doc mentions that doing so violates the Java binary license (basically, this options is to interpose other jar files, but not the rt.jar file), so you are on your own.

Henry

[Winston Gutkowski]

Pratap koritala wrote:It is more because of IT Polices, enforcement of Group polices on linux.

It seems to me that you (or your superiors) are trying to come up with an excuse for an "end-around" solution because you can't be bothered to actually fix the real problem, which is that your application is set up wrong.

And 'but it works' isn't an answer. The fact is, 'it works until...' isn't good enough, particularly when you've just run into the "until", so it's wrong.
It probably always was wrong; you just never ran into the issue.

Any suggestion you get on the lines that you're on are going to be a band-aid at best; and at worst they'll become standard practise.

My advice: Solve the problem, which has very little to do with what you're thinking about. And if that involves changing hundreds of config paths (though that, in itself, sounds like a problem to me), that's what needs to be done.

Winston