We Keep Coding

Why do we need converters for TextFormatters

My professor said that it is 'ideal' to use a filter and a converter for a TextFormatter. I looked at his examples and tried them, but couldn't understand why we need a converter at all.
From the docs:
A Formatter describes a format of a TextInputControl text by using two distinct mechanisms:
A filter (getFilter()) that can intercept and modify user input. This helps to keep the text in the desired format. A default text
supplier can be used to provide the intial text.
A value converter (getValueConverter()) and value (valueProperty()) can be used to provide special format that
represents a value of type V. If the control is editable and the text
is changed by the user, the value is then updated to correspond to the
text.
I am cleary something missing here. I get why you want to convert a string to an integer (for calculations etc.). But why do you have to have it as a part of TextFormatter? Can't we just use getText() and then just cast the text as we want to have the value?
One more thing: If we have a filter that doesn't allow non-numeric characters, then why do we need to take care of the conversion of the text to integer/double etc. with a converter?
Maybe I am just missing something very obvious.

You can't cast a String to an Integer (or any other type, except an Object): you have to convert it. Even if the text formatter has a filter that only allows numeric entry, the text field's getText() method still returns a string, which is usually not very convenient (as the entry in the text field likely represents a numeric value in some object).
You might need to get the integer (for example) value represented by the text field in many different places, so you centralize the conversion code in one place by including the converter as part of the formatter.
Additionally, the formatter's value is an observable property, so you can easily bind other properties to it, etc. This would be tricky if you needed to perform the conversion in a binding on the text field's text property.

Size of Strings and Calendar Objects Java

I am doing some basic (edit: reading and writing to a txt file), which requires me to store a bunch of expenses, and their attributes (i.e. name, price, date of purchase, etc.) I would like to be able to compare dates of purchases if possible. It occured to me that I had a few options when it came to what type of object the date of purchase should be:
I could make the date a Calendar object, and store it on the .txt this would mean storing lots of Calendar objects at once, and then easily compare the dates
I could make the date a String, store it, transmute it to a Calendar object, and then compare them
I could leave the dates as strings and when I am ready to compare them, create some kind of code to go through individual characters and pick out a certain phrase or set of characters.
Which of these would probably be best for keeping the load on the computer down? Also, how would you go about loading objects as they build up over time? Once a person has a lot of spending, it would get pretty hefty to load every single item.

I would strongly suggest using Joda Time wherever possible, rather than Calendar and Date - it's a much cleaner date/time API.
Beyond that, definitely make your object model match your domain as closely as possible. You're dealing with dates, not strings - so make your object model reflect that. You should be converting between strings and dates as rarely as possible. It not clear what you mean by "store it on the .txt" (given that elsewhere you're talking about a database) but using JDBC you'd use parameters anyway, without string conversions.
As for load - work out your performance requirements beforehand, try the simplest approach that works, and test whether that meets your requirements. Usually when people talk about having to have an efficient solution they haven't actually considered what they need. You talk about it getting "pretty hefty" to load every single item - how many items? Can you load them in a batch? Where will the database be? You'd be amazed how much data can be processed these days - but you need to understand the parameters of your problem before you make too many decisions that are hard to change later.

Using Hibernate's Restrictions.ilike() on a Timestamp

I've been thinking it over, and I'm starting to wonder if this is even possible.
User Perspective:
There's a table of data, and one column contains a date. The user can type in a search term like dec and get all rows that occurred during December.
Backend: A jqGrid is used for displaying the table. It sends the entered search terms to the server. The server uses the code
Criteria cr = session.createCriteria( DetailedLogEntry.class );
Disjunction disjunction = Restrictions.disjunction();
MatchMode matchMode = MatchMode.ANYWHERE;
disjunction.add( Restrictions.ilike( searchKey.getField(), searchKey.getData(), matchMode ) );
cr.add( disjunction );
to apply the search terms, and where DetailedLogEntry contains a Date variable to represent the database's TIMESTAMPfield.
Because searchKey.getData() returns a string, comparing it against a date object results in an empty set.
So I guess the question is...is it possible, preferbly through Hibernate, to apply a restriction against a Date object as if it were a String?

That's not possible. You'd need to use Restrictions.between() and give it an upper and lower date values. You could use SimpleDateFormat to convert from your String values to Date values and then perform the search?
If the user searched for Dec, would you expect all the log entries from December of every year to show up? Can they type in :"1, Dec" and expect to see all the logs from the 1st December for every year? If it is string matching on dates you are looking for, it might be easier to load all the data into your jqGrid and use javascript to filter the table based on the string formatted date values.

Range Query with Lucene 2.9.x - Dates in Index are not working

I use the following statement to index a date:
luceneDoc.add(new NumericField(key).setLongValue(date.getTime()));
I also use statements as follows to add text properties:
luceneDoc.add(new Field(key, value, Field.Store.YES, Field.Index.ANALYZED));
Then I perform a text property query:
author:hans
This works perfect. But when I perform a range query, nothing gets returned:
my-date-property:[20100101 TO 20110101]
What am I missing here?
I had a look at the index with Luke, I see all my text property for a document but the date properties only appear in the overview page... maybe that is normal.
I actually DO SEE the date properties if I add it like this:
NumericField field = new NumericField(key, Field.Store.YES, true);
field.setLongValue(date.getTime());
luceneDoc.add(field);
But: the query still does not work! Maybe it only works from Java with the Query Builder? I have not tried out that. But it would be great if the text query would work too. ANY IDEA???

If you want a range query to work with dates in the form of YYYYMMDD, then index your date like this:
String dateString = DateTools.dateToString(date, Resolution.DAY);
luceneDoc.add(new Field(key, dateString, Store.YES, Index.NOT_ANALYZED));

Try to declare my-date-property as DateField.
Since you are using a NumbericField I suppose that the range you specified is interpreted as a numeric range instead of a date range. In this case the numbers 20100101 and 20110101 are far too low to get any reasonable results.

Numeric fields and numeric range queries are absolutely brilliant, but they really are tricky to use for the first time!
Currently, the standard query parser doesn't support numeric range queries. In order to make use of numeric fields, you'll need to derive your own query parser variants and construct numeric range queries where appropriate.
Clarifying my original answer a little (I've just seen it referred to in a comment...), I should note that range queries, where numbers are converted to (usually) zero prefixed text work fine (albeit relatively slowly) in the standard query parser. From the original information posted, the question is how to use numeric (trie encoded) fields in a query. For that you need to parse a query in such a way as to produce numeric range queries (which understand trie encodings). These work much faster than text encoded numeric fields.
Good luck

Get a Date object out of Lucene Document

I have indexed a date in lucene using DateTools.dateToString to store the date in a particular field.
Is there any way to know if this was a date field, and more importantly how to get the date out again?
It's a fieldable with a long integer value.
Thanks

Lucene does not have strong-typing of fields, so the same field could have a date in one record and a string in another record, and a random integer in a third. It's up to your application to know what to look for in a particular field.
You can use the DateTools.StringToDate method to convert from a string back to a date.