[foreign] RFR 8222919: jextract should compile generated java sources rather than use ASM to generate class files
sundararajan.athijegannathan at oracle.com
Wed Apr 24 14:16:54 UTC 2019
Fixed. Updated webrev:
1) Wrong source file name for static forwarder classes -harmless (as the
name is used only in SourceFile attribute) and hence no test failure
because of that. But it has been fixed to use correct source file name
(with package name rather than just simple name).
2) '\\' in names of Zip/Jarfile:
Previously Map<String, byte> used "/" separated names for class names
(com/acme/Foo for com.acme.Foo). This masked the bug in JarWriter (which
replaced '.' with File.separatorChar - but "." didn't occur in the name
at all)! With InMemoryJavaCompiler, names are normal fully qualified
classnames (com.acme.Foo) - which JarWriter transformed with "\\"
(File.separatorChar) on Windows! Resulting in zip/jar file containing
'\\' chars! This is a bug per Zip standard.
"126.96.36.199 The name of the file, with optional relative path. The path
stored MUST NOT contain a drive or device letter, or a leading slash.
All slashes MUST be forward slashes '/' as opposed to backwards slashes
'\' for compatibility with Amiga and UNIX file systems etc. If input
came from standard input, there is no file name field. "
PS. Jorn and I discussed this via private emails as well - found the
same issue independently! Submitting internal mach5 job concurrently.
On 24/04/19, 6:48 PM, Sundararajan Athijegannathan wrote:
> Hi Jorn,
> Yes, I see 3 test failures on Windows (only) with internal mach5
> build. I'll check this out. Thanks.
> On 24/04/19, 4:35 PM, Jorn Vernee wrote:
>> Hi Sundar,
>> In InMemoryJavaCompiler.FileManager::getJavaFileForOutput; Should
>> this use computeIfAbsent instead of put? You're probably more aware
>> of the backing implementation. Is there any chance a file with the
>> same name is requested twice, and then the previously created
>> ClassFile object being overwritten?
>> Also, there are some tests failing. This seems to be due to Unix vs.
>> Windows path separators, for instance in the Runner test:
>> test Runner.testJarManifest(): failure
>> java.lang.AssertionError: Sets differ: expected [com.acme.pad_h,
>> com.acme.pad_h$anon$pad_h$1195, com.acme.pad_h$PaddyStruct] but got
>> [com\\acme\\pad_h$anon$pad_h$1195, com\\acme\\pad_h,
>> at org.testng.Assert.fail(Assert.java:94)
>> I'm looking into this right now, but maybe you know where the problem
>> might be?
>> Sundararajan Athijegannathan schreef op 2019-04-24 11:34:
>>> Please review.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222919
>>> Webrev: https://cr.openjdk.java.net/~sundar/8222919/webrev.00/
More information about the panama-dev