bug#9088: Java support

[tsuna]

On Sun, Jul 17, 2011 at 11:20 PM, Ralf Wildenhues
<address@hidden> wrote:
> * Stefano Lattarini wrote on Fri, Jul 15, 2011 at 10:58:01AM CEST:
>> I'd rather deprecate the JAVA primary, and then introduce a new `JARS'
>> primary, to be used e.g. as follows:
>
> First off, we've _never_ removed support for a primary, and I don't
> think we should.  Even just deprecating one is a sign for fairly big
> time failure in the past, right?

Well... to put it bluntly, what the _JAVA primary does is pretty much
useless.  So you can keep it as is, but it's going to confuse users
even more than they already are.  I don't think you can completely
change the way the _JAVA primary behaves, as that would be even worse
than deprecating it, from a backwards compatibility standpoint.

Some people use the _JAVA primary (surprisingly):
http://www.google.com/codesearch#search/&q=file:Makefile.am%20_JAVA%5Cs*:?=&type=cs

> (All the more reason to do good research before the second attempt.)

Agreed.

>>   foo_jar_SOURCES = all.java foo.java
>>   bar_jar_SOURCES = all.java bar.java
>>   bar_jar_JAVACFLAGS = -nowarn
>>   bar_jar_JARFLAGS = -J-Xmx48M
>
>> This should cause the following behaviour:
>>
>>  1. javac will be called (with the `-d' option), to generate .class files
>>     from all.java and foo.java, and put them into a "private" directory
>>     `.classes/foo_jar/';
>
> Why a private directory?

Well since you can't predict what files the compiler will generate,
it's easier to collect the output of the compilation by telling it
"dump everything under that directory".

> How would that play well with subdir-objects?

Not sure...  How would you implement subdir-objects if you had a C
compiler that compiled a whole project at once and if it produced .o
files with names you couldn't really predict?

> libtool?

How does libtool come into the picture?  I don't see how libtool is
relevant to Java.

> What about per-target flags?  How would you write the rules
> in absence of per-target flags?

By "per-target flags" I take it that you mean "how do I compile this
specific .o with this specific flag"?
People don't do this in Java.  I'm not aware of any Java project or
anyone compiling each .java file one by one.  It doesn't mean it
doesn't exist, just that the overwhelming majority of Java people
build a whole bunch of files at once, typically all the .java files
that should end up in a .jar.

> What about other compilers/environments?

I didn't get that.

> What features do other java
> build systems offer that users will want to see?  (Even if they're not
> implemented right away, an implementation should take care not to
> prevent them being added in the future through wrong decisions early on.)

What would be nice would be to have the ability to recompile only the
.java that changed.  So when you edit 2/3 files, then we'd build just
that, but in one command.  One way of doing this I've been thinking
about is to tell Automake that a .java becomes a .class simply by
touching the .class, and each time we touch a .class we also echo the
name of the .java to a file that serves as a "todo list".  At linking
time, we read the todo list, actually compile all these files at once,
and then build the .jar with all the previous .class files and the
newly built .class files.

If this is feasible, it would be perfectly compatible with what was
described so far.  I'm not aware of any Java build system doing this
(e.g. Ant or Maven), so that would be a competitive advantage for
Automake.  AFAIK most Java build systems don't even both doing
dependency tracking (maybe with the exception of sbt).  At least for
Ant I'm pretty certain it doesn't, it just rebuilds everything all the
time.


>> > Alternate question: if Java was a brand new language Automake had
>> > never heard of, how would I build my project with Automake without
>> > doing what I'm doing now where I have custom rules for everything and
>> > I need to hook myself into install- and dist-hooks to Do The Right
>> > Thing?
>> >
>> Basically (and as far as my knowledge/understanding goes), you wouldn't;
>> Automake is unfortunately quite unflexible in this regard.  Providing
>> your own "all-local", "install-hook" and "uninstall-local" rules is
>> probably the best route to follow.
>
> Well, you can have all other kinds of make rules (and Benoit has them),
> pretty much as in a normal makefile.  Automake doesn't help you, but
> also doesn't take much away from you here (except maybe the odd GNU make
> construct it doesn't grok).

I was just hoping there was a way to tell Automake "here's how you can
turn a .java into a .class" and "here's how to put all the .class
together to do a .jar" and have it generate all the rules for me, so I
could leverage it to have "make dist", "make install" etc do the right
thing.  Because the way I did it (everything built manually) forces me
to manually list all the files in EXTRA_DIST, manually install them or
abuse some other primary (such as _DATA), etc.

>> > Like isn't it possible to have a bin_PROGRAMS = foo.jar and
>> > foo_jar_SOURCES = main.java and then tell automake how to transform a
>> > .java into a .class and then how to turn all the .class into a .jar?
>> > It seems that when I try this, Automake dies with "Java source seen
>> > but `GCJ' is undefined".
>> >
>> Yes, because Automake thinks you want to build foo.jar as a binary
>> executable, and so it wants to use gcj to compile it.  This happens
>> because you've listed foo.jar in a PROGRAMS primary, which is only
>> meant for binary executables, not scripts or bytecode files (ok, I'm
>> simplifying things a bit here, but the main point stands).
>
> Well, that could be fixed, no?  Question is what about @address@hidden

I didn't get this either.

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com