apicolet

I am not sure it will work : it is based on the assumption that you can 'find' a node from one tree in another tree based on this node's value alone. This would actually be the case if we were looking for an algorithm which checks that two binary tree are equal or that one is equal to a subtree of the other.However, the problem here is to find whether the two trees are structurally equal, meaning that two nodes should be compared only by checking that they have the same children structure (none, only left, only right, or both) regardless of the value. For me, I cannot think of a quicker solution than Varalu

Well, that would work indeed, but what about : $str eq reverse($str)That is actually the very definition of the plaindrome, and it further saves your fingers, beyond being easier to understand (which I know isn't what we look for in Perl )

Well, I think the answer depend on what are really these 'nodes'. If we consider them as objects holding the information on the next node - which forms the linkedlist - as well as their own data , then Varalu's solution would work. Indeed, if two nodes from the two linked lists are equal, it means they point to the same 'next node' object, which in turn will point to the same 'next node', etc. In this case, if the two linked list have a common node at some point, then the end of the two linked lists will be equal too. This, in turn, means that , if the two linked list have a common node, then this common node will be at the same position from the end in the two linked lists. Removing the extra nodes in the longest list and starting comparing from here thus work, in o(n). For the case where elements of the list do not contain the reference to the 'next node' but only their value (such that you can have 1->2 in one list and 1->3 in the other), then we can think of a o(n) solution. Suppose there is a way to traverse the list in the reverse order, beginning by the end and navigating to the previous (if the data structure does not enable it, then converting it into a data structurewhich enables it can be done in o(n) anyway). In this case, the algo would be : 0. mergingNode initialised to 'no merging node found (yet)' 1. currentNode from both lists = last node from both lists 2. compare both currentNodes 2.1 if they are different, return mergingNode 2.2 if they are equal : 2.2.1 mergingNode = currentNode 2.2.2 currentNodes from both list = previous element from both list (return mergingNode if one of the nodes does not exist - one list is finished) 2.2.3 go back to 2. 3. if we are here, the two lists are totally equal This is an o(n) algorithm for that.

Well, I would say it depends, and it could even be both (easy answer)... In creating a web application which is not only a bunch of static files, you will always have two parts where your code will run : - on the browser (in Javascript typically) - on the server (in J2EE, PHP, CGI, whatever) I am currently on a project using AJAX philosophy on the browser, with ext-js Javascript framework notably. This is to increase user experience : no more page loading, dynamic,independent panels in different parts of the page, immediate data validation, etc. However at some point, these Ajax call do call some URL on the server, for it to actually do something (that is their reason in life). For the server part, I use the Web part of J2EE, namely, a Tomcat server with WebWork as controller, JSP pages for HTML views, and JSON for data exchange with browser. I would say it is quite common to use both J2EE and AJAX, as the requirements are independent : - you will want AJAX if you want a sexy 'Web 2.0' UI, instead of a awful succession of pages which reload entirely each time - you will want J2EE if you have some complex business logic (maybe not if you only need to put and retieve data in a DB without any processing), or some complex integration with other server systems (using JMS, or connection pooling, etc).

I totally agree with Tetraca on this. I would even go beyond : each time I write a program, even the simplest one, I separate functions and objects into distinct, coherent packages. Almost each time, it turned out later that I was right, because at least one the following thing always happens :- somebody will have make it evolve some day (the data you store needs some special post-processing in a certain case)- somebody will want to reuse one interesting component of it some day (writing another app that will access the same data)- someday, you will want to migrate a part of this to another way of doing the same thing (I used to store my data in plain text file, now let's use a DB, let's even use a new complex plugin architecture for data storage, without impacting the rest of the application)It's true that, when you have a program that would take 20 lines in a single file, it is a bit overkill to split it in 5 modules and define a whole object model and interfaces. I don't do it for throw-away scripts that I need to run only once !

I just found out this is actually a challenge from myjavaserver.com ! They typically ask for the solution not to be disclosed...

Hi, I used GWT one year ago. At that time, I knew very few about client-side programming in Javascript, CSS, HTML, etc, but was quite experienced in Java. This is mainly what triggered my decision to go for it (beyond mere curiosity). I thought the concept very interesting. The main good points I see are : - you do not need to know client-side programming at all to have quickly a working program - the client-server interaction is made really easy : you just call Java methods in Java ! Then the compiler will compile these client-side method calls into Javascript that will marshall data, send it over the wire with an XHR, unmarshall it into Java, call the right object at the right place, and marshall it back, all with handling exceptions... Now that I program in AJAX, I can tell you this is something I regret... - the generated Javascript is highly efficient, and handles browser compatibility issues. Just to know, Google Docs & Spreadsheet application, using the same compiler, has its whole client-side in 6kB of HTML, 6kB of CSS and 100 kB of Javascript (plus +100kB of images) ! What's more, it is terribly obfuscated, which is good if you are not developing open-source apps Now, the main drawbacks I saw : - quite tedious to debug, because of obfuscation. You can only debug in GWT's browser emulator, and of course there are some bugs which occur in Firefox but not in this emulator, and then you are a bit stuck... - hard to do things not already part of the GWT framework. If you want a tree view to have some custom behaviour, well you can't (actually you can, but it is a huge amount of work compared with doing that in a standard Javascript library) - it is compatible with nothing else. If you started your app using GWT, you are bound to it till you rewrite completely your application.

Hi, This is due to Sun's naming convention changing as they progressively bring Java into a wider and stabler platform. To follow the history : - The first releases of Java in the early 90's was labeled 1.0 , then 1.1. We talked then about a JRE 1.1 and JDK 1.1 , for Java Runtime Environment and Java Development Kit. - When it came to Java 1.2 , changes were so radical that the brand name for Java platform 1.2 was 'Java 2'. The JRE and JDK then became J2RE 1.2 and J2SDK 1.2 ! (for "Java 2 Software Development Kit, version 1.2"). This was the beginning of a little confusion... - This continued like that until version 1.4.x. - When introducing platform 1.5.0, Sun thought it a little weird to always stick to a '1.x' version number, even for major changes, like in 1.2. This made people think that version 1.5.0 was merely an update to version 1.0, where I beleive not a single line of code has survived... they then decided to drop the initial '1', and to call the new version 5.0 instead of 1.5.0. However, 1.5.0 would also remain for technical compatibility reasons. Version "5.0" is the product version, while "1.5.0" is the developer version, and the whole still being labeled as 'Java 2' !! We then had a 'J2SE 5.0' for the name of the platform, the runtime and development kit being now reverted to JRE 5.0 and JDK 5.0 (instead of J2SDK and J2RE) due to developer popularity. - For platform 1.6, Sun then dropped the last digit, to call it 'Java 6' , and dropped the 'Java 2' concept. The platform is now called 'Java SE 6', with a 'JDK 6' and a 'JRE 6'. Note that the 'developer version' is still 1.6.0, this is what you would get from doing java -version, and the name of the installation directory... But, to answer precisely to your question : - JDK 6 is the Java Development Kit for Java Platform 6 (developer version 1.6.0) - J2SDK is a Java Development Kit for an unspecified version, there should be an additional version right after. However, if it is really called 'J2SDK', it should technicaly mean that it is comprised between 1.2.x and 1.4.x, but as everybody is confused, this is not a guarantee... Hope this helps Antoine