The Source for Java Technology Collaboration
User: Password:



Felipe Gaucho's Blog

Programming Archives


The Gods Must Be Crazy - Java Edition

Posted by felipegaucho on July 23, 2007 at 12:23 PM | Permalink | Comments (13)

This blog entry is the summary of a long discussion I had with my friend Jason Brazile about Calendar and Date manipulation in Java. Jason is one of those agnostics against Java platform and he is also a high skilled developer and researcher, so our discussions often unveil interesting details about the Java language. This one made me be totally stoned.

How many concrete implementations of the java.util.Calendar are released in your JDK?

  1. ONE: the Gregorian Calendar
  2. TWO: the Gregorian Calendar and a new one from Japan
  3. THREE: because there is secret Calendars somewhere
  4. None of the above

Well, I have to admit I am quite surprise with the answer but, like a Java Puzzler, the most correct answer is: None of the above. If you ask this for a specific version of the JDK, perhaps I can guess how many calendars you have available - but the generic answer considers it is dependent of the JDK version, and probably also dependant on particular revisions of JDK nightly builds.

Skeptic? Just copy/paste and run the code below:

	public static void main(String[] args) {
		// JDK 1.5: This is the hidden Buddhist bug
		Calendar budish = Calendar.getInstance(new Locale("th", "TH"));
		System.out.println(budish.getClass());

		// JDK 1.6: This is the undocumented Imperial mistake
		Calendar japanese = Calendar.getInstance(new Locale("ja", "JP", "JP"));
		System.out.println(japanese.getClass());

		// Any JDK: nobody really knows about the type - suposedely Gregorian
		Calendar suposeGregorian = Calendar.getInstance();
		System.out.println(suposeGregorian.getClass());
	}
For the ones without time to play mind games, the output here in my machine was this one:
	class sun.util.BuddhistCalendar
	class java.util.JapaneseImperialCalendar
	class java.util.GregorianCalendar

