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?
Filed under: Uncategorized
This is coooool:
http://craftymind.com/factory/html5video/CanvasVideo.html
Filed under: Internet Explorer, JavaScript, Uncategorized, Web Development
I had this issue only in IE 8. It’s odd because I tested in the url if the form object exists. In the url address bar:
I typed:
javascript: alert(document.<form name>) —> returned object in firefox, safari and IE 7/8
javascript: alert(document.<form name>.submit) —> returned function definition in firefox and safari but in IE 7/8, “Object doesn’t support this property or method…”
This is yet… another IE idiosyncratic bug.
I read in other forums that indicate if you label an input button or submit using name=”submit”, this will override the submit method in the DOM tree for the form.
This makes sense. If the form is called foobar and has a submit button with the name “submit”:
<form name=”foobar” action=”…”>
<input type=”submit” name=”submit”…>
the native form submit function is overrided. Now, document.foobar.submit will be pointing to the DOM element named “submit”. Basically, the pointer to submit() is reassigned to the DOM element named “submit”.
However, this wasn’t the issue for me. I tried to figure out what exactly was the object I was retrieving, but with failure.
I used typeof(document.foobar) and it returned object.
I typed alert(document.foobar.toString) and it returned object. I believe the same function was called here.
I tried to look for some other object attribute to let me know what it is, but nothing worked.
In the end, I decided to use prototype’s DOM access syntax: $(foobar).submit() This worked.
I’m thinking now it might have to do with the prototype library overriding IE’s document object tree. But this is unconfirmed. If you know, please let me know.
Side Note: Now one can argue why I am not using id or getElementById. It’s really a sad story… I’m bounded by an old struts framework using a struts form tag that does not allow me to assign an id as an attribute in the tag!!!
I know, I know… I pity myself as well.
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.
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.
Bernard's Technocratic Blog 