jtreg - building java and cpp test

Tue Nov 24 04:02:54 UTC 2015

Thanks Staffan, That's good information.  -Pete

On 11/23/15 1:14 PM, Staffan Larsen wrote:
> So this is how it works.
>
> At build-time:
> If you add your test folder to the list in jdk/make/test/JtregNative.gmk and use the naming convention “exe” + mytestname + “.c” for the native code, that file will be compiled into an executable called mytestname(.exe) when the jdk is being built (using the test-images) target. The executable will end up somewhere in your build folder.  
>
> Running the test manually:
> If you want to run the test by manually launching jtreg, you have to find the folder the executable ended up in and use that as an argument to -nativepath.
>
> Running the test using the makefiles:
> If you run using “make test TEST=mytest” the makefiles will automagically add -nativepath with the correct argument when invoking jtreg.
>
> Automated builds:
> When the product is built by the automated systems (jprt et al) the test native code will also be built (as above) and the output folder will be bundled up into a separate zip/tarball next to the product zip/tarball and stored.
>
> Automated testing:
> The automated testing will download _both_ the product zip/tarball and the test zip/tarball and setup the right argument for -nativepath when invoking jtreg.
>
> So as long as your native code is checked in and adheres to the naming convention it will be made available for your test. In your test you can invoke the executable with:
>
>   String lib = System.getProperty("test.nativepath");
>   ProcessBuilder pb = new ProcessBuilder(lib + “/mytestname”);
>   pb.start();
>
> Or if you built a library:
>
>   System.loadLibrary(“mytestname”);
>
> Look at the examples under jdk/test/native_sanity. There are examples with both executables and libraries.
>
>
> /Staffan
>
>
>> On 23 nov. 2015, at 18:34, Pete Brunet <peter.brunet at oracle.com> wrote:
>>
>> HI Staffan, I might have missed it but I don't see how to specify in my
>> test where the native will be.  The wiki shows that jtreg can be run
>> with -nativepath and I can do that from my own command line but what do
>> I need to do so that when the test team runs the the full test suite via
>> jtreg the -nativepath switch will be used for my test along with the
>> specification of the -nativepath argument.  I assume the test teams
>> wouldn't have to know the specific needs of each test that relies on
>> particular -nativepath requirements.
>>
>> But maybe I don't even need -nativepath (although for the future an
>> answer to the prior question would be useful).  In my case I now realize
>> that the exe I need will reside in jdk/bin.  From my test code I need to
>> figure out how to fetch the path of the running jdk and then append the
>> name of the exe I want to start before running the rest of the Java test
>> code.  I think that would be done via the java.home property, e.g.
>> System.getProperty("java.home") + "/bin/jaccessinspector".
>>
>> Pete
>>
>> On 11/20/15 1:20 AM, Staffan Larsen wrote:
>>> Here are some examples of tests using -nativepath in the hotspot repo:
>>>
>>>   $(HOTSPOT_TOPDIR)/test/native_sanity \
>>>   $(HOTSPOT_TOPDIR)/test/runtime/jni/8025979 \
>>>   $(HOTSPOT_TOPDIR)/test/runtime/jni/8033445 \
>>>   $(HOTSPOT_TOPDIR)/test/runtime/jni/ToStringInInterfaceTest \
>>>   $(HOTSPOT_TOPDIR)/test/runtime/SameObject \
>>>
>>> (list copied from hotspot/make/test/JtregNative.gmk)
>>>
>>> /Staffan
>>>
>>>> On 19 nov. 2015, at 22:45, Pete Brunet <peter.brunet at oracle.com> wrote:
>>>>
>>>> Yes, I saw that.  But I don't see how to write my test to use it.  Where
>>>> do I put my cpp file so it ends up in whatever $(shell $(GETMIXEDPATH)
>>>> "$(TESTNATIVE_DIR)/jdk/jtreg/native") is.  I searched for a jtreg/native
>>>> under my entire tree including the build output and didn't find it. 
>>>> That's why it seems noone is using this feature.  But maybe I am missing
>>>> something.  I'm hoping someone has already done this so I can use that
>>>> as a prototype.
>>>>
>>>> BTW, I found https://bugs.openjdk.java.net/browse/JDK-8072842 which
>>>> added the infrastructure last February but didn't find any helpful
>>>> information there.
>>>>
>>>> Pete
>>>>
>>>> On 11/19/15 3:36 PM, Jonathan Gibbons wrote:
>>>>> Pete,
>>>>>
>>>>> I see a few uses in the hotspot/ and jdk/ repos.
>>>>>
>>>>> $ grep --recursive nativepath make */make test */test
>>>>> hotspot/test/Makefile:# jtreg -nativepath <dir>
>>>>> hotspot/test/Makefile:  JTREG_NATIVE_PATH = -nativepath:$(shell
>>>>> $(GETMIXEDPATH) "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>>>>> jdk/test/native_sanity/simplenativelauncher/ProgramTest.java: String
>>>>> lib = System.getProperty("test.nativepath");
>>>>> jdk/test/Makefile:# jtreg -nativepath <dir>
>>>>> jdk/test/Makefile:  JTREG_NATIVE_PATH = -nativepath:$(shell
>>>>> $(GETMIXEDPATH) "$(TESTNATIVE_DIR)/jdk/jtreg/native")
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>>>
>>>>> On 11/19/2015 01:08 PM, Pete Brunet wrote:
>>>>>> On 11/19/15 3:07 PM, Pete Brunet wrote:
>>>>>>> Thanks Jonathan, Is -native in use?  I see some infrastructure for it
>>>>>>> but can't find (yet) that it's actually in use.  -Pete
>>>>>> s/native/nativepath/
>>>>>>> On 11/19/15 12:44 PM, Jonathan Gibbons wrote:
>>>>>>>> On 11/19/2015 07:46 AM, Pete Brunet wrote:
>>>>>>>>> Hi, I need to build a regression test that has both Java and C++
>>>>>>>>> code.
>>>>>>>>> I see some similar cases in the test tree and they include the exe of
>>>>>>>>> the cpp file.  I also see a Makefile.  If I run the test without
>>>>>>>>> the exe
>>>>>>>>> it is not built so what is the Makefile for?  Documentation?
>>>>>>>>>
>>>>>>>>> The Makefile I used as a prototype has
>>>>>>>>> cl -o name.exe name.cpp name.lib name.lib
>>>>>>>>> but when I ran make at the command line cl was not found but at
>>>>>>>>> least at
>>>>>>>>> this point I don't see the need to look into the cl failure if the
>>>>>>>>> Makefile is just for documentation.
>>>>>>>>>
>>>>>>>>> Pete
>>>>>>>> jtreg has no direct, complete solution for mixed code like this, and
>>>>>>>> is unlikely to support
>>>>>>>> it any time soon.
>>>>>>>>
>>>>>>>> You can use Makefiles from a shell script, but that is unlikely to be
>>>>>>>> successful in a
>>>>>>>> broad multi-platform world, like OpenJDK.  Not only is it problematic
>>>>>>>> to know what
>>>>>>>> compiler to use and where to find it, but at least in our internal
>>>>>>>> test infrastructure,
>>>>>>>> the test machines may not even have the native code compilers
>>>>>>>> installed.
>>>>>>>> (i.e. it is common practice to build and test on different host
>>>>>>>> systems.)
>>>>>>>>
>>>>>>>> The compromise solution we adopted in conjunction with the Hotspot SQE
>>>>>>>> team
>>>>>>>> is to use the OpenJDK build process to compile the C/C++ code needed
>>>>>>>> for the tests.
>>>>>>>> The build has the info needed on how to do platform-specific
>>>>>>>> compilation of native
>>>>>>>> code.   The build can then generate a bundle that can be passed to
>>>>>>>> jtreg with the
>>>>>>>> -nativepath option.
>>>>>>>>
>>>>>>>> I cannot speak to the existence of Makefiles appearing in the
>>>>>>>> regression test suite.
>>>>>>>> Sometimes they are used manually to create native files that are
>>>>>>>> checked in to the
>>>>>>>> repo (uugh) and sometimes the tests are restricted to run on a limited
>>>>>>>> set of platforms
>>>>>>>> (e.g. Windows only, or Unix only.)
>>>>>>>>
>>>>>>>> -- Jon