[foreign] RFR 8222919: jextract should compile generated java sources rather than use ASM to generate class files

[Sundararajan Athijegannathan]

Thanks.

Yes, we can start investigating extension/plugin api.

-Sundar

On 24/04/19, 8:23 PM, Jorn Vernee wrote:
> Looks good!
>
> Now that the transition to source code generation is complete, and the 
> ASM factories are removed, we can start looking at the 
> plugin/extension story some more I think?
>
> Cheers,
> Jorn
>
> Sundararajan Athijegannathan schreef op 2019-04-24 16:16:
>> Hi,
>>
>> Fixed. Updated webrev: 
>> https://cr.openjdk.java.net/~sundar/8222919/webrev.01/
>>
>> Issues:
>>
>> 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.
>>
>> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
>>
>> "4.4.17.1 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.
>>
>> Thanks,
>> -Sundar
>>
>> 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.
>>>
>>> -Sundar
>>>
>>> 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, 
>>>> com\\acme\\pad_h$PaddyStruct]
>>>>     at org.testng.Assert.fail(Assert.java:94)
>>>>
>>>> I'm looking into this right now, but maybe you know where the 
>>>> problem might be?
>>>>
>>>> Cheers,
>>>> Jorn
>>>>
>>>> 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/
>>>>>
>>>>> Thanks
>>>>> -Sundar