The Java Tree Withers
Josh Berry
and I found the article "The Java Tree Withers." Abstract is simply
"The Java report card: infrastructure gets a D, code reuse gets
an F."
Was curious to hear thoughts from in here about the article. Right
now, you can find a pdf by just searching on the title. Apologies if
this has already been discussed. (Additional apologies for not being
able to just link to a page with the article...)
Dereck Haskins
My other 2cents on this: NIH and hero-based programming is _even worse_ in .NET world and if the F for re-use in Java is a 50 out of 100, in C# it would be much, much lower. I'm using C# .NET every day at work and in the realm of re-use (or even intelligent code planning and design patterns) the whole stack is pathetic. Syntactic sugar in .NET is fantastic. Down dirty "plan to use patterns and re-use" - man it sucks. And MVPs are always pushing everyone to check out the latest capabilities of the Collections, but they don't usually fix the problems with the previous versions. Just add more sugar (and slowing down the VM time to de-reference).
So the primary competitor to Java is not better on that front.
I think that as VM-based programming is becoming more and more extensive (with libraries built on libraries) we've moved far, far, FAR away from the idea of program design in the small. The effect has been that code is less and less written to be re-used. And I don't really see much talk of this at all (compared to the early days of Java in 97-98 when re-use and intelligent class design was part of every "you should use Java" discussion).
Again, my 3 cents and part rant. In main we've (AFAICT) given up on code re-use. Tooling makes it (perhaps) unnecessary to some people - what does it matter that I have 13 similar classes since organizing isn't all that hard in a nice tool. We are a LONG way from looking at directories to browse the source. Re-use is HIGHLIGHT, CNTRL-C, CNTRL-V. Bah.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Moandji Ezana
I'd have to agree with the title that reuse gets an F
Cédric Beust ♔
In my definition, Maven Central, Github and build tools count as code reuse, and I think the grade is a lot higher than F.
Alex Turner
Fabrizio Giudici
wrote:
> I couldn't agree more.
+1
And did you see in Table 3, "Framework fossils", the row "JVM on Mac:
Deprecated by Apple"? Also in the body: "The biggest threat to Java is
Apple’s banning of Java on the iPhone [ok] and the deprecation of the new
JVM on the Mac OS". !!!
And stuff such as "The chilling thought is that Oracle appears to have
created a monolithic multimedia replacement for JMF, QT4J, and FMJ".
JavaFX might include some media component, but it's completely wrong to
label it as a multimedia replacement for JMF.
But what were doing the reviewers when they were supposed to review that
paper?
PS I'm so glad I've just renewed my IEEE membership only with the annual
fee and I didn't renew my subscription to the Computer Society. Not sure
I'll renew the membership the next year: to keep in touch with technology
evolution in general a bunch of RSS feeds seem fine.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Josh Berry
>
> On Tue, Jan 24, 2012 at 12:56 PM, Moandji Ezana <mwa...@gmail.com> wrote:
>>
>> In my definition, Maven Central, Github and build tools count as code
>> reuse, and I think the grade is a lot higher than F.
>
>
> Thanks, Moandji, I was going to say just that: Maven is probably the finest
> example of code reuse taken to a point that's never been reached in the
> software industry before.
I think there are some heavily rose colored glasses on this claim.
Many other software languages already had stuff like this. CPAN/CTAN
are two that come to mind easily. And this is avoiding stuff like the
ports tree in FreeBSD or packages in various linux stacks.
All of that said, I brought this article up because it did seem
somewhat flame baity. Was curious if it was just me. I am curious to
know what you are referring to with other code reuse.
Ricky Clarkson
because it can be hard to use a particular class or module outside of
its original intended environment.
E.g., pretty much all the code written by or for my current client
depends on DB2 and on parts of a particular shared schema of tables,
and on their being updated by other parts of the system. There's a
lot of value in some parts (e.g., a job scheduling system in the style
of Control-M) that just isn't transferable even to other parts of the
client.
Fabrizio Giudici
<ricky.c...@gmail.com> wrote:
> I think the problem is that ordinary code doesn't get that much reuse,
> because it can be hard to use a particular class or module outside of
> its original intended environment.
>
> E.g., pretty much all the code written by or for my current client
> depends on DB2 and on parts of a particular shared schema of tables,
> and on their being updated by other parts of the system. There's a
> lot of value in some parts (e.g., a job scheduling system in the style
> of Control-M) that just isn't transferable even to other parts of the
> client.
I think nobody is questioning the point that *some* code can't be reused
(and, I add, that in some circumstances it is not worth while to spend
extra money to make it reusable).
But the previous examples referring to tons of popular Java libraries are
pretty clear to demonstrate that well designed libraries can be reused.
Given that we're basically talking of the Java ecosystem, which I think
most people acknowledge is one of the biggest in the world when compared
to other languages, I think that the conclusion that Java does pretty good
code reuse in comparison to other languages is evident.
Ricky Clarkson
Parts of Java applications are generally not very reusable. Sure, if
you're deliberately writing with reuse in mind you're likely to write
something reusable, but there's usually too much dependence on
surrounding code, sometimes a fear of adding classes that means that
utility code lives in the place that it's used as private methods, and
occasionally (as in my client) a dependency on a particular
environment such as a database.
All these can affect other languages too, but I'd wager that they
affect C and Haskell far less, for instance. Probably JavaScript too.
Cédric Beust ♔
My point might not have been very clear, so I'll say it differently.
Parts of Java applications are generally not very reusable. Sure, if
you're deliberately writing with reuse in mind you're likely to write
something reusable, but there's usually too much dependence on
surrounding code
clay
deprecated, JavaBeans aren't the answer to the world, so what? But
there is one point I wanted to elaborate on:
"The biggest threat to Java is Apple’s banning of Java on the iPhone"
The old strategy of every client device having a system-wide Java
runtime with the full manufacturer blessing is obsolete.
There is a huge opportunity for client-side Java to evolve and take a
position at the vanguard of the field: Evolve towards micro-JDKs
embedded into the end user application that are completely invisible
to the end user and are compatabile with iOS and other devices that
don't necessarily embrace Java at the system or manufacturer level.
What Java, the ecosystem, has that is of huge value is a rich,
vibrant, and widely multi-vendor ecosystem of development tools
including programming languages, IDEs, and best of breed build tools.
If that ecosystem can be connected to the wider range of clients and
client devices that don't want to understand or maintain a system
level JRE, that would be a huge win.
Josh Berry
<Fabrizio...@tidalwave.it> wrote:
> But the previous examples referring to tons of popular Java libraries are
> pretty clear to demonstrate that well designed libraries can be reused.
> Given that we're basically talking of the Java ecosystem, which I think most
> people acknowledge is one of the biggest in the world when compared to other
> languages, I think that the conclusion that Java does pretty good code reuse
> in comparison to other languages is evident.
To be fair, a lot of those libraries cited as examples are duplicates
of each other. I make no claims that this is a good or a bad thing,
but it was just recently when it was mentioned that Guava can replace
a lot of apache commons libraries. Libraries that, as far as I know,
do not actually have any bugs. They just haven't been updated in a
while. Even when items are not full on duplicates of each other, how
many libraries have a primitive hashtable to avoid boxing? (The jgit
author specifically mentions having written one.)
And this may have been the author's point. The core library has
favored deprecation to code reuse to a large extent. Hashtable versus
HashMap is an easy example. This is ignoring such new collections as
ArrayDeque. Then there is the increasing size of imports necessary
to use core collections. Static factory methods help a lot with this,
but were not used by core apis. (I'm specifically thinking about
collections here. Seems having Collections.list(a, b, c, d) would
have given an easy way to shield folks from even importing ArrayList,
but still getting it most of the time.)
As I said, overall article is still flame bait, far as I can tell.
Just not sure I understand some of the rebuttals as being actual
rebuttals. Just loud proclamations of dissent.
I should also add that I favor Knuth's view on code reuse as a whole.
So, still not sure I understand the code reuse arguments. Pro or con,
at this point.
Ricky Clarkson
Josh Berry
<ricky.c...@gmail.com> wrote:
> Regarding Collections.list(a, b, c, d), see Arrays.asList.
To do what I said, you'd have to use Lists.newArrayList.
Arrays.asList is a fixed size list, no?
Ricky Clarkson
could modify, but sure.
Josh Berry
<ricky.c...@gmail.com> wrote:
> Nothing in your message suggested you wanted a list whose size you
> could modify, but sure.
My intent was that you could get something that implements all methods
of List without having to specify the concrete class. Apologies for
not making that clearer.
Vineet Sinha
Cédric Beust ♔
1) The concern that the article started with, is that really old code does not run anymore. I have experienced this. I would like to It will be great to read more on how big of an impact this is.
Vineet Sinha
On Tue, Jan 24, 2012 at 7:27 PM, Vineet Sinha <vin...@architexa.com> wrote:1) The concern that the article started with, is that really old code does not run anymore. I have experienced this. I would like to It will be great to read more on how big of an impact this is.I find this surprising. I certainly haven't seen it myself, but I also think that from a theoretical standpoint, Java's backward compatibility is pretty remarkable. Maybe not as remarkable as Windows', but very good nevertheless.
Casper Bang
For us, we were overriding some of the swing classes, and the somewhere down the road more methods were added to the base class. Getting the code to compile was not too hard - but this was code that was last likely touched over 5 years ago and we did not have the expertise in house. So it just meant more time needed to be spent to resurrect the code.
Moandji Ezana
It makes the point the point that there is a lot of code that is getting deprecated and that old Java libraries has been replaced with new.
Moandji Ezana
Interesting subject though. I reckon all of us in here have written our own domain-less StringUtils, NumberUtils, DateUtils etc. which are obvious candidates for reuse.
I realize Maven, NuGet etc. lets us easily pick down packages we know. But what about the whole discovery problem? How would we better benefit from each-others work?!
Fabrizio Giudici
wrote:
I still can't see the point. I think I need a small example to understand
where C/JavaScript (Ricky) and COM (Cédric) are better.
Fabrizio Giudici
> On Wed, Jan 25, 2012 at 5:27 AM, Vineet Sinha <vin...@architexa.com>
> wrote:
>
>> It makes the point the point that there is a lot of code that is getting
>> deprecated and that old Java libraries has been replaced with new.
>
>
> It seems to me that the APIs he mentions - multimedia stuff - is an area
> in
> which Java has always done poorly. There are lots of other APIs (SQL,
> I/O,
> concurrency, not to mention Java EE) that continue to evolve rather than
> be
> replaced.
Yes, I know the pain of media libraries. But it's a situation that doesn't
extend to the rest of the world.
Re: the Guice libraries that replaced Apache Commons... what's the point?
Redundancy in open source is a known problem, basically you don't want the
extremes: too many similar stuff -> NIH syndrome, while just a single way
to do one thing -> lack of flexibility. Apart from rare exceptions, I see
a health distribution of stuff in the Java ecosystem. In any case, it
seems that this can't have to do with the original paper. This is mostly
community related, and 1) it doesn't have to do with Java itself, rather
third parties and 2) how things are supposed to be better in other
communities?
>
> I found that the third sentence (the first substantive one, I think. I
> don't understand the very first sentence.) sets the tone for the
> article's
> WTF-ness: "In 15 years, my Java project has grown from 667 lines of
> code (LOC) to 633,436 LOC." Does this imply that he's worked on one (and
> only one) Java project for 15 years?
Yesterday I mentioned other WTF-nesses. If you go on with the same topic,
there's a fun way of compute the cost due to a library change. In any case
if you google the author's name you'll find his page and a list of
projects.
Eric Jablow
On Jan 25, 7:33 am, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> Re: the Guice libraries that replaced Apache Commons... what's the point?
> Redundancy in open source is a known problem, basically you don't want the
> extremes: too many similar stuff -> NIH syndrome, while just a single way
> to do one thing -> lack of flexibility. Apart from rare exceptions, I see
> a health distribution of stuff in the Java ecosystem. In any case, it
> seems that this can't have to do with the original paper. This is mostly
> community related, and 1) it doesn't have to do with Java itself, rather
> third parties and 2) how things are supposed to be better in other
> communities?
that its contributors never released Java Generics versions. With
Java 6,
Guava functional programming was a strict improvement over Apache.
However, most of the reusable libraries I've seen are either 'making
Java simpler' , or 'making Java more functional', or 'fixing Date', or
the rare math library. The tasks we all have done many times do
not get into libraries. Okay--I'm not sure we'd ever have a standard
PurchaseOrder class. What about Address? Is there any hope for
a standard version? Note that internationalization is crucial. Each
country has its own address attributes. Postal codes differ; I cringe
whenever I see 'zipCode' in a Java class intended for general use,
and worse whenever I see it validated by the regex \d{5}(-\d[4})?.
Should the community try to develop classes for common notions?
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
Respectfully,
Eric Jablow
Rakesh
typical projects. The bigger enemy is duplication.
I see a lot of copy/paste programming that is not cleaned up by
removing the resultant duplication, especially in legacy apps where
(a) members of the team do copy/paste because its easy to do without
having to understand the full code base, and
(b) devs are not given extra time to refactor the code to remove the
duplication.
This leads to code rot and eventually team rot as the application
grows massively in size and grows unwieldy.
I've seen applications sold to different potential customers as
perfect for their needs as it all 'reusable'. However, 9 times out of
10, because the new customer has 'slightly' different requirements, it
could not be reused and instead huge swathes of the existing code base
is copy/pasted and changed.
To add insult to injury, the original estimates are based on this
phantom reusability, and when it turns out not to be reusable, the
devs are instead pressurised into working longer hours to try and
realise those original estimates.
Rakesh
Moandji Ezana
Should the community try to develop classes for common notions?
Vineet Sinha
Vineet Sinha
I've come to the conclusion that chasing reuse is a fools errand in
typical projects. The bigger enemy is duplication. ...
...(b) devs are not given extra time to refactor the code to remove the
duplication.
Andreas Scheinert
excellent point on reuse. How do your customer measure reuse?
regards andreas
On 25 Jan., 22:20, Rakesh <rakesh.mailgro...@gmail.com> wrote:
> I've come to the conclusion that chasing reuse is a fools errand in
> typical projects. The bigger enemy is duplication.
>
> I see a lot of copy/paste programming that is not cleaned up by
> removing the resultant duplication, especially in legacy apps where
> (a) members of the team do copy/paste because its easy to do without
> having to understand the full code base, and
> (b) devs are not given extra time to refactor the code to remove the
> duplication.
>
> This leads to code rot and eventually team rot as the application
> grows massively in size and grows unwieldy.
>
> I've seen applications sold to different potential customers as
> perfect for their needs as it all 'reusable'. However, 9 times out of
> 10, because the new customer has 'slightly' different requirements, it
> could not be reused and instead huge swathes of the existing code base
> is copy/pasted and changed.
>
> To add insult to injury, the original estimates are based on this
> phantom reusability, and when it turns out not to be reusable, the
> devs are instead pressurised into working longer hours to try and
> realise those original estimates.
>
> Rakesh
>