A long time ago, I had used Applets in the Planexstrategy application to render statistical charts, such as bars, lines, pizza and so on. I developed these charts by myself and they were perfectly suitable for the system's needs.
Unfortunately, Sun Microsystems and Microsoft got into a patent fight and the first serious consequence was that Microsoft stopped distributing the Java Virtual Machine as a plug in of the Internet Explorer :(. Actually, after this disagreement, to distribute the JVM became very difficult for three reasons: first, Java was not widely known by non-technical people, thus they don't know about the existence of a certain JVM. Second, even if they know what is a JVM, it is very heavy to download it, considering the lower internet speed at that time, and also difficult to install. Third, a concurrent technology called Flash, created by Macromedia Inc. (Incorporated by Adobe nowadays), entered into the game to definitively kill the need for Applets in the field of interactive web pages.
The applet adoption had gone to a critical situation with the advent of a set of technologies under an umbrella called Ajax. The combination of HTML, XHTML, XML, SVG, JavaScript, SCC, XSLT, canvas and the main catalyst, XMLHttpRequest, allows the development of dynamic content without needing to refresh the whole web page. Now, the web page can adapt itself according to the user behavior. The problem of this model is the incompatibility of an Ajax code between web browsers, like Microsoft Explorer, Firefox, Opera, Safari and others. Every code should be tested with all of them before the production phase and it takes a lot of time.
To address this problem, people started to develop frameworks, previously tested with all those browsers, offering a large set of widgets to be easily used on the web development. Google Web Toolkit (GWT), Yahoo User Interface Library (YUI) and Direct Web Remoting (DWR) are the main frameworks currently adopted. The problem now is the ability to add new components according to specific needs of the software. It's too complicated for most developers to change a framework that mixes so many technologies. It is also difficult to be aligned with future versions of these frameworks.
Parallel to this revolution, the Flash technology has gained more and more attention with the possibility to create interactive applications on the web with the flexibility of a full featured scripting language, the Action Script. They saw an opportunity on the browser incompatibilities and created Flex to simplify the development of interactive web applications. In addition, they introduced Adobe Air, a runtime to execute Flash application directly on the desktop.
Flex and Air are technologies that show the future of web applications. Future? Well, the idea behind Flex was available on Java Applets for years! We can develop high quality web applications with incredible features using swing. With the availability of the web today, Applets are not valued just because of marketing reasons. Sun Microsystems just stopped to promote Applets.
However, in JavaOne'08, Sun brought a very important news: Applets will implement the JavaFX technology and the development of interactive applications will become even more efficient and gorgeous! It will simplify even more the model proposed by Flex + Air. Watch the video below and see what I mean!
Sunday, June 15, 2008
Sunday, June 1, 2008
My Netbeans 6.1 Personal Issues
After an intensive work with Netbeans 6.1 in all my projects this year, I was able to create my personal list of annoying issues. It doesn't mean I will leave Netbeans. Far from that! What I really want is to draw attention for those issues in order to get them solved on the next Netbeans version (probably 6.5 in October 2008). So, lets have fun!
Absolute References to Libraries in a Shareable File
If you add jar files, which are independent from those libraries managed by Netbeans, to your project, Netbeans will store absolute references for them in the nbproject/project.properties file. The problem is that Netbeans tries to share this file when you configure the project to commit versions to a SVN repository (I don't know about CVS, but it could be a common problem). Sharing this file will cause problems for other team members, mainly for those who use Linux, OpenSolaris and other ones that implement a different path syntax. My suggestion is to create a lib folder, as important as the test folder is, copy all independent libraries to that folder and store relative paths in the nbproject/project.properties file.
JSP Auto-complete Doesn't Work Very Well
I'm developing some JSF pages these days using Facelets, which adopts XHTML (XML based) format to code the view. I found a simple but very significant issue, as you can see in the figure below. When you finish to type a tag, which name follows the camel notation, the auto-complete feature doesn't understand that the closing tag should also follow the camel notation. If it's able to recognize the tag, why doesn't it just reuse its name instead of invoking a String.toLowerCase() method before? Then we press enter to confirm the auto-completing suggestion and the issue remains there.
It seems to be a very simple issue, but if you are writing hundreds and hundreds of code, it is absolutely annoying.
Another XML auto-complete issue is shown in the figure below.
If you see carefully, the tag doesn't have a body because there is a "/" character at the end, but the auto-complete suggests to add one . It's a minor problem because I can go on just pressing "Esc", but it's still inconsistent. The figure is pretty illustrative because it shows the previous issue as well, since the camel notation is not respected.
Performance Issue: Divide and Conquer
One of the most important advantages reported about the version 6.1 was the startup time reduction. They succeeded to reduce in 40% the time to start the IDE since the previous version. However, this apparent performance improvement was resultant from an on-demand loading, since resources load when the user asks for them. The figure below shows the exact moment of a project being loaded when the user selects it in the project tab.
So, you wait less time to load the IDE, but you wait the same time to start working. It's important to mention that the performance issue is only an issue at the beginning. During the work, the IDE behaves very well.
Issues in the Netbeans SQL Command Tab
I have heard that Netbeans 6.5 will have considerable evolutions on the database support. I hope so, because I'm having some troubles with the current one. Actually, it is not usable, since you have to resize the resulting columns all the time. Take a look at the video below.
As you can see, there are a lot of space available to show data on the right. The table should use all these space and also use a fixed size font, because sometimes we need to compare the size of the data in number of characters. A reload button is also useful if we want to execute the query again, keeping the last configured columns' size.
That's all for now. I reinforce that issues are present in our lives and they will stay for a long time. However, somebody should notice and expose them in order to get solutions and improvements to be even more productive and happy with Java programming.
Absolute References to Libraries in a Shareable File
If you add jar files, which are independent from those libraries managed by Netbeans, to your project, Netbeans will store absolute references for them in the nbproject/project.properties file. The problem is that Netbeans tries to share this file when you configure the project to commit versions to a SVN repository (I don't know about CVS, but it could be a common problem). Sharing this file will cause problems for other team members, mainly for those who use Linux, OpenSolaris and other ones that implement a different path syntax. My suggestion is to create a lib folder, as important as the test folder is, copy all independent libraries to that folder and store relative paths in the nbproject/project.properties file.
JSP Auto-complete Doesn't Work Very Well
I'm developing some JSF pages these days using Facelets, which adopts XHTML (XML based) format to code the view. I found a simple but very significant issue, as you can see in the figure below. When you finish to type a tag, which name follows the camel notation, the auto-complete feature doesn't understand that the closing tag should also follow the camel notation. If it's able to recognize the tag, why doesn't it just reuse its name instead of invoking a String.toLowerCase() method before? Then we press enter to confirm the auto-completing suggestion and the issue remains there.
It seems to be a very simple issue, but if you are writing hundreds and hundreds of code, it is absolutely annoying.
Another XML auto-complete issue is shown in the figure below.
If you see carefully, the tag
Performance Issue: Divide and Conquer
One of the most important advantages reported about the version 6.1 was the startup time reduction. They succeeded to reduce in 40% the time to start the IDE since the previous version. However, this apparent performance improvement was resultant from an on-demand loading, since resources load when the user asks for them. The figure below shows the exact moment of a project being loaded when the user selects it in the project tab.
So, you wait less time to load the IDE, but you wait the same time to start working. It's important to mention that the performance issue is only an issue at the beginning. During the work, the IDE behaves very well.
Issues in the Netbeans SQL Command Tab
I have heard that Netbeans 6.5 will have considerable evolutions on the database support. I hope so, because I'm having some troubles with the current one. Actually, it is not usable, since you have to resize the resulting columns all the time. Take a look at the video below.
As you can see, there are a lot of space available to show data on the right. The table should use all these space and also use a fixed size font, because sometimes we need to compare the size of the data in number of characters. A reload button is also useful if we want to execute the query again, keeping the last configured columns' size.
That's all for now. I reinforce that issues are present in our lives and they will stay for a long time. However, somebody should notice and expose them in order to get solutions and improvements to be even more productive and happy with Java programming.
Subscribe to:
Posts (Atom)