Hey All, I recently downloaded JDK 1.3 but to my surprise there was no javax.servlet package (even the http one).So my question is if I have to write and compile a servlet how do I access the package available in jsdk2.0 (which I have installed).I'd like to add that there is another problem which I am facing .It is :How do I write the import statement required at the beginning of the source file .The problem I face is that it does not recognize a statement such as import jsdk2.0.src.javax.servlet.*; This is because of the version and the dot in between . How do I work this out and have access to the package? Please help me on this front .Thanks
Hey Larry, Thanks for your response.Well I did not know this fact as I did not check the details of late.But what I really ponder is why has such kind of design been created at all?I mean this dot hierarchy of packages ..doesnt this create a kind of problem . That is everytime I require a package I have to check with its latest wrapper.I mean what if I have to have access to a class (or package details)in another root directory then it is not possible?? Or may be I am confused about this thing.I wonder if anyone has to say about this.
Hey Sumit, Usually as you go along, depending on the project you're working on, you will add different classpaths to the environment you're working in (IDE, commandline, or whatever). This hierarchy system just makes things easier to locate & find, as well as providing a good system of representing inheritance & categorization/specialization. You can reference as many classpaths as you want usually, just make sure that you don't have conflicting versions of the same class being imported. Hope this helps you a little, Larry
Hey Larry, You put that point across beautifully.But isnt the problem of conflicting namespaces a big one!!!.At least I feel so..Id appreciate if you could give your comment on that. Thanks for your kind response. Regards
The conflicting names really shouldn't be a problem as long as you're creating logically separated entities (different classes). This is where modelling comes in to play, just as it does in any well-designed system. Java is a very well-designed system in that it is completely designed for code re-use, which means there should never be a need for conflicting names because everything should be logically separated, or else extending something previously written (which would also make it separate). This lends itself real easily to long and ambiguous classnames, which I know a few of for example because at work everyone simply adds a new word to the class they build from, sometimes classes are 5-10 words in length, getting in between 15 and 30 characters. I agree with you that sometimes the conflicting namespace would be hard to avoid, and there really should be some standard set as to when you need to define a separate package for one type of class, as opposed to separate classes in a package where a lot of different types of Objects exist. For example, lets say that there's 10 different types of Apples in the FruitStand package. There could be GalaApples, MacintoshApples, GrannySmithApples, RedDeliciousApples, etc., mixing around with your other classes like your Oranges, Bananas and whatnot. At what point do you try to avoid the confusion and make a separate subpackage called FruitStand.Apples.*? I don't know what Sun has to say on the above example, but I'm sure the people modeling might have different ways they prefer to do it. All I know, is that as long as you know the way that your packages are defined, and keep things separated by function, the naming conflicts can be kept miniscule. I don't know if what I said at all makes sense to anyone else, or even answered the question for that matter, but I think it could be the grounds for a good discussion. In Java, Larry
On another note, Java also leaves room for interfaces, which might be the intelligent way to go about using multiple similar objects. But that is different from the namespace concern, yet it relates. Gettin me confused! Larry