> you should think of a JLI_open function and then you can > put its implementation into the Windows version of java_md.c.
Hi Christoph, I like this idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > Would it be possible to add a jtreg testcase that shows/tests the issue? > Maybe I could put something into the existing jdk/test/jdk/tools/launcher tests. Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 28. Januar 2019 14:23 > To: Baesken, Matthias <matthias.baes...@sap.com>; Alan Bateman > <alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net > Subject: RE: RFR : 8217093: Support extended-length paths in > parse_manifest.c on windows > > Hi Matthias, > > thanks for the update. > > I still think you should avoid introducing a file parse_manifest_md.c. As per > my previous mail, you should think of a JLI_open function and then you can > put its implementation into the Windows version of java_md.c. You can take > example on the implementation of JLI_Snprintf which has coding on > Windows and for Unix it's just a #define to snprintf. > > Would it be possible to add a jtreg testcase that shows/tests the issue? > > Best regards > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Montag, 28. Januar 2019 12:38 > > To: Alan Bateman <alan.bate...@oracle.com>; core-libs- > > d...@openjdk.java.net > > Cc: Langer, Christoph <christoph.lan...@sap.com> > > Subject: RE: RFR : 8217093: Support extended-length paths in > > parse_manifest.c on windows > > > > Hello Alan / Christoph, > > new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ > > > > - moved ELP_PREFIX define out of the function > > - added a check (wfullnamelen > 247) before CreateFileW is attempted > > - some other formatting (mostly suggested by Christoph) > > > > > > Best regards, Matthias > > > > > > > -----Original Message----- > > > From: Alan Bateman <alan.bate...@oracle.com> > > > Sent: Sonntag, 27. Januar 2019 16:57 > > > To: Baesken, Matthias <matthias.baes...@sap.com>; core-libs- > > > d...@openjdk.java.net > > > Cc: Langer, Christoph <christoph.lan...@sap.com> > > > Subject: Re: RFR : 8217093: Support extended-length paths in > > > parse_manifest.c on windows > > > > > > On 24/01/2019 16:19, Baesken, Matthias wrote: > > > >> Did you consider adding a Unix version of open_jarfile to avoid #ifdef > > > >> WIN32 ? > > > > Hi Alan, do you mean , adding a separate c-file for UNIX containing the > > > function open_jarfile ? > > > > I considered this, but did not like the idea to add a separate file for > UNIX > > > just for the small function . > > > > > > > > Your suggestion to use FILE_SHARE_READ is probably the right way to > > do > > > it , I changed this, second webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.2/ > > > > > > > Christoph Langer's suggestion to use jli_util seems worth exploring to > > > keep the platform specific code together. > > > > > > I still find the call to _open and checking for ENOENT a bit icky. If > > > this change gets pushed then I think we need a follow-up issue created > > > to replace this to use CreateFile consistently. > > > > > > -Alan >
