Somebody likes the javafx syntax :) (Which, really, is understandable. Say what you want, javafx script is gobsmackingly elegant, especially for GUI programming).
On Feb 23, 6:12 pm, Viktor Klang <[email protected]> wrote: > On Sun, Feb 22, 2009 at 11:23 PM, Christian Catchpole < > > [email protected]> wrote: > > > I guess there is no right or wrong to most patterns, it's just a > > matter of taste. My person opinion is that ThreadLocals are a bit of > > a hack. I'm an advocate for optimizing interfaces, reducing boiler > > plate and minimizing code. But I drew the line when it breaks some > > fundamental paradigms. > > > Readers will have heard me complain about the "returning self" builder > > pattern. > > > new Thing().setOne().setTwo() > > Ah, this reminds me... > > I've grown more and more fond of using instance-initializers. > > It produces more declarative looking code: > > someArea = new JTextArea(10, 20){ > { > setLineWrap(true); > > setBorder(BorderFactory.createLineBorder(Color.BLACK)); > setMaximumSize(new > Dimension(100,100)); > > setBackground(Color.RED); > }}; > > Pros with this approach is that you don't loiter the code, it's apparent > that the code belongs to the created instance, > you can make all "construction-time only" methods into "protected" so > they're not accessible from outside object creation (thus encouraging > information hiding etc) > > This allows you to write stuff like: > > public abstract class Foo > { > private Bar bar; > private Baz baz; > protected void setBar(Bar bar) { this bar = bar; } > protected void setBaz(Baz baz) { this baz = baz; } > public Bar getBar() { return this.bar; } > public Baz getBaz() { return this.baz; } > > } > > then in other package: > > { > Foo myFoo = new Foo(){{ > setBar(someBar); > setBaz(someBaz); > }}; > > myFoo.setBar(null); //Not visible > myFoo.getBar(); //Visible > > } > > > Why should the API change so my code can be a little more compact? > > > There is talk of adding 'returning self' as a language feature. I > > can't understand why we don't implement a globally applicable language > > feature that doesn't change APIs and works on existing code. Having a > > method return (this) at the end is somewhat broken.. If not just plain > > strange. > > > using (new Thing()) { setOne(); setTwo() } // override the default > > 'this.' within the block. > > > But that's another thread. :) > > > I guess ThreadLocal is more of an accepted pattern, even if I don't > > like it. > > > ThreadLocal assumes you code is running on that and only that thread. > > It also can cause problem with garbage collection (entities don't get > > collected when they should). > > > On Feb 23, 7:20 am, Christian Hvid <[email protected]> wrote: > > > There is a built-in connection pool and you are right; there is no > > > overhead in closing and opening a pooled connection. > > > > But you still have to say what database is used. And here it is the > > > database the caller is using unless explicitly stated otherwise. > > > > Wrt. ThreadLocal - the way it is used here is a bit like context > > > passing in AspectJ. > > > > I don't think it is evil. It is just not commonly used in Java. But it > > > has its merits and here it serves the purpose of reducing boiler plate > > > code. > > > > On Feb 22, 9:51 pm, Christian Catchpole <[email protected]> > > > wrote: > > > > > I think stageful statics are evil. I think ThreadLocal should be cast > > > > into a large pit and burried. :) > > > > > Isn't connection management a non-issue in web containers and even > > > > stand along apps with a good connection pool. When you open and close > > > > a connection, you are just borrowing a slot in a pool. There is no > > > > expense to it. In fact the pool will do clever things such as match > > > > prepared statements to connections which it has already been prepared > > > > on. > > > > > I'm simply suggesting that you might be able to get away with hiding > > > > the connection management. > > > > > I'm not trying to discourage your work. I have written a persistence > > > > layer which takes a completely different approach again. > > > > > Nice name by the way. :) > > > > > On Feb 23, 5:58 am, Christian Hvid <[email protected]> wrote: > > > > > > :-D > > > > > > Great, exactly. > > > > > > This is the point - it removes a lot of code - it is magic - and thus > > > > > smells of ... air - unless you are used to it. > > > > > > You avoid carrying around a JDBC connection object or a reference to > > > > > something like jdbcTemplate. > > > > > > Suppose you write a web application and in your servlet code or page > > > > > code you have a single try finally block that opens and closes the > > > > > database connection. > > > > > > Within that block you call into your business code and your business > > > > > code uses various database queries - all against the connection that > > > > > you manage with the try catch block. > > > > > > The reason it is a stack of connections and just one connection - is > > > > > that a stack allows you to use multiple databases / connections - so > > > > > this would work: > > > > > > public long accountBalance(int accountId) { > > > > > openConnection("accounting"); > > > > > try { > > > > > return queryScalar(Integer.class, "select balance from account > > > > > where id=?", accountId); > > > > > } finally { > > > > > closeConnection(); > > > > > } > > > > > > } > > > > > > int accountId = 27; > > > > > > try { > > > > > openConnection("logging"); > > > > > update("insert into log(account_id, balance) values(?, ?)", > > > > > accountId, accountBalance(accountId));} finally { > > > > > > closeConnection(); > > > > > > } > > > > > > On Feb 22, 7:59 pm, Robert Fischer <[email protected] > > > > > > wrote: > > > > > > > Now you've shifted the problem from a plumbing issue to a magical > > state issue. This is a major code > > > > > > smell and complicates the API in nonobvious (to the user) ways. > > > > > > > (Of course, I'm the guy who also finalizes his method arguments. > > So I've got some wacky opinions > > > > > > relative to Java norms.) > > > > > > > ~~ Robert. > > > > > > > Christian Hvid wrote: > > > > > > > But you can leave it up to the caller to open the connection - > > meaning > > > > > > > you just don't open or close any connections. > > > > > > > > public int getUserCount() { > > > > > > > return queryScalar(Integer.class, "select count(*) from > > people"); > > > > > > > } > > > > > > > > And then have the calling code open and close the connection: > > > > > > > > openConnection(); > > > > > > > try { > > > > > > > ... > > > > > > > getUserCount(); > > > > > > > ... > > > > > > > } finally { > > > > > > > closeConnection(); > > > > > > > } > > > > > > > > (The idea is that there is a stack of connections and when you do > > > > > > > something you always use the connection at the top of the stack.) > > > > > > > > On Feb 22, 7:24 pm, Robert Fischer < > > [email protected]> > > > > > > > wrote: > > > > > > >> The problem is this code: > > > > > > > >> public int getUserCount() { > > > > > > >> openConnection(); > > > > > > >> try { > > > > > > >> return queryScalar(Integer.class, "select > > count(*) from people"); > > > > > > >> } finally { > > > > > > >> closeConnection(); > > > > > > >> } > > > > > > > >> } > > > > > > > >> That's 1 semantically meaningful line surrounded by 5 lines of > > boilerplate plumbing. Which means > > > > > > >> that it's really 1/6th actual code, and 5/6th noise. That's a > > pretty poor signal to noise ratio. > > > > > > > >> It's even worse when you're dealing with raw JDBC calls, since > > you have to think about preparing > > > > > > >> statements and managing connections and data sets and the like. > > > > > > > >> ~~ Robert. > > > > > > > >> Christian Hvid wrote: > > > > > > >>> I don't understand - why would that be a problem? (That you > > have > > > > > > >>> explictly open and close your database connection). > > > > > > >>> On Feb 22, 7:09 pm, Robert Fischer < > > [email protected]> > > > > > > >>> wrote: > > > > > > >>>> +1 for Spring JDBC: it manages all that > > openConnection/closeConnection noise for you, which means > > > > > > >>>> that your JDBC code can *also* start to be expressive. > > > > > > >>>> ~~ Robert. > > > > > > >>>> Rakesh wrote: > > > > > > >>>>> have you looked at Spring JDBC? It has a similar interface > > and manages > > > > > > >>>>> the connections for you. > > > > > > >>>>> I think if you go down a non-orm route and want to have lots > > of sql, > > > > > > >>>>> Ibatis is quite common - not used it so can't say for sure. > > > > > > >>>>> Spring JDBC though is very nice and have used it extensively. > > > > > > >>>>> Rakesh > > > > > > >>>>> On Sun, Feb 22, 2009 at 2:21 PM, Christian Hvid > > > > > > >>>>> <[email protected]> wrote: > > > > > > >>>>>> Hi Java people. > > > > > > >>>>>> I have been toying with simplier ways of doing embedded SQL > > in Java. > > > > > > >>>>>> And would like your comments on this one? > > > > > > >>>>>>http://code.google.com/p/chalkmine/ > > > > > > >>>>>> It allows you to write code like this: > > > > > > >>>>>> openConnection(); > > > > > > >>>>>> try { > > > > > > >>>>>> int count = queryScalar(Integer.class, "select count(*) > > from > > > > > > >>>>>> people"); > > > > > > >>>>>> System.out.println("There are "+count+" people in the > > bin."); > > > > > > >>>>>> } finally { > > > > > > >>>>>> closeConnection(); > > > > > > >>>>>> } > > > > > > >>>>>> or > > > > > > >>>>>> openConnection(); > > > > > > >>>>>> try { > > > > > > >>>>>> List<Person> people = queryList(Person.class, "select > > name, > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
