-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting rid of new File(URL.getPath()).toURI()
#5496
Comments
The reason for filing the issue was not performance related at the beginning, the problem was that Jersey did not build on Windows. The issue showed the reason, The performance degradation comes from the additional operations the |
Hopefully it is clear now that MyTest.class.getResource("").getPath() returns the path component of the URL, it's not a file path.
On Windows, the new implementation will of course convert forward slashes to back slashes, the issue I think you are running into seems to be "/C:/" which comes about from treating the URL path component as a file path. |
@jansupol I would propose that I set up a test environment so I can check Alan's ideas. Regarding performance I do not see where this is in the critical path. Do you have a pointer for me where performance plays a role here, so I keep checking that special case then? |
@jansupol Earlier this year you had to rework my NIO2 optimizations in Jersey due to problems with Windows path names. We found out that the original cause was not the
Path
class itself, but Jersey's use ofURL.getPath()
. In https://bugs.openjdk.org/browse/JDK-8314511 you claimed that you abstain from using Team OpenJDK's solution (URL.toURI()
) because of performance reasons. Due to that I openend https://bugs.openjdk.org/browse/JDK-8321591 and checked the Jersey source code. In fact, I could not find a proof for a notable performance loss in Jersey's critical path, nor any other good reason for keepingnew File(URL.getPath()).toURI()
. As @AlanBateman explained several times, it is just a question of time until Jersey will run into a runtime fault as that code line will definitively fail with blanks in spaces (which is quite typical on Windows thanks to theProgram Files
folder for example). Hence I would kindly ask you to work with me to identify the actual reason why you still keep that "broken" code (and the risk of runtime failure), or to identify changes needed in OpenJDK to overcome your pretended performance shortcomings. Thanks! :-)The text was updated successfully, but these errors were encountered: