failing to steal from Java (was Re: Someone needs to take jwz aside...)

[Nicholas Clark]

On Wed, Apr 27, 2011 at 01:28:14PM +0100, Pedro Figueiredo wrote:
> On 27 Apr 2011, at 13:02, Nicholas Clark wrote:
> 
> > 
> > The issues seem to be dependency management and code reuse.
> > 
> > How is Java solving these in ways that Perl is failing at?
> > 
> > It's not automating the (to some degree necessary) bureaucratic
> > permission-gaining exercises. So what is it doing differently?
> > 
> 
> >From my point of view, when we decide to update a dependency, run the tests, get Ops approval, have run it on a few live servers, etc (the whole bureaucratic process), all I have to do is update or add the dependency information in the POM file:
> 
>     <dependency>
>       <groupId>mysql</groupId>
>       <artifactId>mysql-connector-java</artifactId>
>       <version>5.1.13</version>
>       <scope>compile</scope>
>     </dependency>
> 
> I would either add this block, if it's a new dependency, or change the version number. Then I would run 'mvn deploy' and go have a coffee.

But a dependency in a Makefile.PL can do that just as well, so what's the
difference/advantage of the Java toolchain?

As a partial answer, most everywhere I've worked has *not* packaged up its
internal code as modules with Makefile.PL - it's just one (or more) big trees
of modules in place. Is the "problem" that the compile first nature of Java
forces one to package everything up within a build system (a sunk cost, which
can't be avoided, unlike perl), so that it's always going to be a low
*incremental* cost to add proper dependency metadata to a Java project?

> Ops aren't even involved in this other than to deploy the new package (a single file) to live and having given their amen to the results of the previous testing.

Is that the *big* advantage - process?

In that it's standard, reliable and easy to distribute java code as a single
file, that's known good to work? Meaning that a lot of the process cost of
installing dependencies can be pushed back from "operations" to "development",
meaning in turn that operations are not as averse to changing/adding new code,
because for them it's pretty-much a no brainer?

[Whereas you can't usefully compile a single perl module or distribution into
a single file package that the runtime only needs to load and link-edit into
the rest of the code, and I think that it's a "hard" problem to solve
because 

a: Perl can run code at compile time, thanks to BEGIN {} blocks
b: Perl code is happy/allowed to fiddle with anyone else's namespaces,
   including globals, so it's hard to know what the actual impact of
   C<use Foo> really was

neither of which, I believe, is the case for Java.

Plus,

c: The relative ease of XS, and the things it lets you that you can't in
   pure Perl means that it's fairly common to end up indirectly depending on
   an XS module. Which is fine locally, but means that your remote deploy is
   now (at least) 2 things - the Perl code, the shared object from the XS
   code, and then potentially any dependencies on other shared objects.

whereas, for Java, nearly everything is written in pure Java, and deployed as
Java bytecode?]


And what of this can't be solved by building packages for the OS packaging
system? Which boxes *don't* those tick that Java does?

Nicholas Clark