Skip to main content

Most common problems, found in the code of reviewed applets

  1 post   Feedicon  
Replies: 0 - Last Post: October 31, 2011 15:13
by: Audrius.Meskauskas
« Older Topic » Newer Topic
showing 1 - 1 of 1
Posted: October 31, 2011 15:13 by Audrius.Meskauskas
I would like to share some thoughts that arise after seeing and frequently fixing various applet issues in Ultrastudio.org. They potentially may provide some hints about that Java should care more in the future.

"Many applets with good content just do not run well enough to be useful" - the opponents say and, indeed, some (way not all) applets need major fixes before they can even start properly. This is, however, seldom a result of some subtle individual bugs. Instead, some common pattern seems emerging. Here are the most typical issues:

1. Self signed applet without the real need. I do not know which bright mind has proposed this first; maybe some marketing campaign on digital signing has over-tried - indeed, there are applets that display these scaring messages on startup yet later do not do anything or almost anything that would require elevated rights! Most commonly the only reason is to provide option for saving or reading some user data file from the local file system, while in majority of cases it can also easily be copy pasted. Maybe file opening by explicit user selection should be considered secure enough also for the unsigned code; if not, it is better to try some workarounds if the signing is required only for some tiny helper functionality. Do not self-sign at least the applet that does not use any elevated rights at all!

2. "Mutated Swing rudiments". Many applets contain something that looks like reduced versions of Swing. Sometimes this is just several funny classes, but may also be complex libraries, several times and more exceeding the code responsible for the actual functionality of the applet. Most likely this was done trying to adapt previously Swing based applets so that they could also run on Java 1.0 or 1.1. In any case, a lot of work has been spend by the the authors and a lot of mess introduced for the future maintainers. With the full understanding of why this was done, we still need to tell that has happened.

3. Image (and in general resource) loading. It looks like image access has been done both unnecessarily complex and specific. The code usually stops working after we package various icons directly into .jar rather than dropping them on the web, and we need to fix the code to make it packaging-independent.

4. Animation uses threads, always. No any single applet in our collection ever used timer for animation, while some do after we fix them. This may be because developers do not assume they have javax.swing.Timer available, but also point that timer based animation is somehow unclear or not known widely enough. Depending on how threads are used the animation may hang but may also just run fine - matter of luck.

5. Assuming fixed size. Many applets are written assuming that they will always run having some fixed dimensions, likely the dimensions that are specified in the applet tag. The problem is, even if undocked, the applet gets different dimensions after the recent browser changes the zoom level. Usually it is trivial to fix applet to run well under any size above the minimal limit. This becomes even more important if we later get the possibility to undock.

6. "Standard libraries", "common frameworks", "unified platforms" and the like - different in every applet. Why so many developers implement the fully focused task by first writing some parody of a-la general purpose tool? Quite often these "libraries" contain a lot of never called code, and the used code would be much easier to understand and maintain if embedded directly into the concrete implementation - it is not standard anyway. It must be a clever threshold before developing a library is useful; do now write a library just to draw a triangle with some mysterious extra options that later are not called anyway.

7. Action event handling is frequently a mess. It is not unusual to register the same listener (as a rule an applet itself) for all buttons and then have a gigantic if that checks the event source, command, the button title text of whatever comes to the authors mind. It is possible to have anonymous class or inner class. Anonymous class may just call the method of the enclosing class or have all functionality inside. Likely there are too many ways to do this differently, and it is not obvious how the simple "hello world" application should operate.

8. "User friendly" GUI designers are a tragedy. They most often produce near unreadable and unmaintainable code that needs the same designer to work with - ten years later this can be a problem on itself, even not taking into consideration that there are too many different designers and some of them are little known. Some designers add they own proprietary dependences, requiring to rewrite sections of the code before we can even build it. If we need to do something with such a class, we usually rip all generated code out, replacing it by hand-written implementation that usually is three or about times shorter, readable and most often handles resizing much better than the generated version.

While notable, the listed issues have not been blockers in the most of cases. Many applets were running one or another way even if they had these problems inside. The size of the "major part" (the one containing and delivering the expert knowledge") is also varying dramatically. In some cases it is just several lines of code, pointing clearly that JavaScript application would perform equally well have it Canvas. But there are also applets where the expert part spans through many classes, uses OOP heavily and runs real numeric simulations. Such visualizations, where they are serious, still may require more complex and powerful engine.

Replies: 0 - Last Post: October 31, 2011 15:13
by: Audrius.Meskauskas
« Older Topic » Newer Topic
 
 
Close
loading
Please Confirm
Close