RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

[Baesken, Matthias]

Hello here is an updated webrev :


http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/



> > In  JLI_Open(const char* name, int flags), you should remove ret and only
> > use fd, I think.


I removed ret  and adjusted some comments.

Additionally I added a  test  that uses (on Windows)     JLI_Open  on  a  jar file  with a "long"   path  (> 260 chars).
 [ JLI_Open  is currently called  from  parse_manifest.c  with jarfile as parameter ]



Best regards, Matthias




> -----Original Message-----
> From: Baesken, Matthias
> Sent: Montag, 25. März 2019 10:48
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net; Alan Bateman
> <Alan.Bateman at oracle.com>
> Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code
> (libjli) - was : RE: RFR : 8217093: Support extended-length paths in
> parse_manifest.c on windows
> 
> Hi Christoph / Alan, thanks  for the  reviews.
> 
> 
> Btw what do you think about the   longPathAware     setting   in the manifest
> ?
> 
> https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file
> 
> https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-
> long-paths-on-windows-10/
> 
> This might be an option for Windows 10 / Windows server 2016  to  enable
> long path awareness for  all open calls.
> ( however for older Windows versions I think we still  need the ELP/UNC path
> coding)
> 
> 
> Thanks, Matthias
> 
> 
> 
> > -----Original Message-----
> > From: Langer, Christoph
> > Sent: Sonntag, 24. März 2019 07:14
> > To: Baesken, Matthias <matthias.baesken at sap.com>
> > Cc: core-libs-dev at openjdk.java.net; Alan Bateman
> > <Alan.Bateman at oracle.com>
> > Subject: RE: RFR: 8218547: Simplify JLI_Open on Windows in native code
> > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in
> > parse_manifest.c on windows
> >
> > Hi Matthias,
> >
> > yes, I think this is generally a good way to go.
> >
> > In  JLI_Open(const char* name, int flags), you should remove ret and only
> > use fd, I think. (Currently it would return 0 in the _wopen case).
> >
> > Furthermore, I think it would be a good time to introduce a test now that
> > exercises paths to libjvm of different lengths...
> >
> > Thanks for your work here!
> >
> > Best regards
> > Christoph
> >
> >
> > > -----Original Message-----
> > > From: Alan Bateman <Alan.Bateman at oracle.com>
> > > Sent: Freitag, 22. März 2019 20:37
> > > To: Baesken, Matthias <matthias.baesken at sap.com>; Langer, Christoph
> > > <christoph.langer at sap.com>
> > > Cc: core-libs-dev at openjdk.java.net
> > > Subject: Re: RFR: 8218547: Simplify JLI_Open on Windows in native code
> > > (libjli) - was : RE: RFR : 8217093: Support extended-length paths in
> > > parse_manifest.c on windows
> > >
> > > On 22/03/2019 14:37, Baesken, Matthias wrote:
> > > > Hello, here is   the new webrev .
> > > >
> > > > I  took over and adjusted  coding from       os::open  +  create_unc_path
> > > functions   in os_windows.cpp   in hotspot  :
> > > >
> > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.0/webrev/
> > > >
> > > This looks quite good. For the comment then it might be better to drop
> > > the mention of os_windows.cpp, also maybe mention that the memory
> > > should
> > > be freed with JLI_MemFree rather than free.
> > >
> > > -Alan