In respect of my lovely technology I will avoid to transcript here my first thoughts about that, but I propose to the reader the following questions:

  • What kind of Calendar is instantiated when you call Calendar.getInstance()?
    • Answer: I suppose it is GregorianCalendar, but if you are trying it in Thailand, who knows?
  • PersonalJava API and debug packages are supposed to be available in the production versions of JDK?
    • Answer: to allow an API to run an unpredicted behaviour based on an undocumented library seems weird. The Japanese Imperial Calendar seems less complicated because its package follows the recommended naming convention and it is just not documented. But the Buddhist Calendar should be the preferred Calendar of Mr. Val Valentino
  • If your system uses the Calendar.getInstance() method, is it safe? Even if some day it runs in a place containing a dangerous Locale? How easy is to find a bug if a developer is testing in a safe Locale and the production environment is in a dangerous one?
    • Answer: I have now answer for that ;) please help to enlight my mind on this topic.


  • The backslash of ResourceBundle

    Posted by felipegaucho on July 16, 2007 at 01:48 AM | Permalink | Comments (6)

    Few days ago I received a simple Java task: to take a comma-separated values (CSV) file and to create a Properties file for every column. The content of CSV file was delimited by semicolon; and the data was typed as the example below. Notice that first token of each line in the csv file represents a key and the other tokens should be split in different files - one for each language.

    Original CSV file

    Expected generated files

    text.csv

    text_en_US.properties

    text_pt_BR.properties

    key;pt_BR;en_US
    person.name;nome;name:
    person.birthday;aniversario:;birthday:;
    person.salary;salario=;salary=;

    person.name=name:
    person.birthday=birthday:
    person.salary=salary=

    person.name=nome
    person.birthday=aniversario:
    person.salary=salario=

    To solve this problem, I decided to create an ANT task with the following algorithm:

    1. Reading the csv file with a CSV Parser
    2. Creating a java.util.Properties for each language defined in the first row.
    3. For each row of csv contents (ignoring the header)
      • reading the first column as key
      • for the other columns
    4. Invoking the store(OutputStream out, String comments) in all Properties files.

    Quite simple, and it worked since the very first time I run it. But when I checked the generated files, I got a surprise: the generated file included some unexpected backslashes before some characters. Checking the API documentation, I got other surprises about the store(..) method:

    • The stream is written using the ISO 8859-1 character encoding.
      • SURPRISE: you cannot change the charset of the output :(
    • For each entry the key string is written, then an ASCII =, then the associated element string. Each character of the key and element strings is examined to see whether it should be rendered as an escape sequence. The ASCII characters \, tab, form feed, newline, and carriage return are written as \\, \t, \f \n, and \r, respectively. Characters less than \u0020 and characters greater than \u007E are written as \uxxxx for the appropriate hexadecimal value xxxx. For the key, all space characters are written with a preceding \ character. For the element, leading space characters, but not embedded or trailing space characters, are written with a preceding \ character. The key and element characters #, !, =, and : are written with a preceding backslash to ensure that they are properly loaded.
      • SURPRISE: when you store a Properties object in a file, several transformations are being done in order to escape special characters.

    The escape sequence rendering is well documented since Java 1.2, then I assume it was my fault not to know about that, but wait: I am developing software in Java for more than ten years now, and I really don't remember i18n files generated with backslashes - so I decided to ask about that in mailing lists. My suspicious was confirmed, almost nobody really knows about these minor tricks in internationalization Properties. Going deep in the code of Java I figured out the reason of this unconsciousness: the method getBundle(String baseName) of the class ResourceBundle supports special characters with or without the backslash, and since the most part of i18n files are created by hand, we never remember the minor details.

    From my original example, we have the following output:

    Original CSV file

    Properties.store(...) generated files

    text.csv

    text_en_US.properties

    text_pt_BR.properties

    key;pt_BR;en_US
    person.name;nome:;name:
    person.birthday;aniversario:;birthday:;
    person.salary;salario=;salary=;

    person.name=name\:
    person.birthday=birthday\:
    person.salary=salary\=

    person.name=nome\:
    person.birthday=aniversario\:
    person.salary=salario\=

    Interesting, a good reason to check the javadoc sometimes :)



    Black Belt results at Jazoon'07

    Posted by felipegaucho on July 02, 2007 at 11:45 AM | Permalink | Comments (11)

    The prizes and and the competition format were very attractive: 5 questions about Java SE, with victory criteria based on velocity and precision. With that in mind I showed up in the competition arena trying to be as fast as possible - a strategy mistake I figured out few minutes later.

    The questions were really not so hard, but you know, all that minor details about immutable classes and types are the known enemies since my first Java certification. I really don't know what I missed exactly because after finishing my session I forgot to check the summary presented in the screen, we were all having a great moment with a lot of fun, so I shall remember next time to check better what is going on around my competition cockpit.

    I am not sure if spending more time would be helpful to my plans, but at least I had the honor to be the fastest competitor :) The competition was wonderful, Black Belt is definitely suggested to be present in all conferences because it helps people integration and it is a lot of fun. See you in the next arena.

    julio.jpg
    Jazoon'07 Final Standings
    PlaceNameCountrytimecorrect answers
    1thJúlio FaermanBrazil2 min 04 seg5 / 5
    2thPerica MilosevicSerbia2 min 11 seg5 / 5
    3thDinko SrkočCroatia3 min 21 seg5 / 5
    4thNikola PostolovMacedonia7 min 08 seg5 / 5
    5thFelipe GaúchoBrazil1 min 15 seg4 / 5
    time.jpg


    Green grass project looking for innovative technologies

    Posted by felipegaucho on June 13, 2007 at 05:07 AM | Permalink | Comments (11)

    The core of the Footprint Project is alive, and during the next few days I will be organizing a minimum documentation in order to publish the first stable release. The current snapshot is able to generate and sign PDF documents through a concise code - a very good beginning considering the scarce resources of the project. Now it is time to check the outlook and to start discussing the more advanced and valuable features of the project, as follows:

    1. To generate a web-service for validating the generated certificates.
    2. To generate a client to the web-service
      • a web-application
      • a desktop or rich-client application

    I am here playing this fortune teller role in order to guess the chances of the new technologies to survive along the time. My crystal ball is displaying a mix of old labels and novelties like jMaki, JavaFX, Netbeans, Glassfish or EJB3 for example. Some of these technologies are already materialized in the software market, other ones are just whispering good features, prospective ideas waiting a chance to be adopted. We all play these mind games some times, and we know every Open Source project based on pure collaboration - no financial support and very small teams - need some kind of special attraction to be noticed by the Java community. So, our task now is to check the horizon and bet on the winners.

    The early adoption of new technologies is a strategy to give the project a chance to survive along the time and also a better chance to be adopted in real world scenarios. My past experiences taught me this strategy works, but it is also very risky and several good ideas suffer premature death due to the excess of effort required by the learning curve and the absence of mind share around the new concepts.

    In the other hand, it is not worth basing a project with medium marketing appeal in old and stable technologies because it ends like a scholar work: beauty, nice tailored but extremely boring. That kind of project everyone knows how to do but nobody has time to do, so your project is just something easy to be done and it will probably be overlapped by other project with the same nature - eventually with more resources or just a better pedigree.

    The innovation dilemma

    Now we have to think about the classical dilemma in software design:

    	How to design a software that will be innovative, useful by
    	its robustness and easy to maintain with scarce resources?

    I will leave the answer for you, I have my own concepts about that but I prefer to wait your thoughts to not influence your suggestions.

    Jazoon Kumite looking for Black Belt Developers

    Posted by felipegaucho on May 21, 2007 at 07:19 AM | Permalink | Comments (1)

    • Where: Jazoon'07, Zürich / Switzerland
    • Date: June 24 - 28
    • Prize: Your Java Honor (and some gifts)
    jazoon-logo-for-web-minimum.png
    challenge.gif

    So, check the mosquito flying, don't lose your focus and remember: one hit, one answer!



    Scriptlet programming challenge 4 students (JDK6 x Groovy)

    Posted by felipegaucho on April 11, 2007 at 06:06 AM | Permalink | Comments (1)

    ELCA announced an entry level scriptlet competition at Jazoon'07, with focus in innovative thinking and rapid application development based on the new features of the JDK 6 or based on Groovy.

    The prizes are quite attractive for students, including free Jazoon'07 vouchers and books from Amazon. And, of course, the best prize: proving your skills in one of the richest markets in the world :)

    All codes should be submitted by e-mail until April 30th, so hurry up with your best thoughts ;)

    Interested in participating? check details here.

    	def deadline = 'April 30th';
    	def name='alert'; println "$deadline!";
    	def magic = '0xCAFEBABE';
    	// see you @ Jazoon'07
    


    Basic Concepts about Object Orientation (a quiz)

    Posted by felipegaucho on July 17, 2006 at 12:44 AM | Permalink | Comments (3)

    One of the most tricky parts to learn Object Orientation is the concept of classification. The task of separating entities of the real word in groups and then enumerating the characteristics of each group seems quite simple for experienced programmers but could be messy for novice students. The discussion about the fundamentals of classification is very important to establish a baseline about what are classes. A clean explanation about this subject is a challenge for the teachers and the fluency about the OO terminology is the first duty for absolute beginners in Java or any other object oriented programming language. This test is not closed to Java - it was created to be independent of programming languages.

    The audience: this test could be useful for teachers interested in offer their pupils a revision material and also to interchange ideas about how to enhance the OO teaching methodologies. The students of introductorial classes about Java and OO could check their knowledge and discuss variations about the answers. The feedback from the students brainstorm and also from the teachers usage of this material is the most valuable result I can expect from this text. The questions below are the result of a continuous effort in order to facilitate the learning of the basic concepts of classification. If you remember an amazing question - the one that helped you to figure out the idea of classes, objects and its relationships, post your comments on the bottom of this page.

    Take the Test

    This section presents a set of questions about classification. Some questions refers to controversial subjects and could let a student to spend hours thinking about that. Don´t worry if some questions are not obvious - it is absolute normal on the first time you think about concepts on real world objects and their modelling in programming languages. The questions are presented in the context of the programming languages but the classification concepts are nor obvious neither inspired in the computing. The classification are an old concern of the human thinking and motivates researches in other areas such as Linguistics, Philosofy and Computer Science. The reading of classification theories in those diverse study fields is a source of inspiration and I recomend you to talk about that with your teacher and with your friends. Take all the time you need to complete this test, but resist the urge to peek at the answers until you finish. The test begins now.

    1. Mark ( T )rue or ( F )alse in the following assertions about the pictures:

      fig1.JPG

      1. Picture a represents a person (    ).
      2. Picture b represents a person (    ).
      3. Picture c represents a person (    ).
      4. Picture d represents a person (    ).
      5. Picture e represents a person (    ).

    2. If you group the pictures above, based on the characteristics of the represented objects, how many groups will you create? Why?

    3. Why didn´t you classify picture e as a person, if eyes are part of a person?

    4. Why didn´t you classify picture d as a person, if a person could have a car?

    5. Mark ( T )rue or ( F )alse in the following assertions about the pictures:

      fig2.JPG

      1. Picture a represents a vehicle (    ).
      2. Picture b represents a vehicle (    ).
      3. Picture c represents a vehicle (    ).
      4. Picture d represents a vehicle (    ).
      5. Picture e represents a vehicle (    ).

    6. If you group the pictures above, based on the characteristics of the represented objects, how many groups will you create? Why?

    7. If you agree all the pictures above represent vehicles, why can we separate these figures in different groups?

    8. What is a class?

    9. What is a subclass?

    10. What is a superclass?

    11. If you found a vehicle industry, what kind of products it will produce? Each vehicle produced by your industry will represent a class or an object?

    12. Can I say picture (c) is an airplane and also a vehicle?

    13. A vehicle can have different formats? What is polymorphism?

    14. What is inheritance?

    15. Can I say that the vehicle (c) flies? And can I say that the plane (c) flies? What is casting?

    16. Watch the picture below in order to answer the further questions:

      fig3.JPG

    17. If you group the words of the picture above, how many groups will you create? Why?

    18. What words compose each group? What is the meaning of each group you created?

    19. What is a method?

    20. What is a member of a class?

    21. Can you manipulate the internal pieces of the motor of a moving vehicle? Can you touch your own heart? Why not?

    22. Supposing you have wife, son and a car, answer the questions below using ( Y )es or ( N )o:

      1. A stranger can sing a song for you without your permission? (    ).
      2. Your son can watch your TV without your permission? (    ).
      3. A stranger can drive your car without your permission? (    ).
      4. Your wife can drive your car without your permission? (    ).

    23. What is the difference among public, protected and private members of a class?

    24. How can you avoid a stranger of driving your car without your permission?

    25. What is encapsulation?

    26. What are package methods?

    27. Can you change the format of your car wheels? What are constant members of a class?

    28. Draw an image for each of these classes: love, beauty and geometry.

    29. Did you have succes trying to draw the above classes? Why can´t you draw an image for the class love?

    30. What are the differences between concrete and abstract classes?

    31. What characteristic is shared by a bee, a plane and a cloud?

    32. What is an interface?

    33. Can you imagine a superclass for modelling bees, planes and clouds? What kind of problems could occur when we group so different objects in a unique model? Give an alternative to avoid such problems.

    34. Quick review: give a one phrase definition to the terms below:

      1. Classes
      2. Objects
      3. Interfaces
      4. Attributes
      5. Methods
      6. Class Hierarchy
      7. Polymorphism
      8. Encapsulation

    Well, done - here comes the answers: Click here to see the suggested answers.

    Conclusion

    The questions above compose a basic checklist I use to assess the learning rate of my students at the end of the semester. I usually use that test on the first or second semester of graduation courses. The test doesn´t have a score itself and it serves only to review some concepts and also to detect knowledge deficiencies. If you find the questions are easy, congratulations, you are ready to go on to the more sophisticated subjects - such as Design Patterns, Software Design & Architecture. If you have doubts about the concepts here presented, don´t give up - just read your book again and ask your teacher and colleagues about that. Object Orientation and classification are not trivial subjects and you don´t have to underestimate or superestimate them - you just have to understand them as the begining of your learning about Software Design.

    See you on the next test.

    Resources



    Creating Eclipse Warnings with AspectJ

    Posted by felipegaucho on March 09, 2006 at 03:48 AM | Permalink | Comments (6)

    Debugging with println is an ancient habit in programming - even the novice developers know about how fragile is such strategy facing the robust debugging tools provided by the most common IDEs. Despite that, everybody sometimes includes some commands like System.out.println("step #1"), or System.out.println("remember to remove this...") . The code smell gets unveiled when a client observes his console printing friendly words like this is just a test or even worst when a system administrator opens a server log and finds hundreds of debug lines printed with undeciphered numbers and letters. The most common strategy to avoid such programming deviation is to use guard tools like Checkstyle and PMD. These tools are excellent vigilants on the best practices of the code-style and patterns usage - but they seem weak facing non-Java concerns like the disabling println policy.

    On the Cejug-Classifieds Project, we have made some experiments with the creation of an Eclipse Warning to detect the usage of the println into the code. Every time a developer type System.out.prinltn(...) the warning icon appears beside his code - and we are very proud about the zero-warning status of our code. One can ask why do not simply require the developers to adopt the project code-style?. The answer is simple: it doesn't work, never worked and I don't believe a human being is able to obey such non intuitive rules whithout an ubiquitous advisor. The code-style maintenance can be a very boring task and every time a developer becomes tired he will try to get past the rules. An IDE guard can be (and must be) a good friend of the developers. The image below shows an example of warning generated when the developer types println anywhere on the code:

    aspectj.jpg
    Image 1: The Eclipse Problems View

    Creating an Eclipse Wwarning_co.gifrning with AspectJ

    The decision about using a pure Java implementation, based on annotations, or about using an external tool like AspectJ is very controversial (1, 2, 3, 4, ...). I will leave this discussion to a further blog entry - for now I will simply enumerate the steps required to create a new warning on the Eclipse IDE.

    • Download and install your preferred flavor of the Eclipe 3.1.+ (I'm using the WTP 0.7).
    • Use the Help/Software Update feature to be sure you have the AspectJ installed in your Eclipse.
    • Create a Java Project.
    • Right Click on the project name and choose Convert to AspectJ Project.
    • Done! You are ready to start to write the aspects definitions.

    A demonstration Project

    For a demonstration, I created a simple project with just one class and one aspect definition. The project can be downloaded here. Just download the demo and use the Import feature for assembling the project into your Eclipse. A tip: after installing the project on the eclipse, type some println commands on the test class, and observe the behaviour of the IDE.

    Below is the aspect code used in the example project. Note the call(* *.println(..))) - this command indicates that every println command executed by the JVM will be intercepted by the aspect definition. Other interesting code fragment is the warning definition, which declares a warning guard for the Eclipse View.

    	package net.java.dev.aop;
    
    	public aspect Test {
    		/** Everything outside the aspect package. */
    		pointcut not_aspect(): !within(net.java.dev.blogger.aop..*);
    
    		/** Pointcut to get any 'println' occurence (except in aspects). */
    		pointcut all_print_not_aspect():
    			(call(* *.println(..))) && not_aspect();
    
    		/** A warning definition. */
    		declare warning : all_print_not_aspect() :
    				 "Sorry, we can't use println in our project";
    	}

    Simple, isn't it? Not that much, the above example is just a bit of AOP. More sophisticated controls over the code, including complete use cases implementations are deeply discussed for a while by the software community. The aim of this blog entry is just registering an approach we are adopting in our project to try a better code-style and to evaluate its impact on the day by day of developers. Cejug-Classifieds has a lot of aspect definitions right now, and we would like to invite you to visit our project and to test by yourself - your feedback is very important to us.

    Cleaning the servlet requests from Html Injection

    Posted by felipegaucho on November 02, 2005 at 10:53 AM | Permalink | Comments (6)

    Holiday in Brazil, a good moment to taste crabs aperitifs on the sunny beach and to fix some old issues in the code of my Open Source projects. Some of these issues had revealed subtle gaps in our traditional programming - like the Web Application Security Vulnerabilities. Reviewing the code of Cejug-Classifieds, I noted the lack of control over Html Injection and I decided to dedicate my afternoon working around to fix that gap. This blog entry describe my first effort in order to reinforce the security of the code of my project, and it should evolve in the next weeks. It is an opportunity to share with you my project decisions and also a hope in order to learn more about that.

    Reading the excellent paper of Stephen Enright, I started to design a general solution to Html injection - adapting the paper tips to the patterns I´m using in the cejug-classifieds. Before describing the solution details, let me introduce you the idea of the classifieds: The Cejug-Classifieds is a study case, with the aim to produce a web-application based on Desing Patterns. All frameworks were ignored in order to provide a clean view over the layers of the application - since the jsp view to the jdbc persistence. The project started from my need to learn patterns - a first step in the Architect Certification direction.

    The project has a FrontController which receives all requests and then identify a Helper able to deal with each request. This Helper creates a Command, which use DAOs to manage data into a database. Factory and Filter are other patterns explored in the project.

    The idea is to prevent request parameters containing injection tricks, like scripting injection and Html injection. I designed a HtmlInjectionFilter to solve the problem: the idea of this filter is to remove the dangerous characters before processing the FrontController doGet or doPost methods, like shown in the figure below:

    http://weblogs.java.net/blog/felipegaucho/archive/hi.png

    Quite simple? Not yet. Despite the simple idea behind the filtering Html injection, some code details concerning the manipulation of requests become trickiest than expected - mainly the need of a modifiable map of the request parameters. The interface javax.servlet.http.HttpServletRequest is primary implemented through the class javax.servlet.http.HttpServletRequestWrapper and the map of parameters used by this class is locked, i.e., non-mutable. My filter was designed to replace the dangerous parameters by the clean ones, but the map doesn´t allow me to change the contents of the original parameters map. After some posts into discussion lists, I developed a request wrapper. I called that as MutableHttpServletRequest due to its mutable map of parameters. It works fine right now, despite the need to improve its functionality in order to reinforce its robustness. The class has a internal Map that overwrites the superclass map. The constructor copies all values from the original map filtering injection and then uses the clean map as the data structure of the request.


    Well, the work is under progress and some patches will be necessary before it becomes stable enough to a release. The project have promoted good discussions into foruns and discussion lists, and that is one of its major objectives. If you are interested in discussing more project details, be my guest to contribute.

                                                      Felipe Gaúcho - Dia de Finados 2005.
    


    Using elephant bullets to kill small ants

    Posted by felipegaucho on October 08, 2005 at 12:46 PM | Permalink | Comments (9)

    Few months ago we started two very similar projects in my daylight job. Both projects were WebStart applications based on simple business rules with a lot data validation and a fancy GUI requirement - almost all Swing components were used to produce the visual aspect our client had requested. Those projects shared the same life-cycle, under the same management model but with different teams. A project was carried out by a junior team while the other was formed by experienced programmers. Few weeks after the beggining, we noticed a critical difference between the projects: its sizes - both projects had a very similar number of code lines but the former was much heavier than the latter. The junior team produced their system based on third party libraries, while the experienced programmers provided a lightweight solution. Evaluating all the development process we observed a very common scene in the software industry: velocity versus reasoning. While the experienced programmers designed the software based on their solid background about the Java API, the newbies relied on Google to ask how to do their duties. Many tasks were solved through a download of a third party library. JDom, Log4J and many other JARs were dropped in the lib folder without much care concerning the impact in the project size. The tasks were quickly developed and any new issue was fixed through a new Google search. Other interesting aspect is that those libraries had also their third party dependencies, i.e., a chain reaction.

    You may conclude the problem was in the junior team, the people was unskilled for the project. But ask yourself how many libraries you adopted in your last project and also if all those libraries were really necessary.

    Few years ago people produced bank applications with less than 1Mb of memory (do you remember ambar screens?). Nowadays, any computer without 1Gb RAM seems useless for the developers. Part of this complexity comes from the user demand - friendly GUIs, robust systems to inapt users and the sophisticated technology and tools. Other aspect is about the interoperability among systems that pushes the simplicity away (SOA? EJB?). It is a natural motion in the software industry and people are not concerned about that - but there is the developers side. If one starts a simple project without thinking about its size, a system could depends on 10 Mb or more just to read mails and save files, and that's seems to be a next quality concern.

    When you think about software quality, do you include the size of the project in your evaluation? And what about dependencies?

    Ok, I'm not suggesting you to make all the hard working from the raw concepts and using only the Java API - but I feel sometimes we are loosing the sense of equilibrium in that question. My suggestion: to adopt good libraries just after comparing their features with the JRE API and also after a brief evaluation about their benefits in the project life-cycle, including the future perspectives of both projects - your project and the exogenous libraries.


    Let's think about that ....





    Powered by
    Movable Type 3.01D
 Feed java.net RSS Feeds