[Scons-dev] SCons and Java

[Dirk Bächle]

Hi William,

please find a few comments below.

On 30.05.2014 02:42, William Blevins wrote:
> Team,
>
> I have a couple points I'd like to discuss, but for the sake of 
> organization, I intend to split them into separate emails.
>
> Java Part #2
>
> There has been some discussion on making Scons more ANT-like, 
> http://www.scons.org/wiki/JavaSupport, and that might solve some 
> issues like identifying Java targets.  There is merit here assuming 
> that Java support stays SCons-like at the same time; otherwise, why 
> not just use ant or maven?
>
 From this I get that you'd like to have some form of Java support in 
SCons directly, and don't want to delegate things to an external 
program, correct? At least it's my assumption for the following remarks...

> Problem(s) this will solve:
> 1. Determining the source -> target(s) from *.java -> *.class is 
> painful, possibly java version dependent, and performance intensive 
> (possibly); thus, we should optimize this out.
> 2. Java developers are plagued requiring manual cleaning of a jar far 
> too often with ant-like system(s) and the current scon(s) methodology.
>    1. Clean could be required when deleting or moving a file since the 
> last build output isn't removed otherwise; avoidable in current SCons 
> depending on how sources are specified (not obvious and/or intuitive 
> coming from ant-like system(s)).
> 3. Simplify the SCons Java API to allow building jar file(s) without 
> having to interact with *.class file(s) at all.
> 4. Simplify the SCons Java support for resource file(s); currently, 
> you have to do copying by hand (if it's supported I know not where or 
> how).
> 5. Reduce the amount of code required to build a jar (by a lot).
>
This sounds like an even more simplified Java Builder than what we have 
now. If you could come up with a SoSimpleJava() Builder, we'd probably 
add it to the core and let people have their own choice.

> How I imagine this should work:
> 1. Treat class file(s) like side-effect(s) and do not include them (at 
> all) in the dependency tree.
>     1. This means we don't have to scan the Java file(s) and determine 
> *.class targets.
I don't think that you can have both. If you treat files as SideEffects 
(in the SCons sense), they have to be part of the dependency DAG. See 
next comment...

> 2. Remove the Java(...) function from SCons; thus, do not interact 
> with *.class file(s) directly ever.  There isn't a *good* reason to do 
> this.
Here is just one scenario, where dealing with *.class files actually 
makes sense: If you're using anonymous classes in a Java source, a bunch 
of additional class files get generated. How do you remove these files 
on a "clean", if they are located in a source folder (which people might 
prefer for some reason)?

More experienced Java developers can probably come up with a dozen more 
useful cases...I'm not sure how often people would want to integrate 
pre-built *.class files (coming from Scala perhaps?) into their builds, 
for example.

You may be able to work around the "clean" problem, by creating all 
"*.class" files in a separate folder structure (pretty much like a 
VariantDir). But what you'll end up with is a somewhat crippled DAG, 
forcing you to remove this output dir completely and rebuild everything 
from scratch...even when only a comment in a single Java source is 
changed. Only to "be sure", just like in make or Ant...there is not much 
of a win here for the user, I'm afraid.

Users might also accidentally delete "*.class" files in your output dir, 
between two builds. And they expect SCons to rebuild those intermediate 
targets on its next invocation. How do you want to handle this?

Finally, you should take into account that users might want to create 
different versions of the same source code. Just as an example, let's 
assume they want to create an "original" and "obfuscated" target(s), or 
a "simple" and "extended" release where additional packages get included 
based on environment variables. And for maximum speedup they do this in 
parallel, by using the "-j" option...so a single dedicated output dir 
won't do probably.

Best regards,

Dirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140530/8d17957f/attachment.html>