Subject: Re: Java, JARS primary?

From: Stefano Lattarini <[email-masked]>
Date: Fri, 10 May 2013 14:45:57 +0200

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

>From 4ccf9a8034c597f33ce9592f06533e3cd096fd99 Mon Sep 17 00:00:00 2001
Message-Id: <4ccf9a803[email-masked]>
From: Stefano Lattarini <[email-masked]>
Date: Thu, 9 May 2013 20:23:40 +0200
Subject: [PATCH] docs: we still don't have the promised better Java interface

Reported by Michael Zucchi:
<http://lists.gnu.org/archive/html/automake/2013-05/threads.html>

See also automake bug#9088.

* doc/automake.texi (Java): Adjust and clarify.
* THANKS: Update.

Reported-by: Michael Zucchi <[email-masked]>
Signed-off-by: Stefano Lattarini <[email-masked]>
---
 THANKS            | 1 +
 doc/automake.texi | 8 ++++----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/THANKS b/THANKS
index fd023e2..66b3270 100644
--- a/THANKS
+++ b/THANKS
@@ -261,6 +261,7 @@ Michael Brantley                [email-masked]
 Michael Daniels                 [email-masked]
 Michael Hofmann                 [email-masked]
 Michael Ploujnikov              [email-masked]
+Michael Zucchi                  [email-masked]
 Michel de Ruiter                [email-masked]
 Mike Castle                     [email-masked]
 Mike Frysinger                  [email-masked]
diff --git a/doc/automake.texi b/doc/automake.texi
index e52cc3a..58561ed 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7598,11 +7598,11 @@ libtool, The Libtool Manual}) with the @code{LTLIBRARIES} primary.
 Automake provides some minimal support for Java bytecode compilation with
 the @code{JAVA} primary (in addition to the support for compiling Java to
 native machine code; @pxref{Java Support with gcj}).  Note however that
-@emph{the interface and most features described here are deprecated}; the
-next automake release will strive to provide a better and cleaner
+@emph{the interface and most features described here are deprecated}.
+Future Automake releases will strive to provide a better and cleaner
 interface, which however @emph{won't be backward-compatible}; the present
-interface will probably be removed altogether in future automake releases
-(1.13 or later), so don't use it in new code.
+interface will probably be removed altogether some time after the
+introduction of the new interface (if that ever materializes).
 
 Any @file{.java} files listed in a @code{_JAVA} variable will be
 compiled with @code{JAVAC} at build time.  By default, @file{.java}
-- 
1.8.3.rc0.19.g7e6a0cc