Viktor, I'm the first to agree that is ugly boilerplate (in fact, I proposed a (denied) proposal to the coin list that nevertheless did get some positive traction for a context sensitive keyword on a class declare that turns all its members into getters, and generates a toString, an equals, and a hashCode) - however, that's not a particularly convincing example, as the entire shebang is still generated by eclipse, netbeans, or intelliJ. This doesn't help maintainability all that much (easiest way to make changes: delete all methods, change the fields, re-generate all methods, which is a needless hack), but nevertheless: "I spend days of my life fruitlessly typing supporting code, oh woe is me" is exaggerating.
I'm not having that many problems making nice, relatively fluent, java APIs. Last time I did a LoC comparison for an home-grown (from scratch - it was a weekend exercise) XML marshalling library, I ended up with about 15% more LoC than a factor implementation, and factor is generally known for being very concise. Consider your anecdotal evidence that java makes your code verbose countered by my anecdotal evidence. I'd argue the bloat is more like 20 to 30% extra, tops. That's still a significant number, and I wish coin did a little more to address this bloat. However, coin wasn't all bad, for a few reasons: 1. Long standing pet peeve about using generics in a varargs call generating a completely pointless warning that's in the wrong place WILL be addressed by coin, at least, if Coin sticks to the last short list blogged by Joe Darcy (coin lead). This makes it a lot easier to write nice APIs in java. 2. ARM blocks appear to be coming to coin as well, though the ARM proposal certainly has been the most contentious (The fact that Neal Gafter has made it his personal crusade to come up with as many arguments as he possibly could against any proposal that could feasibly be implemented via closures instead wasn't helping). ARM is serious boilerplate that is annoying to write, annoying to automate, and very harmful if you forget or use a less verbose but unproper hack. 3. minor boilerplate busting, such as eliminating the need to double up on the generics info when writing Foo<Bar> X = new SubFoo<Bar>();, and null-aware operators (foo?:bar returns bar if foo is null, foo otherwise), and foo?.bar() will do foo.bar() if foo is not null, but just evaluates to null if foo is null, instead of throwing an NPE. 4. The concern 'eliminate boilerplate' was, fortunately, often mentioned as a principal design goal. Some boilerplate busters that haven't made it. (apparently - coin's list isn't final yet): data classes, property-like constructs, and anything else that makes javac generate any of: Getters, Setters, propertychangelisteners + a list to track them, hashCode, equals, or toString methods. Technically, an AST processor can do this trick (though you'd have to call the class with the fields in it something else; AST can make new classes for you, it can't edit existing ones afaik). Why is nobody building this, or if someone has? Why isn't it popular? I'd use it, if it came out. On May 6, 10:22 am, Viktor Klang <[email protected]> wrote: > On Wed, May 6, 2009 at 3:37 AM, Alexey Zinger <[email protected]> wrote: > > > This is gonna be about verbosity of generics, isn't it? > > Hi Alexey! > > The switch to Java 5 certainly added alot of cruft for API developers with > regards to the addition of Generics. > But this is not about Generics, this is about all the small things adding up > - turning Java into a boilerplatey language when building abstractions/APIs. > > When I switched from Java to Scala, I suddenly noticed a rather striking > difference: In Java there's alot of "supporting" code; and in Scala, there > is alot less. > This means that you spend less time writing code, and more time thinking > about the solution. > > Compare: > > Scala: > > *case class Person(var name : String)* > > Java: > > *public class Person > { > public Person(String name) > { > super(); > this.name = name; > } > > private String name; > > public String getName() > { > return name; > } > > public void setName(String name) > { > this.name = name; > } > > @Override > public int hashCode() > { > final int prime = 31; > int result = 1; > result = prime * result + ((name == null) ? 0 : name.hashCode()); > return result; > } > > @Override > public boolean equals(Object obj) > { > if (this == obj) > return true; > if (obj == null) > return false; > if (getClass() != obj.getClass()) > return false; > Person other = (Person) obj; > if (name == null) > { > if (other.name != null) > return false; > } > else if (!name.equals(other.name)) > return false; > return true; > }} > > * > > While the above is just a trivial example, it would think it accentuates my > point. > > I spent a couple of hours the day before yesterday rewriting an event > dispatch API in Java, trying to expose the most clean consumer interface as > possible, and I really felt I had to jump through hoops in order to be able > to do just that. But when written in Scala, not only was the resulting API > code about 30% of the LoC, but it also exposed a _cleaner_ interface. > > That's when the question to write libraries in Scala to be consumed by Java > application code. > Hence this thread. > > Viktor > > > > > > > Alexey > > > --- On Tue, 5/5/09, Dave Watson <[email protected]> wrote: > > > > From: Dave Watson <[email protected]> > > > Subject: [The Java Posse] Re: Java as API language, its days numbered? > > > To: "The Java Posse" <[email protected]> > > > Date: Tuesday, May 5, 2009, 9:10 PM > > > What does this mean, exactly? Can you elaborate more about > > > the 85% of > > > your code that is boilerplate? > > > > Not trying to argue, I'm just very puzzled by what this > > > might mean.... > > > > On May 5, 5:27 pm, Viktor Klang > > > <[email protected]> wrote: > > > > Greetings posse, > > > > > having spent more than half a decade writing API:s in > > > Java I feel that since > > > > Java 5 was introduced, more and more time has to be > > > spent writing > > > > boilerplate API code to try to save the API consumers > > > from jumping through > > > > hoops in order to get stuff done. Because we all want > > > easily consumable > > > > libraries, don't we? > > > > > Having jumped onto the Scala bandwagon about 1½ years > > > ago I feel like the > > > > ratio of business end code of Java is appro 15% while > > > in Scala it's more > > > > like 65% > > > > > <observation>You can most likely substitute > > > "Scala" in the text below with > > > > any non-Java JVM language</observation> > > > > > With Scala getting more and more cleaner to be > > > consumed by Java code, isn't > > > > there plenty of good reasons to switch to Scala for > > > library code, while > > > > letting the application developers stay i Java-land? > > > > > -- > > > > Viktor Klang > > > > Known from the Internet > > -- > Viktor Klang > Senior Systems Analyst --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
