<AWT Dev> RfR JDK-8055831 Open Source Java Access Bridge

[Pete Brunet]

Thanks Phil,

On 3/25/15 11:26 AM, Phil Race wrote:
> AWTEventMonitor.java has a bunch of deprecated methods.
> If you don't have time now (I expect you don't) then it can be
> revisited later. Open sourcing is different than binary compatibility.
These were deprecated via CCC 8007499.
>
> The change jdk/make/copy/Copy-java.gmk suggests that accessbridge
> is the only reason the closed version of the java.policy file exists.
> However these files are not otherwise identical. And also implies
> there'd be a corresponding closed review to remove that file.
The full (open/closed) webrev has been under review since Feb 17.
>
> I am not sure this is exactly right. I see one other difference - that
> looks a bit like someone else overlooked the closed file.
Please elaborate.
>
> Clearly no one looking only at the open code can ever know that its safe
> to remove that copy for closed builds anyway
>
> I think the safe thing to do is undo that change in Copy-java.gmk
> and leave the closed file in place and discuss off-line with the
> security team why the files differ ..
I'll start a discussion on this.
>
> -phil.
>
>
> On 3/25/2015 8:55 AM, Pete Brunet wrote:
>> Hi Sergey, Which methods are you referring to?  -Pete
>>
>> On 3/25/15 10:16 AM, Sergey Bylokhov wrote:
>>> The fix looks fine.
>>> But it is interesting, do we have an option to remove all deprecated
>>> methods during this opening? or can we do it later? or we cannot?
>>>
>>> 25.03.15 17:44, Pete Brunet wrote:
>>>> On 3/25/15 3:01 AM, Erik Joelsson wrote:
>>>>> Hello Peter,
>>>>>
>>>>> The new source layout and Lib-jdk.accessibility.gmk look much better.
>>>>> Thanks!
>>>>>
>>>>> Regarding the .def files, I was mistaken and missed that they were
>>>>> referenced in the LDFLAGS, they were indeed used in the build so no
>>>>> reason to remove them.
>>>> Thanks Erik, My build and tests ran OK so apparently they are no
>>>> longer
>>>> needed.
>>>>
>>>> To all:  My hope is to push this patch into 9 tomorrow (Thursday) so
>>>> please let me know if there are any additional issues as soon as you
>>>> can.
>>>>
>>>> Pete
>>>>> /Erik
>>>>>
>>>>> On 2015-03-24 22:36, Pete Brunet wrote:
>>>>>> Here's the latest patch:
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/
>>>>>>
>>>>>> The changes are:
>>>>>> - restructured the native libraries from one directory to several
>>>>>> directories on a per DLL/EXE basis
>>>>>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk
>>>>>> - removed the source for the Ferret and Monkey test tools which
>>>>>> will be
>>>>>> the subject of a later patch
>>>>>> - removed the DEF files; although they were used in the build,
>>>>>> there are
>>>>>> no build or runtime problems after their removal
>>>>>>
>>>>>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-03-23 18:31, Pete Brunet wrote:
>>>>>>>> Hi Erik,
>>>>>>>>
>>>>>>>> I tried the restructuring about 2 weeks ago and the build failed
>>>>>>>> trying
>>>>>>>> to find an h file in the common directory.  I used two
>>>>>>>> directories on
>>>>>>>> the SRC := setting for SetupNativeCompilation but the build
>>>>>>>> failed not
>>>>>>>> finding an h file located in the second (common) directory.
>>>>>>> For .h files, you need to also set the -I flag correctly. This
>>>>>>> is not
>>>>>>> done automatically from SRC. (Maybe it should.)
>>>>>>>
>>>>>>> We have a pattern that you can copy to get this behavior. E.g.
>>>>>>>
>>>>>>> LIBINSTRUMENT_SRC :=
>>>>>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \
>>>>>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> \
>>>>>>>        #
>>>>>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \
>>>>>>>        $(addprefix -I, $(LIBINSTRUMENT_SRC)) \
>>>>>>>        -Isomewhere-else \
>>>>>>>        #
>>>>>>>
>>>>>>>>> There are a number of extra .cpp files in the libaccessbridge dir
>>>>>>>>> that
>>>>>>>>> aren't used in any of the libraries. What is the purpose of
>>>>>>>>> those?
>>>>>>>>> Keeping source code around that is not being built seems
>>>>>>>>> strange to
>>>>>>>>> me. There are also extra .rc files and a bunch of .DEF files.
>>>>>>>>> Are the
>>>>>>>>> .DEF files used for anything? If all these files really need
>>>>>>>>> to be
>>>>>>>>> included in our source base, perhaps sort them out into a
>>>>>>>>> jdk.accessibility/windows/native/misc dir or something so that
>>>>>>>>> it's
>>>>>>>>> clear what is needed to build the product and what is not?
>>>>>>>> The Ferret and Monkey tools need to be built and added to the JDK
>>>>>>>> image.  This is JDK-8056925.  That covers 2 CPP and the 3 RC files
>>>>>>>> plus
>>>>>>>> AccessInfo.cpp.  Do you want me to remove those now and add them
>>>>>>>> back in
>>>>>>>> later?
>>>>>>> I would prefer that. It is generally better to make each change
>>>>>>> coherent, unless there is much work in making some changes that
>>>>>>> will
>>>>>>> very shortly be undone. This is not the case here. This change
>>>>>>> should
>>>>>>> only add the files that are needed for these dll:s to compile.
>>>>>>>
>>>>>>>> JavaAccessBridge.DEF is pretty empty.  I'll see if the build will
>>>>>>>> work
>>>>>>>> without it.
>>>>>>>>
>>>>>>>> WinAccessBridge.DEF seems like it might be needed.  What do you
>>>>>>>> think?
>>>>>>> Is it accessed by the compiler? Unless it is given as input to the
>>>>>>> compiler or linker command line, it is not used in the build.
>>>>>>> Unless
>>>>>>> the microsoft compiler does some magic trick and picks up files
>>>>>>> unasked based on filename, that is. (Unlikely but not
>>>>>>> impossible, but
>>>>>>> I'd like to see that proved.)
>>>>>>>
>>>>>>> /Magnus
>>>
>