If any of those variables are empty or if we ended the whole path with a path separator, the current working directory is coming into the classpath.I'd be surprised, in fact I'd be astonished. I would expect that if you put anything into the classpath other than empty elements, it won't use '.'. However this is not what you have done. What you have done is specify four empty elements, which is equivalent to specifying nothing at all, which is causing it to use '.'.
Is it the intent? Users may not even notice that the current working directory is getting added to the CLASSPATH as they are not deliberately adding '.'I don't believe it's even happening.
So any simple misplacement of a path separator character can result in the current working directory getting added to the CLASSPATH. I did not expect this at all.I think you are misinterpreting what I said.
user623867 wrote:In terms of the class loader - because it is coded that way.
Can someone explain why the current working directory is getting added to the classpath in these scenarios when I did not include "." in the CLASSPATH?
user623867 wrote:Except of course that I have shown that this has been going on for years and this is the first time anyone noted it. Thus it would suggest that regardless of the lack of knowledge it is not a problem. Not a problem for a lot of people.
Thank you for the reply. My main issue is that folks may not be even aware of the fact that the current working directory is getting added to the classpath (as they did not explicitly put '.' in the classpath).
At least I did not know until I recently started looking at some code where a property file is getting loaded from the classpath and the property file is no where in the J2EE WAR/EAR or any classpath hierarchy of the application server but it is in the directory where the app server is getting started.That to me sounds like an install problem.