The SquizLogKeith Pitty takes a squiz at the world. |
|
The SquizLogKeith Pitty takes a squiz at the world. |
|
Whilst I didn't get as much out of today's talks as yesterday's I'd still like to share some of my impressions of the final day of this year's Sun Developer Days conference.
Improving Java Application Performance: Threading and Garbage Collection
Simon Ritter started by asking who within the audience had thought Java was slow when they first started working with it. Predictably the response was close to 100%. When he asked who thought Java was still slow he was surprised that many still said yes. Most likely due to poor application code, Simon said. Then he launched into a description of the HotSpot virtual machine heap layout and its use of different spaces - the Eden Space (for new objects), Survivor Spaces (for objects still alive when the Garbage Collector runs), Tenured Space (for objects that are old enough to be moved from Survivor Spaces when the GC runs) and, finally, Permanent Space (used by the virtual machine but not applications).
Simon really seemed to be in his element when he drilled down to discuss different GC algorithms (Thread Local Allocation, Parallel Copy Collector, Mark Sweep Compact, Low Pause Collector or Concurrent Mark Sweep, Incremental Concurrent Mark Sweep, Throughput Collector) and associated virtual machine options.
To illustrate the importance of using the latest JVM, he also mentioned several performance improvements in JRE 5.0_06.
Having discussed how different options can direct the JVM to use different GC algorithms, Simon also described how JVM options can be used to set ergonomic goals such as Maximum Pause Time, Throughput and Footprint. And he also stressed tuning possibilities such as increasing the heap size or increasing the size of young generation. Given that most objects (80 - 98%) are very short lived the last of these would seem very relevant.
There were other aspects of performance improvement discussed but one which he rightly stressed was this: make sure you do profiling before altering one or more of the many JVM options.
Java ME and NetBeans Mobility Pack
Not having had the need to use the Java Micro Edition, I sat in on Angela Caicedo's session out of curiosity. In her Columbian accent (another example of the diversity of the speakers at this conference), Angela certainly conveyed her enthusiasm for mobile applications. I didn't focus closely on most of the detail but I did find her demo impressive. Using NetBeans she was easily able to graphically develop an application that sent a message via Bluetooth to a Sony phone. Perhaps one day I'll have the need or make the time to explore Java ME applications.
Effective (Modern) Database Strategies
Another talk, another accent - this time the dinky di accent of Tom Daly from Adelaide. His talk addressed Sun's increasing focus on supporting open source databases, specifically MySQL, PostgreSQL and Java DB (based on Apache Derby, formerly Cloudscape).
Whilst describing the trend towards and business incentives for using open source databases, Tom was at pains to emphasise that he was not recommending migrating mission critical applications away from well tested enterprise database engines. However, it was interesting to learn about the MySQL benchmark showing more than 2,000 concurrent OLTP users. In the end, it's a judgement call.
And that was it. I almost stayed to learn something more about Ajax but the session looked fairly introductory (given that I've already done some reading) and I had real work to do back at the office... and, if the truth be known, some beverages to consume at beer o'clock.
This year's Sun Developer Days conference started in Sydney today and I was lucky enough to gain some insights into the evolution of the Java Standard and Java Enterprise Editions via a couple of excellent presentations.
Java SE: Tiger, Mustang and Dolphin
Having listened to Matt Thompson's American accent as he presented his keynote (Changing the Landscape of Software Development - the emergence of open source communities) my ears pricked up as Simon Ritter began speaking in his English accent. [No offence to Matt intended, it's just that I prefer British accents.]
After Simon talked a little about various new more open licences and the main features of Tiger (J2SE5.0), he moved on to elaborate on the JSRs that have been included in Mustang (JSE6), which is currently in beta. A major theme for Mustang is to make Java development easier. Three features that appealed to me particularly were:
File class has had useful methods such as getUsableSpace() added so that a Java program can determine how much free disk space is available;Mustang's successor, Dolphin, is still in the planning stage via the JCP so it is too early to be sure of its contents. However, Simon described some possibilities. The first, language support for XML, he was not entirely enamoured with. As he pointed out, the syntax chosen with Tiger's introduction of Generics has made the job of supporting XML syntax problematic. Angle brackets have already been taken! An alternative syntax that Simon showed looked counter-intuitive to say the least.
Of particular interest to me is the intention to support dynamically typed languages like Ruby and Python. Part of the solution for this will involve adding a new invokedynamic byte code.
Persistence for Java SE & Java EE Applications using the Java Persistence API in EJB 3.0
After lunch Rima Patel provided a change of focus and a change of accent. I'm not sure how long she's been in Boston but Rima still has an unmistakable Indian accent and I enjoyed her use of cricket in the analogy she chose to introduce her presentation about the Java Persistence API.
As Rima enthused, when compared with Entity Beans in EJB 2.1, the Java Persistence API (JPA) is like a breath of fresh air. Whilst TopLink and JDO have also influenced the specification (now in public final draft phase), much of what Rima presented was very reminiscent of Hibernate.
JPA uses a POJO (plain old Java objects) model, referring to POJOs as entities - not to be confused with Entity Beans. It introduces the notion of a persistence provider. The chosen provider (e.g. Hibernate) must conform to the API. Entities make heavy use of annotations. For example, at the most fundamental level, @Entity denotes that a class will be treated as an entity via JPA. A primary key is denoted by the @Id annotation. Relationships to other entities are defined using annotations e.g. @OneToMany.
JPA introduces an EntityManager type that works in the same way as Hibernate's Session. Associated with this is a PersistenceContext or ExtendedPersistenceContext, the latter appropriate for use with Stateful Session Beans. And speaking of session beans, they are also simplified by the use of annotations. Indeed the presentation could have been entitled "Death by Annotations" such is their prevalence!
Rima also discussed cascading behaviour, transactions (local and XA), embedded objects, composite primary keys, the simplified life cycle (New -> Managed -> Detached -> Removed), entity listeners and callbacks, entity inheritance, EJB-QL enhancements, dynamic queries and named queries.
Her enthusiasm was well founded. Perhaps it's time to take another look at using EJB. However, as Rima emphasised, the JPA is not limited to use within EJBs. It can be used with JSE applications.
At tea on day four of the Pura Cup final Queensland, only needing a draw to win the title, are 3/860 in reply to Victoria's 344. No, that's not a typo - they are 516 runs ahead!
Perhaps they have their eye on not only denying Victoria this season's title but eclipsing their record score of 1107, set back in 1927!
As my colleague said to me this afternoon,
"Refactoring makes you feel clean."So true. Fortunately for me I've had a few food opportunities at work this week to refactor some Java code and make it better for those that follow (either end-users or fellow developers). Without going into the details exhaustively (one was a simple, yet elegant introduction of a Java interface to enable me to replace conditional logic with polymorphism), it just felt good.
Yes, refactoring is good for the soul!
As I read more of this letter to the editor in today's Sydney Morning Herald I found myself agreeing whole-heartedly. Pat and Don Brown conclude:
Our rage derives from the fact that contemporary political leadership everywhere contradicts the truths that our lives have taught us. In the times of our darkest personal tragedies we were sustained by the love of people around us, and the hundreds of acts of human kindness this involved. We have tried over the years to pass on those kindnesses. To believe that bombs, barriers and bullets, or increasing personal wealth in limited sections of the population, will have the same restorative effect, flies in the face of history.A sad, sober assessment perhaps, but one with which I think it is hard to argue.Is there a leader anywhere in this sad world with the capability and the willingness to pursue an alternative vision and to give hope to a couple of older Australians?
And how can we, and hundreds more like us, help?
When indeed will we see a leader with the guts and persuasiveness to steer humanity onto a saner path?
What a debut by Sydney University's Stuart Clark, taking five wickets on debut, including the scalps of Smith, Kallis and Gibbs in his first spell!
Well done, Sarfraz!
I concluded my last entry pondering how much of an impact Rails will have in the market over the next year or two.
And then I came across a two page spread in today's Comptuterworld about how a Perth company, Spin Technologies, has been moving away from C# and into Rails development. So far they have five Rails production applications.
Good to see news of an Aussie company using Rails commercially.
Earlier today I read with interest a list of reasons why Ruby on Rails appeals to Todd Huss more than Java. Like Todd, I've been experimenting with Rails but Java continues to pay my bills and I still enjoy developing J2EE apps. For a while I've been mulling over what I see as the strengths of Rails compared to J2EE. Now let's see if I can enumerate a few from my experience.
First of all, some background. Over the last few months I've been developing a Rails app that I've called, for want of a more inspired name, Cricket Coach Helper. I've enjoyed it because it has given me a chance to get my hands dirty with Rails (beyond following the example in the book) and in the process build an application that has proved quite useful to me. For those of you familiar with cricket, the app has allowed me to record details of players, competitions, fixtures, match scores and to generate statistics (e.g. batting, bowling, fielding and partnerships) for the team that I have been coaching.
So what impressions of Rails has this experience left me with?
Installing Rails was a breeze. Then in a short time I had run rails crichelp to generate the structure of my application, created my development database with a Players table, configured my database.yml file, run ruby script/generate scaffold Player Admin::Player to generate CRUD code for the Players table and pointed my browser to http://localhost:3000/crichelp. I was ready to test my first iteration!
As I progressed beyond some straightforward CRUD functions I soon encountered use cases where a scaffold didn't cut the mustard. But, like Todd, I found that I could learn more details of the Rails framework as I needed them. Having the PDF versions of both the Rails book and PickAxe handy has been invaluable. Using WEBrick as a development web server also smoothed the way. And having the structure of the application pre-defined by Rails allowed me to concentrate on incrementing the application's functions rather than refactoring infrastructure code.
I think the way Active Record integrates the tables with the Ruby model classes is simple, clean and elegant. The way it infers attribute names from column names is liberating when compared to Java equivalents (I know Hibernate and TopLink have more flexibility to overcome impedence mismatches but how often is that really a problem?). And having the relationship declarations (e.g. has_many) together with additional methods that may be required all in the same Ruby class makes so much sense (It's an unfair comparison but I've just had an awful flashback to generating CMP Entity Beans!).
As I get to know Ruby better one reason I like it so much is because it reminds me of Smalltalk. Blocks and closures are sadly missing from Java. And I think duck typing works well too. However, I'm well aware of the debates about the relative merits of strong and weak typing. Anyway, I like Ruby. For example, it allows the programmer to manipulate collections so much more elegantly and tersely than Java (even Java 5).
The convention over configuration approach is definitely a strength of Rails. The structure to support separation of MVC concerns is a given. So there's no mucking about at the start of a project making decisions about standards to ensure MVC concerns are separated using a consistent approach. That's all good as long as Rails supports the technical requirements, which is not always going to be the case (e.g. responding to asynchronous messages is a case that is well supported in J2EE by JMS and message-driven beans).
The use of rake for automated unit testing of the model was similar in many ways to my experience of JUnit. However, I was particularly impressed with the way fixtures have been built into Rails. This is another good practical example of the productivity to be gained from the convention over configuration philosophy. On the downside, and I know this is trivial, I did miss seeing the JUnit green bar!
TextMate is an excellent code editor for Rails development, especially because it recognises Ruby and Rails syntax. I definitely found it superior to using Eclipse with the Ruby plugin, mainly because TextMate shows Embedded Ruby syntax in the view files whereas the Eclipse Ruby plugin is dumb as far as rhtml files are concerned. However, I could not help but yearn for the helpful features of an IDE like Eclipse. Simply being able to use code complete in Eclipse to find methods quickly or in conjunction with code templates is such a productivity booster. Anyone who argues that languages like Ruby, Python or Groovy are more productive because you have to type less is being blind to the huge benefits of a sophisticated IDE.
I need to research this topic more but to date I haven't seen a rigorous analysis of the ability of Rails to scale compared with J2EE. This is any easy target for those defending J2EE against Rails and I don't think reporting that a Rails site handled 2.5 million requests in a day is helpful or rigorous.
This is another topic that I need to research more. However, from what I have read, Apache's support for running Rails via FastCGI is problematic. I know that lighttpd is an alternative for production deployment but if it is problematic to run Rails on the world's most popular web server that would appear to be a limiting factor to widespread adoption. As I said, I need to learn more about Rails deployment so if you think I'm talking rubbish here, I'm happy for you to politely correct me.
I think Rails has a good fit for relatively simple web applications that typically provide a web UI to a database. I've seen web applications developed using J2EE for which that technology was an unnecessarily complex choice. Rails offers a promising alternative now. However, J2EE is not going to go away any time soon. It is a mature technology, is undergoing significant improvements (e.g. EJB 3.0) and is trusted by many corporations who have made a significant investment in it (wait on, that sounds like a defence for COBOL!). And, for some applications, it will be a more appropriate choice than Rails.
There you have it. Ten impressions from my experience with Rails so far. It will be interesting to see how much of an impression Rails makes on the market over the next year or two.
Forced into it I was.
Due to family circumstances I had to work from home today. After finishing work for the day, aided by the wonders of modern technology (the Internet, PuTTY, ssh, Rational Application Developer, CVS, instant messaging, email) and not so modern tools (the telephone) I was able to get a reasonable amount of work done as well as collect my daughter from school and make sure she was entertained and fed.
Oh, and I also placated the dog by taking him for a walk at lunch time.
But the really tough part of it was having to endure a refreshing pause between finishing work and preparing dinner (all right, my wife had made this chore easy - all I had to do was put the dinners in the microwave).
So there I was, sitting out the back, sipping from a bottle of Little Creatures, kindly given to me by a friend from Perth. It gave me time to just be, to ponder, enjoy what was happening in the garden and contemplate life without being in a rush, on the way from somewhere to somewhere else.
And, as I savoured another mouthful of a very pleasing Fremantle ale, I couldn't help but compare the difference between commuting two hours each way to Sydney and working from home.
I've pondered the benefits of telecommuting several days a week before. Now I think it's time for my boss and I to have a serious chat.
