[...]However, if I'm working by myself, I find it helpful to leave the last test broken at the end of the day. When I arrive in the morning, I know just what to do to get started: fix that test. That's usually enough to get me started on my day
-
There are almost 2 weeks from the last post, but it seems that this end of year will be a very busy one, so I will have little time to write. I hope I'll be back more active on the next year. Now, getting away from this type of excuses and back to the topic. Thanks to JavaRanch I had the opportunity to read the last Kent Beck's book on JUnit: JUnit - Pocket Guide. As the name states, it is indeed a pocket guide: 77 pages, from which almost 20 are about JUnit usage inside IDEs (if the editor would cut these full of images pages too and reduce a little bit the format, the book would enter your pocket without any problems [smile/]). Otherwise, the book contains a little of everything: history, reasoning behind creating and using JUnit, a short presentation of the framework architecture and implementation, reduced JUnit API comments and very few examples. Some short comments on possible extensions and that's all. I think everything inside is in pocket suited format. Concluding, I would say that JUnit - Pocket Guide is an (very) entry level reading for those wanting to have the first contact with JUnit. More infos are to be found on the JUnit site and other books. Next reading: JUnit Recipes a book recommended everywhere and with great reviews. Update: in the pocket review above I've forgot to pass the idea I loved the most:
-
All this has started with a forum discussion on the articles on TSS: JDO Query Part 1 and JDO Query Part 2 I think that JDOQL has gone a long way ... in the good direction and it shows now a lot of power. I like very much the idea of objectual querying, i.e.:
Query q = pm.newQuery (Seller.class, "accountNumber == '0072'");
or the more advancedQuery q = pm.newQuery (AuctionItem.class, "description.matches('.*Connect.*')");
idea that has been used by Hibernate for a while. This is quite impressive and I find it very neat. But in a way reading the articles I had the feeling that the spec stopped in the middle and proposed:Query q = pm.newQuery (AuctionItem.class, "winningBid.bidAmount > reservePrice"); q.setResult ("title, reservePrice, winningBid.bidAmount, winningBid.bidder.user.userName");
I consider the above unnecessary API. I am not sure (and I mostly believe that currently this is not possible), but I would write the above in the following way (again a form of this is already available in Hibernate):pm.newQuery("AuctionItem.title", "AuctionItem.reserverPrice",....);
or removing the varargs from above:pm.newQuery({"AuctionItem.title", "AuctionItem.reserverPrice"}, filter);
Why I would like this? Because in this way all the querying is objectual and no additional API is involved. Unfortunately the above hides a little problem too: compile time check. If I change the AuctionItem, than I will discover that my query is broken only at runtime (this maybe has already required a redeploy of the app). So I think the best solution would allow you to build the query:pm.newQuery().addResultField(ai.title) .addResultField(ai.reserverPrice)...
(note the missing quotes; but still a problem as I needed an instance of AuctionItem :-( ). Hoping you got my point, I would like to move forward. I like that a lot of aggregate function have been taken into account, but again I feel it is a mix: what does it really mean in objectual model count() or distinct? These are rather DB functions and I would like to have it like this:addResultField().setAggregateFunction()
or maybe betteraddCount(addDistinct(ai.title))
I see the point on having these on a ORM, but in a more generic spec as JDO intend to be, I think they must be more near to objectual model than to RDBMS. And finally - at least for the moment - I would not go for inventing new notations/notions for something already existing: indeed regexp can be seen as a good selection filter but I haven't seen the (?i) till now. Also why bothering to create unbound variables when an implicit variable would solve it? Here I might be wrong as I see some interesting usage inString filter = "bidder.bids.contains(b) && b.item.seller == seller && b.item != this"; Query q = pm.newQuery (AuctionItem.class, filter); q.declareVariables ("Bidder bidder; Bid b"); Collection results = (Collection)q.execute ();
-
Unfortunately I have succeded somehow to overwrite this article. It is now available here.
-
Some time ago I was investigating the possibility to have a light in-memory model of java sources. My research has gone mainly to QDox and xjavadoc, passing also through commons attributes. Unfortunately, after following the mailing list for a long time, I am unable to say that the support for JDK 1.5 will be available soon (or at least at a specific moment in the future - even if the developers are already taking into account this). So, I get back a little bit and evaluated the problem some other way:
- how are they implementing these features?
- why are they implementing this way?
- which way should i go for?
- How are they implementing these features?
- QDox: has its own model that is able to keep information about 5 elements: java types, java classes, java fields, java methods and tags. So in order to support JDK 1.5 features, they will need (in big lines) to improve the java type to support generics and add a model class for annotations. Another interesting point of QDox is that it is using its custom java source lexer/parser written in flex and yacc (i guess). They will need also to enhance this too.
- xjavadoc: has its own model too. In big lines it supports the same elements as QDox does (which in fact represent their real working target). In the same direction, xjavadoc uses its own parser based on JavaCC. So, I would say that xjavadoc has to do the same enhancements as QDox.
- Why are they implementing this way?
- While the model used in both cases is very clear and I think that with the enhancement I was talking they will be stable for a long time, I am not very sure why both solutions have chosen to use custom parsers. I know that javadoc tool is memory expensive while working with large object graphs, I guess if it is used to parse only bunches of sources and than solve references in memory it would possibly be a viable solution. Here I would like to have some insights of the guys involved in QDox and xjavadoc
- Which way should i go for?
- I would say that imo QDox seems more alive than xjavadoc (even if the xdoclet guys are working hard). One solution would be to get involved into QDox dev and make/contribute with the enhancements. (But I don't know if I have a place there as they are already many and I am not sure they are in need for my help). Another solution would be to reinvent half a wheel and go for a solution based only on javadoc parser. While I see some benefits in doing this (assuring the compatibility with the latest JDK available and independence for any custom parsers, and possible to offer access at the code level, without really parsing it), I think I must find out firstly the answer to the above question.
-
Just a few minutes ago the Firefox 1.0 is out. I hope their servers are prepared as I think a lot of people will go for it (Index of /pub/mozilla.org/firefox/releases/1.0). Congrats! Hope this will be a winner!
-
The trick I have found for custom getters/setters in Eclipse seemed very nice. I would like to add more on this: the prefix and suffix accepts a comma separated list of strings that will be ignored by the generator. Wow ... very very neat.
-
I just finished reading the Gavin King's interview published on Javafree.com.br. I am using Hibernate for quite a while and I must say I am very happy with it. I have even taken a look (not so deep) to the upcomming Hibernate3, but I still found myself unable to say:
The Hibernate3 core (currently in alpha) is the most powerful ORM engine in the world - and it will take a little while for others to catch up.
, when I know thatUm, traditionally, no, we did not pay that much attention - I was much more comfortable being guided by request from users, than by "what the other guys got".
Even if Gavin and Hibernate have always had their fanatics(*) [smile/], I am wondering ifHowever, more recently, we have done some feature-by-feature competitive evaluations of the two leading commercial ORM solutions, just to make sure we didn't miss anything.
was done the same way the Microsoft vs IBM solution comparison was done. I haven't seen the results published anywhere and I am wondering which are those 2 leading solutions that have been compaired. I have seen the same statements coming from the TopLink team so I will not jump to a conclusion so quickly and I will wait to read at least the comparison results. On the same direction I have found out that the guys/companies developing non-RDBMS solutions would have to leave their business:How do you see alternatives to relational databases, like XML and OO databases, or Prevayler? We don't see them ;-)
I will give credit to the [blink/] in the end of the sentence and hope that not every other solution will stop their existance and just jump into the RDBMS field immediately. When SUN has announced the initiative to create a common spec out of JDO and EJB3 I was wondering which will be the future of JDO. Gavin's opinion isWe don't see any future for JDO.
, but I am thinking that this future will be the same for Hibernate 2 users as for JDO users. Gavin's feelings about JDO have been expressed also on some other occasions. What is Craig Russell's opinion on this? Finally, I find myself asking if Gavin expressed his true feelings on these or rather it was a somehow furious interview? Disclaimer: do not consider the bad meaning of fanatic word. -
I don't want to challenge R.J. but I feel this trick is quite interesting. During the last weeks I have found quite annoying to use the conventions of the projects I am contributing to, because they impose the usage of
m_ands_notations and for a long time I have considered that this is a killer for the getter/setter generation in Eclipse. But no, it is not: you can configure Eclipse to consider some prefixes and suffixes and these will be removed from the generated getters and setters. Step by step: - Window -> Preferences -> Java -> Code Style - Variable type: Fields and add the m_ prefix - Variable type: Static fields and add the s_ prefix (if you really use getters/setters for static fields [blink/]. Congrats again to the guys developing Eclipse! -
With the new release milestone Eclipse 3.1M3 is approaching fullfilment of J2SE features. Currently (as you can read in Eclipse 3.1 M3 News - Part 1) 97.95% of the compliance tests are already passes (in other words there are still 223 tests out of 10863). Good work guys!
-
I was writting a few posts ago (at the moment Google Desktop Search was the hero of the moment) that I am probably considered a bad Windows user: I haven't touch Outlook or Outlook Express for quite a long time and I am opening IE just to set the proxy options to allow the Eclipse Browser widget to work fine (this is quite a trick). For a long time for me web browsing and mail clients meant just Mozilla Suite. I was very happy with it. But in the last few months I have started slowly to move away from it. But, hey wait a minute. I am not going the so far away. I have just passed to its little (but quickly growing) brothers: FireFox and Thunderbird. I have regained trust in FireFox starting with the 0.9 version. There I have rediscovered the stability and the smaller memory footprint. I have used it in parallel just up to 1.0PR and I must say that after some time the Mozilla browser just remained closed. Now I am on FireFox 1.0RC2 and probably I will be between the first getting the 1.0 [blink/]. About the other brother I have only good words too! Thunderbird installed smoothly taking control over everything I have had in Mozilla. Moreover it brought into scenes the Find Folders, a feature that I was looking so disparate after (from time to time I have read some developer documentation in order to finally write down my own plugin for this). But the guys have read my mind and the 0.9 came out having this. It is a very warm and pleasant feeling to know that some guys are developing the right things. So, good bye my friend Mozilla Suite. It has been a pleasure working with you! Welcome little brothers and I hope that my experience with both of you will be as smooth and delightfull as with your big brother. I hope for you three that some day you will be the top of the tops! (for me, you already are for quite a while). PS: I will probably miss the common about:config [smile/].
-
AspectWerkz guys (Alex Vasseur and Jonas Boner) have announced the 1.0 final version. I want to congratulate for the long way they have gone and wish them to keep up the good work! Congrats! You can read about the current features and release notes while you download it.
-
Here is an old link to a nice (good) list of Java - to - Relational solutions. Enjoy.
-
After a few time spent on this subject and a few posts on this, I think I have reached the conclusion moment. Shortly, my goals were:
- to find a documentation format easy for writting and enough configurable as regards the generated output
- to allow different output formats
- light/easy/few tools required
- html
- docbook
- xdoc
- wiki
- html way too related to output presentation
- xdoc quite powerfull and not very very linked to presentation. It misses a few things: imbricated section levels, meta support.
- docbook very powerfull, but way too complex (from both points of view: writting and configuration of output)
- wiki interesting, but the output is too limitted and requires a heavy solution (servlet container, except you are using the Wiki Plugin for Eclipse)
An enhanced xdoc format (overpassing the missing features presented above) and a couple of XSLs to transform it either to a final document or to put it in the format of one of the other above mentioned formats.
Somebody could argue that I have tried to reinvent the wheel, but this is not the truth. I have added to the xdoc format just a few more things:- level attribute for section element
- indefinite section recursion
- meta child element of properties element ... and that's all
-
This weekend I have passed some time checking the code generated by dtoGen™. I have been trying to remove any possibility that a NPE would occur in the generated tool class. (for those not knowing about dtoGen I would recommend a quick read of the intro). I have had to check against NPEs for any instance forced convertor (something like model.getValue().intValue()). I have had to check against NPEs for collections, arrays, maps manipulation... and at a moment I got angry on these NPEs. Why should I check it and not the compiler? (hmmm wait a minute is this possible? would it be fesable? would it be really good?). I sat down for a moment and thought of this. How easy would life be without NPEs! But no, this is not true. The compiler should create check points for any instance variable access or for any instance method call. The code will grow over and over. This is not the last issue. What would it happen when a possible NPE occur? Just signal you? Ignore that piece of code? Wow... after object oriented programming we would begin the fuzzy programming era. I would go home and say: I wrote down today a program. There are many chances it will run. But also many chances it will go a path I don't even imagine it can. So, bye bye swearing NPEs. They are a good evil!
