Subject: Thinlet Titan Interview With Michael Nascimento Santos
Newsgroups: gmane.comp.java.thinlet.user
Date: 2004-12-17 01:36:53 GMT (3 years, 28 weeks, 5 days, 4 hours and 6 minutes ago)
Hello, Welcome back to the Thinlet Titan Interview series. Today let's welcome Thinlet committer and Genesis founder Michael Nascimento Santos. Q: Can you tell us a little bit about yourself? Michael Nascimento Santos: I've been programming since I was 11 years old. My interest on Java began when a edition of a famous magazine in Brazil came out with an article about a new "hot" programming language. I had tried OOP before using Clipper and lots of compiler tricks (#xcommand, #xtranslate etc.) and I was looking for a more powerful and expressive OO language that wasn't as low as C++. Visual Basic wasn't good enough, but Delphi actually appealed to me at that time. However, when I found Java, I got crazy about it almost immediately. It was very powerful but yet significantly simpler when compared to C++. It's been 5 years I've been coding almost exclusively in Java and I don't regret it. Nowadays, I help to run SouJava, one of the world largest JUGs, manage the JSR community @ java.net, serve as expert at JSR 207 (PD4J) and 250 (Common Annotations), and help to develop Thinlet as a commiter and AspectWerkz as a contributor. I've also spoken at many events, such as JavaOne, JustJava, BrasilOne, Javali (FISL), Abaporu, COMDEX Brazil and others. I'm very proud to work at Summa Technologies do Brasil, which is recognized by the community as being the leading company for Java development, mentoring and consulting in the country and also has an office at Pittsburgh. We've just released a Thinlet-based open-source framework (that does much more than UI, by the way) called genesis, hosted on java.net at http://genesis.dev.java.net Q: How did you stumble onto Thinlet? Have you tried out any alternative XML UI toolkits for Java before settling on Thinlet? Michael: One of our customers asked us which technology they should use to migrate their over-10-year-old client-server applications - which is a very common scenario in Brazil. They needed something that produced very lightweight (some of their machines have 16MB of RAM), responsive and easy-to-develop UIs. So we first asked everyone at Summa for alternatives to Swing (which obviously didn't meet the first and the third requirements) and Eduardo Ito, our "encyclopedia" guy, come up with around 50 frameworks that could be useful, including Thinlet, SwiXML, SwingML, wingS, Zaval, Millstone, Luxor, Naked Objects and others. After some testing, we were sure Thinlet was the way to go. In around 2h I was able to code the entire UI logic for a somewhat complicated logic. Designing the UI itself just took a few minutes, so at that moment I was sure Thinlet was just what they've been looking for. The funny thing is that although we did this research almost one year ago, they didn't start using Thinlet until very recently, but we've been using it since then in many projects. It's just great. Q: What's the hook? Why would anyone use Thinlet over say plain old Java Swing coding? Michael: For the same reasons we've been using it: it's easy to teach, easy to use, fast to develop with, produce responsive UIs without too much thinking and has a very intuitive API. Swing is painful and, it's very hard not to produce slow, unresponsive UIs with it. It takes ages for someone to master it. You don't want your UI programmers to be senior programmers unless you're doing some sort of very specific software in which you need high control and extensibility in order to do your work. Q: Can you highlight some of your apps built using Thinlet? Michael: Before Javali's effort to develop a free, open-source JVM, I was asked to take a look at the different open-source VMs already available and how they did compare to each other and especially to Sun's implementation. I developed client-server application consisting of a remote test server for each VM configuration and a performance meter workbench that would allow one to register remote VMs, select which tests to run, how many iteractions shouldn't be considered (warm-up iteractions), how much time to pause between iteractions, whether or not to invoke the gc between them, how many runs each iteraction should have, and much more. Then, you could start the remote tests and the workbench application would collect statistics about each run of each test in each VM, allowing you to analyze them using many different perspectives, such as test results per VM, VM performance per test and so on. This was my first "serious" Thinlet application and I learned a lot about how to develop applications using it. The first need I noticed was to write strongly typed setters/getters for properties, methods to create rows and items based on Collections and things like that. One application we are particularly proud of was one developed for a customer that needed to get rid of Dataflex in their core business, mission-critical application. It was a sales system with complex business rules and many UI iteractions that could cause the whole screen to be repopulated in order to always display consistent data. It was quite a challenge since one of the requirement was that our customer's existent team could develop it with us and actually understand the technology involved, at least well enough so they could maintain it by themselves. Before starting this project we were looking for a way to solve exactly this problem and we got our solution ready in time. We've developed a framework that solves the client-side problem by extending Thinlet and integrating it with commons-beanutils and commons-validator. Now, it's far more mature, handles many other situations and is available as open source software at http://genesis.dev.java.net I've also recently helped one of our customers to define a platform for PDA development using Thinlet with genesis. It was quite interesting to see Thinlet working seamlessly on the device.Q: Can you tell us some challenges you faced building your apps using Thinlet? Michael: We've found out Thinlet dialogs don't work very well for some users, so we had to replace their use with java.awt.Dialogs. A limitation that got in your way in the beginning was the fact you can't edit a cell in a table directly. We've got around this by opening an auxiliary window when the user double-click the row. There were some critical bugs in spinbox and table that took me some time to fix. Q: How did you get started on AspectWerkz? Michael: A friend of mine, Carlos Villela, told me about it once and I checked out their site immediately. It seemed very attractive to me since that first contact because it didn't require an odd syntax, new keywords or IDE plugins. Then, when I needed to do something serious with AOP (transparent remoting, the first genesis feature) I tried it and got it working really quickly. At that time, AW 0.9 was in beta and its license wouldn't allow me to use it in our project that would start in two weeks. I sent an email to AW user's list about it and Jonas Boner and Alex were very responsive, doing a release and changing the license really quickly. When I noticed they were so responsive and that AW was so easy to use and powerful, I was sure it was the right AOP framework for us. Q: Can you tell us what aspects and cross-cutting concerns you use in your Thinlet app(s) and how AOP fits into the Thinlet world? Michael: Well, most things at genesis are implemented with aspects: transparent remoting, transactional support, dynamic searches, enabling/disabling fields declaratively, showing/hiding widgets, calling validation before executing a UI action and much more. AOP is great when you use Thinlet on desktops and Java 1.3/1.4. Its usage has made our code very clean, maintainable and testable. It's a perfect couple