Re: JDK 10 removal of javah

Hi James,

Whatever you do, please keep backward compatibility with older JDKs.
Reason is building on older OS X machines for most compatibility which
do not allow latest JDKs.

Thanks for considering.

--
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog
On 2018-05-18 4:27, James McCoy wrote:
> On Fri, May 04, 2018 at 08:12:29AM -0400, James McCoy wrote:
>> On Sat, Dec 23, 2017 at 06:44:13PM +0100, Branko Čibej wrote:
>>> On 23.12.2017 16:30, Andreas Stieger wrote:
>>>> Hello,
>>>>
>>>> I was made aware by our Java package maintainer of the fact that JDK 10
>>>> is removing the javah tool, after the deprecation from JDK 8. Our javahl
>>>> stuff no longer builds and apparently the functionality is in javac now.
>>>>
>>>> JEP 313: Remove the Native-Header Generation Tool (javah)
>>>> http://openjdk.java.net/jeps/313
>>>>
>>>> Was anyone looking at this?
>>>
>>> Not to my knowledge, and patches are always welcome. If javac has the
>>> same functionality, it shouldn't be too hard to tweak the build system.
>>
>> Java 10 has now hit Debian as default, so I've started looking into
>> fixing this.
>>
>> Basically, javac can now be told to generate the headers at the same
>> time it generates the class files, by adding "-h subversion/bindings/javahl/include"
>> to the existing javac calls.  However, this only works with Java 8 or
>> newer.
> 
> It's taken longer than I was hoping, but I'll have something for trunk
> soon.
> 
> The biggest wrinkle is that "javac -h" _only_ generates a header file if
> there are native annotations, whereas "javah" would always generate a
> header file.  This found some places where we didn't have native
> annotations even though they were needed.
> 
> It also throws a wrench in our dependency tracking.  We can't just say
> "Hey make, these .java files all generate a .h file, and libsvnjavahl
> depends on all the .h files" anymore.
> 
> I was initially going to drop the javah type from build.conf.  Since it
> looks like we'll need to explicitly list the header files we expect to
> generate, it will probably be cleaner to use the package-based javah
> stanzas instead.  That will also keep the dependencies more accurate.
> 
> Cheers,
>