[+cc bug#9088]

On 05/08/2013 12:08 PM, Michael Zucchi wrote:
> 
> Hi list,
>
> I recently added a tiny bit of java+jni to an auto* configured project,
> and during the process came across some discussion from about two years
> ago about improving Java support.  As documented on:
> 
>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088
>
I'm adding that in CC:, so that this new discussion will get correctly
registered in the bug tracker.

> So, it seems the JAVA deprecation was carried out,
>
Actually, not really.  But I see the documentation mistakenly report
such a deprecation in pretty strong terms.  The attached patch fixes
that (and adds you to the THANKS file).

> but not the JARS
> implementation.  I presume that was mainly due to lack of interest
> together with critical-path personnel constraints?
>
Basically, yes.  If somebody knowledgeable enough were to write patches,
they would likely be gladly received.  Of course, there is not need to
present complete patches right away; the best thing to do is start with
some RFC version to spark a discussion, and then refine/extended them
as needed --- and this is where the community should provide help and
feedback to the patch writer.

> Unfortunately as
> much as ant (really) sucks, I can't see the Java world changing it's use
> of horrid tools, and the GNU world still seems to shun Java too - so
> interest may never pick up.
> 
> However, assuming it hasn't gone anywhere beyond that bug report,
>
It hasn't, sadly.

> where
> would one begin were one to try to tackle this?  m4 mostly just gives me
> the willies so i'm not sure I can help much but if I waste my time it's
> only my time wasted.
>
m4 is only required in order to write configure tests. For this new feature,
doing that might be trivial, and needn't be done right away: you could just
write the first version of the patches assuming java and jar are present,
and follow-up patches might improve on that writing proper configure tests.

The real workhorses here are the automake script (~ 8000 lines of perl), and
the *.am Makefile fragments in the 'lib/am' subdirectory.  That's what you'll
need to interact with.

So, if you are willing to go ahead, you might want to clone the Automake
git repository, read the HACKING file, and start perusing the files
'bin/automake.in' and 'lib/am/*.am' for "inspiration".

Also, notice that in order to have any non-trivial change integrated in the
official Automake repository, you'll need to either assign copyright for the
change to the Free Software Foundation, or at least explicitly put it in the
public domain.  If you are willing to proceed, contact me off-list, and I'll
try to help about this issue.

Thanks, and best regards,
  Stefano