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

[Phil Race]

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.

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.

I am not sure this is exactly right. I see one other difference - that
looks a bit like someone else overlooked the closed file.

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 ..

-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
>>