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

Pete Brunet peter.brunet at oracle.com
Wed Mar 25 15:55:05 UTC 2015


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



More information about the awt-dev mailing list