I was playing around with BlockingQueues and I thought to myself if there was a way to ensure graceful shut down of threads.
For example, what if I created a producer-consumer queue and needed to shutdown the JVMs? However, I want to ensure that the queue is emptied out before the JVM shuts down. It appears that I need to create a shut down hook class and register it with the current runtime:
package test;
public class ShutdownHookDemo {
public void start() {
System.out.println("Demo");
ShutdownHook shutdownHook = new ShutdownHook();
Runtime.getRuntime().addShutdownHook(shutdownHook);
}
public static void main(String[] args) {
ShutdownHookDemo demo = new ShutdownHookDemo();
demo.start();
try {
System.in.read();
}
catch(Exception e) {
}
}
}
class ShutdownHook extends Thread {
public void run() {
System.out.println("Shutting down");
}
}
Are you having these types of Eclipse-related errors???
The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Enum. Fix the build path then try building this project
The type java.lang.Enum cannot be resolved. It is indirectly referenced from required .class files XXX.java
So this issue took me a few hours to resolve. I’ve looked at other blogs and people say that you should check if your eclipse is pointing to the wrong JVM. e.g. 1.6 vs 1.5
But this wasn’t the cause of the issue for me. So I work on MBP. With the latest OS updates, the JVM directories are overridden. This is a pain especially if you are working with legacy applications using JVM 1.5.
I tried to download a 1.5 JDK/JVM version, but that copy appears to be incomplete or corrupted. So the best thing to do and you may not have been doing this, is to restore the java directories using time machine. On my machine, I would go to:
/System/Library/Frameworks/JavaVM.framework/Versions/
Then enter time machine, and replace all the directories with that past version that worked. BTW, don’t delete the A directory. You would think it’s some junk directory, but it’s not. It’s a required directory that some engineer did not think to name properly.
In eclipse, I went to Preferences -> Java -> Installed JREs and selected the JVM 1.5. If it’s not there, click on the Search button. This will search your system for all installed JREs.
Next, go to Project -> Properties -> Java Build Path and make sure the JVM 1.5 JRE System Library is added to the list. If not, you should click on the Add Library button , select JRE System Library and select workspace default JRE (JVM 1.5).
This took me 3 hours to debug!!! And it’s 3 am…
Although I have upgraded a few months back, I felt compelled to re-visit the issue I faced when upgrading from Leopard to Snow Leopard. For some odd reason, my code was throwing errors of java version incompatibilities.
It took me a while to realize that I wanted to use Java 1.5 and my environment variable was pointing to the 1.5 directory:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0
However, the actual java files inside this directory were overridden during the upgrade to be 1.6.0. They were either overridden or the symbolic link created was pointing to 1.6.
I’m still trying to get a grasp why there are symbolic links in this directory and why can’t the system just reference that particular directory explicitly.
But in any case, this led to a few hours of debugging when I realized 1.5 did not exist. So I had to reinstall JDK 1.5 from Sun (now Oracle) site. It fixed the issue. But recently, I had to install a corporate software on my machine. It kept on crashing and I raised a ticket to the appropriate team.
There were a lot of back and forth correspondence indicating that Snow Leopard works with 1.6 only. This is contrary to what I have been running the last few months. Everything works fine except for this one software install.
So I had to remove Java 1.5 so that the software can be installed correctly. Then, I reintroduced Java 1.5 back into the system. It really is some weird thing going on.
I was referred to this url: http://wiki.oneswarm.org/index.php/OS_X_10.6_Snow_Leopard
The directions are very good. The part about setting up 1.5 is odd as you have to create a few symbolic links in order to tell the OS that this directory is in fact 1.5. It’s not intuitive at all.
In fact, if you execute: ls -al
You see the java versions have many different symbolic links pointing to actual java versions, or CurrentJDK, or Current. Then I found another article where it would be ideal to set your $JAVA_HOME environment var to be: /System/Library/Frameworks/JavaVM.framework/Home
Guess what? This is yet ANOTHER symbolic link pointing to the …/CurrentJDK/Home
I understand that this helps in changing JDK version across the whole system, but I find it difficult to discover this without research and testing. Why was it done this way, I do not know.
Do you?
So this error appeared after I compiled my java classes, packaged them in a war, and deployed it to the application server. The only major change that happened to my system was an upgrade to Snow Leopard. I searched the web forums and discovered that this issue is due to compiling the java classes with a different Java compiler version than the JVM version on the application server.
How can this be? It was working fine all this time. I checked my JAVA_HOME environment variable and it was pointing to a JVM-specific directory: 1.X.0
On the command line, I typed:
javac -version
and it returned the latest version. So I thought that maybe the OS upgrade overrided my default Java compiler. I started to look into the ant file to find a task attribute to point to a specific JVM. After redeployment, the error still persisted.
So finally, I thought about testing the actual java compiler, in the 1.X.0 directory. I typed: javac -version and it returned again the latest version. I tried: ./javac -version.. the results are the same.
Then I traversed to the other previous versioned directories. All of them returned the latest version.
This was really odd. So finally, I decided to override all the directories from the AWESOME Time Machine. Specifically, I replaced the directories with the directories before the OS upgrade.
I ran the compilation and deployment and the issue is RESOLVED.
I’m not sure why Snow Leopard overrided my directories with the latest Java compiler, but I’m glad the war file is deployable. If I didn’t discover this issue, then it would have caused me unneccessary stress and panic if it was a release day.
I have a passion in writing Java and Javascript (JS) code. I worked at eBay for 2 years on Javascript-only projects. I worked at Sun, BEA and Linkedin for 3 years working in Java-only projects. Now I work on a combination of Java and JavaScript features for my current projects. So I have some experience on how Java and JavaScript (JS) developers treat each other. It is similar to a social hierarchy. Who is on the higher social scale depends on whom you talk to. I would like to comment on some personal incidences that I’ve experienced as a Java and JavaScript developer:
Incident 1: The Java developer may think that JS is easy. Hiding and showing divs, displaying alert boxes and writing simple functions to accomplish a task is very rudimentary.
Response: In JS, you can create classes similar to Java. You can and should apply object oriented principles in JS. JS can encapsulate data in its objects. There is also inheritance used in JS where methods (Java lingo) or functions (JS lingo) can be inherited by JS subclasses. JS is loosely-typed language. Actually, it really doesn’t have a type which probably irks the Java developer. A variable with the same name can be assigned to a string or an integer. But in defense of JavaScript, an object, although instantiated many times in the browser, can have a function dynamically added and inherited from all non-existing and existing objects. Java cannot do this, but maybe the Java developer will ask why it is needed in the first place. I would respond it’s not a need, but a bonus especially if one wants to add functions on-the-fly. I agree a Java developer probably can easily become a JavaScript developer IF and only IF, he/she actually dedicates time to understand and code in JavaScript and use many of the rich libraries available to him/her (YUI, JQuery, Prototype, SproutCore). I’ve interviewed Java developers whom tell me that they have several years of experience working with JavaScript code. But when I asked the developer “basic” JS questions, the response was convoluted and almost a complete retraction to the “several years of experience” earlier response. If the Java developer really has dived deep in the JS realm, then the Java developer should at least know what event listeners are, how to create JS classes, cross-domain AJAX calls vs. native AJAX calls, JS libraries, prototype usage, typeof() function, closures, how browsers render JS and what are some performance implications, JSON.
Incident 2: The JS developer feels that the Java developer thinks he/she knows JS, but really doesn’t know JS
Response 2: I’ve worked on many idiosyncratic browser-compatibility issues related to JS. It is an art on it’s own that not just any Java developer can say he can understand and know JS. All developers can read or make out different syntax of a language. JS and Java have loops, functions/methods, variables, conditional statements, switches, etc. However, having experience in working on a particular language sets that developer apart from any other language developer. I would think that if a person whom worked on JS for 5 years would know more about JS than a Java developer whom has worked in Java for 5 years and some JS during that time.
I recall an experience I had working as a Java developer and writing some JS code: I like the fact that Java constants are in upper-case format. It tells the reader that the variable is a constant. When I applied this same coding convention to JS, a JS developer informed me, “That’s fine in Java, but it’s not JavaScript”. It was pretty much a snide comment from someone whom assumed I did not know JS or maybe he just had some disagreement about JS vs Java coding conventions.
That comment made me think more about the dichotomy of Java and JS developers. Over the years, I’ve sensed the exclusivity of Java and JS developers. Maybe it’s a way to feel empowered to protect “their” language. I guess this empowerment usually applies to any group with some commonality: race, religion, language, hobby, etc. Being the hybrid developer, I feel placed in-between two worlds. I can see how a Java developer does not want to work in JS; on the other hand, I can see how the JS developer does not want to work in Java. But knowing both languages fairly well, I think that we can always give and take from each language and apply the same coding conventions and design patterns that are agnostic to any particular language. But also, it is important that a developer dedicates an adequate amount of time and experience in a language before qualifying that that developer actually knows the language well.
So I was reading my old professor’s Java blog (Cay Horstmann) from June of this year: http://weblogs.java.net/blog/2009/06/15/my-department-slashdotted BTW, great blog to bookmark.
There is one particular point in the blog that hits a sore spot with me. Consider the following code:
boolean foundEmpty = false;
if(foundEmpty == false)
{...}
if(foundEmpty == true)
{...}
I work with many developers and seeing code such as (foundEmpty == false) is an indicator that the developer, to me, lacks an understanding of the boolean type. Also, the programming level is very entry-level. I’m sure that when I started programming, I wrote code that explicitly checks the value of a boolean. But over time and experience, I see it not used at all except by developers who don’t understand the concept of booleans. Granted, it is very readable, but also adding unnecessary code.
Shouldn’t we move toward writing code that is very concise and implicit? I’ve also seen code written in such a way:
Boolean foundEmpty = Boolean.FALSE;
if ( (foundEmpty).equals(false) )
{ ...}
if ( (foundEmpty).equals(true) )
{ ... }
What happened to using the “else” clause? One can argue that it’s very readable, but maybe too readable to a point that it bothers me so much that I have to re-write it:
if(foundEmpty)
{...}
else
{...}
Why make my life or any programmer’s life reading this code harder than it needs to be? Simple logic and understanding in how to use if..else and booleans is sufficient for me.
Of course, one can argue…
(foundEmpty) ? {...} : {...};
Well, now it becomes more cryptic, less code, and yet again, I may have a hard time reading. I rather pick the latter two, than see the former.
At least the latter two tells me the developer has a basic understanding on how to use if…else and booleans.
In this point of the argument, I acknowledge that it’s more of a stylistic debate rather than a knowledge debate.
So over the weekend, our Tomcat servers were restarted without no new code deployment. For some reason exceptions were thrown in the logs indicating that the same JSP error from the previous release still existed.
The problem is that we addressed and fixed the issue on the previous release. Furthermore, the servers were in stable condition for one week. The application is visited hundreds and thousands of times a day so the new, fixed JSP should be cached properly.
So what is the root cause?
Theory 1:
I thought that maybe when the WAR files were redeployed during the release, it was overwriting the existing WAR files. Maybe the WAR files was corrupted during this overwrite process.
Investigation: I checked the production servers and all the date stamps and file sizes on the WAR files are identical. Also, I confirmed from the release and deployment team that the WAR files and exploded WAR directories were removed before installing the new WAR files.
Theory 2:
If no new code was deployed and we are still using the existing WAR files from the last release, then there may be some weird caching issue.
So I googled it and found out that the “work” directory in the Tomcat instances need to be deleted to remove the JSP and Java caches. Why this is not automated in Tomcat, I do not know.
So here are the references that I found:
1. Old and a little relevant: http://www.coderanch.com/t/85276/Tomcat/Tomcat-weirdness-incomplete-WAR-explosion
2. “Tomcat cache – stop tomcat, delete “work” folder from tomcat install path, restart tomcat. (since this requires stopping the tomcat service, you may need an administrator’s help for this.)”
http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14292602
3. http://forums.sun.com/thread.jspa?threadID=652758
4. Even Eclipse has a build in feature to clean tomcat’s work directory: http://www.eclipse.org/webtools/releases/2.0/newandnoteworthy/server.php
5. “Have you stopped and restarted Tomcat?
Also you may need to clear the Tomcat Cache, this is located in the Tomcat installation directory in the “work” folder. Let me know if this resolves your problem”
Unfortunately, the “work” directory was not cleaned during our release process.
So for now, this is what I think is the culprit to the infamous Tomcat displaying an older version of a JSP page.
I realized over time that there is a huge difference of knowing a design pattern and applying it. My personal code practice is to never apply a design pattern for the sake of the design pattern.
You have to really understand the current system and predict the future usage of the system in order to use a design pattern appropriately. Otherwise, you may find yourself adding unnecessary lines of codes and possibly degrading the system. With that in mind, I would like to share my personal experience:
So a few months ago, I wanted to implement the singleton pattern. I didn’t have much experience in implementing singletons, but I have reviewed code that applied this pattern. I also conversed with another engineer from my old company about the pros and cons of it. The feedback that I received from him was that singletons often cause memory issues. Sometimes the JVM GC will not clean up the singleton object after a server restart and then you have stale objects persisted providing stale data.
So I thought more about it and to me, I have concluded that the safest means to use singleton objects is to read a properties file and store it in memory per server instance. This saves the application from opening and closing file streams which creates much CPU overhead. Also, I have to consider the size of the file. If it’s 1 GB, then storing the properties file content in memory should be forbidden. In my case, the properties file had three lines. It contained information to switch the environment between test or production or increment the build number. So I created a singleton utility class called EnvironmentUtil.java that provides getters for the environment information. It worked, it’s in production, all is well in bernytech land…
Then yesterday, another developer edited EnvironmentUtil.java to have a method to provide the server ip information. Without much thought, I approved the code. However, I gave more thought about the code changes. If it’s a singleton object, then it will store the data once in memory and share its data to all threads that access that object. The method to retrieve the server ip address is called InetAddress.getLocalHost(). I suppose the data will always be dynamically retrieved, but I thought about the repercussions. If 250 threads (max threads set on server) hits the server and each one is requesting the ip address from the singleton EnvironmentUtil java object, I would think it would crash the JVM some way, some how.
But I thought EnvironmentUtil is named appropriately as this utilty class provides helper methods to information about the environment such as: type of environment, build number, and ip address. Another issue that I thought is that the developer whom added the method didn’t really think about what would happen if one added methods to a singleton object.
To address my concerns, I decided to refactor the code: I created a class called XPropertiesSingletonUtil.java. I liked the fact that it was explicitly hinting other developers that this class is not only a utility class, but it is implementing the singleton pattern. Also, it indicates that the class provides information specifically for the X.properties file.
Then, I refactored EnvironmentUtil.java to be a POJO. I included wrapper methods inside the POJO to reference XPropertiesSingletonUtil.java while keeping the method to retrieve the server ip address.
The end result is that developers now need to instantiate a new object for EnvironmentUtil.java.
The benefits of this refactoring are:
* Less Thread Dependency on One Java Object: Every thread calling methods in EnvironmentUtil.java will have it’s own instantiated object providing server ip information. That object will be garbage collected accordingly by the JVM if it’s not in use.
* Less Maintenance: In the future, other developers can add whatever utility methods needed for the EnvironmentUtil class without thinking too much about memory consumption.
* Still Uphold Proper Use of Singleton Pattern: EnvironmentUtil includes the convenience of retrieving environment property values from X.properties through a singleton class, XPropertiesSingleton. Having the singleton object reduces the overhead of opening and closing the properties file.
* Good Naming Convention: I do not have to worry as much if other developers will modify XPropertiesSingletonUtil.java because the file name explicitly hints the developer that this class is associated with the X.properties file and that it is implementing the singleton pattern. Hopefully, the developer will think carefully about the repercussions in adding extra methods to a singleton class.
Update: Upon further research, using the ResourceBundle class is a quick and simple way to retrieve values from a properties file (inside the source code) as getResourceBundle() caches the file in its native code.
However, when retrieving a value from a properties file that lives externally from the code base, the XPropertiesSingleton object is a viable option.
While trying to re-design, optimize, and develop a new code base, my team and I decided to create a new package name that differs from the old package name. Let’s say the old one is: com.not.orange.foo.xxx The new one would be renamed: com.not.orange.foo2.xxx
Ideally, we would keep each code base independent of each other and take the classes that were designed well in the first foo package and incorporate those classes into the foo2 package. Sounds like a good plan, no?
So in the end of the project, I created this re-usable component class called ProductManager that would eventually make an API call to a data source to retrieve information. The parser class would parse the xml response from the data source and detect any system errors. If a system error was detected, it would throw an exception from the foo2 package.
ProductManager can be re-used by any application via Action classes, from any package. Everything was working well until last night…
I saw an action class from foo package (old package) not catching the ProductNotFound Exception in the appropriate catch clause. It was being caught in the general Exception catch clause. It was very unusual behavior until I realized…
The catch clauses in the action class were expecting to catch the ProductNotFoundException from package foo while the ProductManager class was throwing a ProductNotFoundException from package foo2. So this illustrates that even though you have the same code and the same class name, but different package names, those objects are inherently different.
The easy solution would have been to change the package name in the action class to import com.not.orange.foo2.xxxExceptions. However, since the class is from foo, it may call other foo APIs that may throw Exceptions from the foo package. In this case, you will have the reverse issue where foo2 Exceptions are caught correctly, but foo Exceptions will be caught in the general Exception clause.
So what is the hacky, but sufficient solution? Keep the original foo Exception catch clauses and add the new catch clauses but make explicit reference to the foo2 Exceptions:
...
catch(ProductNotFoundException e)
{…}
catch(com.not.orange.foo2.ProductNotFoundException)
{ …}
It does not look elegant especially with the extra lines of code, but it works functionally. I need the extra time to think about a better design approach.
The take away is that even though I thought having independent packages as a good means to start the code from scratch, you stray away from re-usable code; maintenance nightmare when keeping two sets of java classes with the same name and synchronized; more integration issues when java classes are from different packages while keeping the same functionalities.
If you want to re-design, then either work with the code that you have or use a new code base and deprecate the old code base completely. This may save time in the long run.
So I spent two hours debugging this annoying bug.
<h3>Validation error messages from TagLibraryValidator for c in /pages/frame/ko_KR/topnav.jsp</h3><p>null: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x1a) was found in the CDATA section.</p>
This was thrown in the Java stack trace for one of the pages I was working on. I mean it could have been anything.
At first, I thought it was the taglib reference to the JSTL “c” (core) library. If I removed the tag, the page rendered fine.
<%@ taglib uri=”http://java.sun.com/jstl/core” prefix=”c” %>
Of course, if you remove it, then you can’t use any JSTL tag on the page which defeats the purpose of having it there in the first place.
So I read up on some forums. Some people indicated that I should upgrade Tomcat, turn off tld validation or make some changes in web.xml to reference some newer version.
* http://threebit.net/mail-archive/tomcat-users/msg12692.html
* https://issues.apache.org/bugzilla/show_bug.cgi?id=40797
I found it odd though because other pages were working and I didn’t think any of those options are correct. However, the latter forum also suggested to search for the invalid XML character on the JSP page that is causing the whole page to fail.
So I started the tedious process of elimination to find exactly what section of the JSP page is having some invalid XML character. 0x1a is some form of box as I translated it using a unicode tool. But there were no visible boxes on the page. Finally, I isolated the issue in the code:
<span> </span>
In the eclipse editor, I couldn’t see anything except for blank spaces. But when I pasted into this blog, I can see the “boxes”. When I changed the view in Eclipse to display spaces as periods, there were no periods in-between the span tags. So I deleted the invisible characters in-between the span tags and re-rendered the page. The issue was resolved.
I still wanted to find out what the issue was. So I copied and pasted the invisible characters and inserted it into: unicode tool
The invisible characters were: 001A 001A
This is exactly what the exception was telling me: An invalid XML character (Unicode: 0x1a) was found in the CDATA section.
The question is, how do I scan or parse files for future errors like this?
Battle won, but war is on-going.
Bernard's Technocratic Blog 