By compressing javascript files page loading time is significantly reduced.

Below I've wrote an ant task that can be used in a build file of a project to 

compress javascript source files. 

Before using it, be sure you have

custom_rhino.jar and ant-contrib.jar added to your classpath.

<target name="js-compress">

		<property name="input.dir" value=""/>

		<property name="output.dir" value=""/>

		<echo message="compress files from ${input.dir}" />

		<for param="file">

			<path>

				<fileset dir="${input.dir}" includes="**/*.js">

					<depth max="2"/>

				</fileset>

			</path>

			<sequential>

				<echo message="file: @{file}"/>

				<antcall target="js-file-compress">

					<param name="input" value="@{file}"/>

					<param name="output" value="@{file}"/>

				</antcall>

			</sequential>

		</for>

	</target>

	

	<target name="js-file-compress" description="compress js files">

		<property name="input" value=""/>

		<property name="output" value=""/>

		<java jar="lib/rhino/custom_rhino.jar" fork="true">

			<arg value="-c"/>

			<arg file="${input}"/>

			<redirector output="${output}"/>

		</java>

	</target>

Ant task  can be used as follows  

Supposing js deploy directory is in web/js:

	<antcall target="js-compress">

			<param name="input.dir" value="web/js"/>

			<param name="output.dir" value="web/js"/>

	</antcall>

Check out the first Romanian online AJAX dictionary: www.123dictionar.ro.

Similar to Google Suggest, the AJAX dictionary will provide instant word definitions as you type, or, in case no matches are found, similar words. By a simple double-click on a word you can navigate to new words in the destination language selected. Currently we have definitions for Romanian, English and German languages.

For the technical people out there, implementation was done using Prototype AJAX library, Scriptaculous for UI and suggestions powered by Lucene search engine.

Enjoy!

One day, after starting Eclipse 3.2, I noticed astonished that the autocomplete feature for Java classes did not work anymore. On pressing Ctrl+Space the popup list did appear, but it was always empty. This was a time of great mourning, since autocomplete is one of the killer features of Eclipse.

So what was the problem? In the evening of the previous day I did some reorganizing on my computer and moved the Eclipse workspaces to another drive (my operating system being Windows XP). It seems that this alone made Eclipse to fail the autocompletion.

QUICK FIX: Create a new workspace on the new desired location and import the projects from the old workspace. Do not forget to check the “Copy projects into workspace” checkbox so that the projects get copied to the new workspace directory. From this point on autocomplete should be back on its feet.

There are several limitations and problems of Apache Derby as noted in the previous post (http://blog.tremend.ro/2006/10/03/about-the-maturity-of-apache-derby/), but with Derby it seems that you’re still way better than with Hypersonic SQL. While I used Apache Derby extensively as described by the post, I did not end up trying out Hypersonic SQL for this same project I was porting. The reason was that when I asked around for potential issues right on the Hypersonic SQL mailing list, I received these responses.

To sum up, in Hypersonic SQL you can encounter database corruption, besides internal server errors. In Derby at least what you have in the database is secure. You might encounter some problems retrieving data when using more complex queries, but at no point when using Derby I never had to worry about the possibility of getting the database corrupted.

For those of you that didn’t hear about it yet, Apache Derby is a Java relational database engine that can both run as a network server or embedded in a Java application. You might have encountered Derby under its previous name, Cloudscape DB, shipped with the recent J2EE reference implementations. Sun also plans to include this product in JDK 6 but branded as Java DB.

I recently did some work on porting a tool to use the Apache Derby database engine, besides the existing MySQL 4.1 support. The database behind the application was of a medium size: around 50 tables and reasonably complex queries. I used at that time the most recent 10.1.3.1 version and also used development versions of the 10.2.1.3 version.

While overall Derby is a great idea and a good implementation, it is important to know that it is still immature. While doing the port I have encountered the following problem categories:

• unsupported SQL features,
• internal server errors,
• fatal server errors,
• stored function limitations,
• differences between the networked and embedded JDBC drivers.

Unsupported SQL features range from simpler to annoying ones. Alias visibility is a great issue here, so for instance the following SQL query is not valid in Derby:

SELECT SUM(table1.field1) AS my_sum1
FROM table1
GROUP BY my_sum1

Select item aliases are not visible in the GROUP BY clause, but _are_ visible in the ORDER BY clause!

Internal server errors range from plain NullPointerExceptions (in case of the COALESCE built-in function) to some protocol errors. Once protocol errors appear, though less frequent, one needs to restart the server (or the application, if you’re running in embedded mode). Frequent source of internal server errors is when one tries to overcome the alias limitation by putting group expressions in the GROUP BY clause (e.g. GROUP BY SUM(table1.field1).
Hopefully I encountered fatal server errors only in one scenario, and I managed to get over it but unfortunately not in a reproductible manner. This particular server error was caused by a more complex query which produced an internal server error. The server did not recover from it so that all subsequent valid queries were raising the same error.

It is important to know that Derby has a limited number of built-in functions, so one needs to frequently resort to custom stored functions. The problem with this is that, besides the lack of proper documentation, this support is quite limited. Stored functions can be defined only in Java. That would be mostly fine if it would work well. But for instance, if you want a stored function that returns an INTEGER value, you must specify the return type of the associated Java method as int. This means that basically you cannot return NULL integers from your function!

I have encountered some differences between the networked and embedded JDBC drivers. Actually only one, but which convinced me not to complicate things and to overall avoid the embedded driver. The problem is related to the way NULL values are specified for prepared statement parameters. If the java.sql.PreparedStatement.setNull(int parameterIndex, int sqlType) method is called with sqlType 0 (done by default by iBATIS) then it will raise an error, but only with the embedded driver.
There are several other limitations which would need a lot more to detail. The good news is that for most of these problems there are bug reports and developers are working to fix them, but I think that there’s still a lot to do to stabilize the whole thing. I managed to successfully avoid all the pitfalls and do the port, but the effort was too big in my oppinion.
I don’t say that you shouldn’t use Derby for your projects. It’s just that it is important to know its limitations and be sure that you don’t have a better alternative. As a sidenote, compared with Derby the Hypersonic SQL database engine is very much more unstable and featureless.