JAVA_LIBRARY_PATH=`cygpath -p -w "$JAVA_LIBRARY_PATH"`
For trunk and 0.20 in the appropriate places. This now receives the same level of protection that CLASSPATH does. As I acknowledged above there is indeed a possibility that a user will have a broken JAVA_LIBRARY_PATH and this will break for them. That possibility is slim. A quick google of JAVA_LIBRARY_PATH brings this jira up as #5 which indicates its a significantly less common env then CLASSPATH. Regardless the possibility exists.
With the cygpath fix above this change makes every reasonable effort to protect cygwin users. Which places them in the same boat as all the other bash users (Linux, Mac, Solaris, etc). If you have a broken env there is nothing I can do. It would the same if you had a broken CLASSPATH. As with all possibly breaking changes there is a trade off between the users that need the functionality and the users it will break.
Users that need to get native libraries in as it stands have to hack the wrapper. This is tedious and error prone over setting a env. And its not immediately obvious that its what you have to do. The wrapper script respects CLASSPATH logically it should respect others. And its not documented that if you want to do this, oh by the way you have to hack this.
I'm all for testing. But the risk here is broken user env's which is not something in the scope of this jira to address. We can test the patch and add a release note so that if it breaks someone they can read that this was changed. If people are really that worried about it we can add:
echo "Existing JAVA_LIBRARY_PATH detected, if things are breaking please check this first."
But most likely that will just send someone who breaks for a different reason off on a 5 minute wild goose chase.