CLASSPATH vs. #include

[Alvaro Mendez]

I think you've been misinformed. Java does not make all classes visible in the "global namespace", and you still need to "import" the ones you want to use (with the exception of those in the java.lang package). So as long as each .java file imports only the classes and/or packages it needs, its compile time doesn't vary. Regards, Alvaro

[Farhan Noor Qureshi]

After working with both C++ and Java I can say that the concept of CLASSPATH sucks. The most common problem is that your class/package is not in CLASSPATH. And it can crash on runtime. In C++ with includes and linking this is not a problem. (DLL's are another issue) And then, two problems, 1. CLASSPATH becomes unmanageable as your jars, zips and other classes grow in number and also when your directory/folder names are repeated. As an example take two jars, jar1.jar and jar2.jar and they are in folder /usr/apps/stuff/jars, so now your classpath becomes /usr/apps/stuff/jars/jar1.jar:/usr/apps/stuff/jars/jar2.jar As you can see CLASSPATH is growing exponentially. 2. It takes a lot of time for the class loader to "find" your class in the jungle of jars and zips in your classpath. BTW: When I am talking about CLASSPATH, its either the environment variable or the value supplied to java through -classpath param. X| :) ;) ;P :-D :cool: Farhan Noor Qureshi

[Jason Gerard]

You don't have to import in Java at all. If I wanted to use members of the java.util package such as the Date class, I could do so in two ways.

import java.util.*;
Date date = new Date();

or

java.util.Date date = new java.util.Date();

Both ways are acceptable. Nothing that is imported in Java gets compilied into your source as a #include would in C++. Importing just saves you keystrokes. Packages are just a way to organize your classes logically. You could have a package span multiple jars (Java Archives). It doesn't affect your compile time as it does in C++. However, if you are using a class or package, it's path must specified in your CLASSPATH. Much like you C++ complier must know where to look for you header files. Jason Gerard, Master of Kung Foo

[CodeGuy]

Hi Alvaro, I think I wasn't clear. I didn't mean the java.* classes/packages, but rather the ones that a developer would write for his own project(s). Basically, every class inside the CLASSPATH is visible to every other class. I can see where this would be fine for small projects, but when scaling up to large projects, I would think the compile time would be a nightmare. This is why Stroustrup recommended the judicious use of #include in large C++ projects; he said that he saw the wise use of #include reduce compile times by a factor of 10. I was just wondering how Java developers handled the same issue when scaling up to hundreds of classes. If they use packages, then they must run into the same issues as C++ programmers with #includes, right? I would think that it would negate the advantages of using a CLASSPATH. Best regards, CodeGuy The WTL newsgroup: 880 members and growing ... http://groups.yahoo.com/group/wtl

[CodeGuy]

Thanks Farhan. This is what I suspected for large Java projects. CodeGuy The WTL newsgroup: 880 members and growing ... http://groups.yahoo.com/group/wtl

[Farhan Noor Qureshi]

Hello CodeGuy, AFAIK, majority of the Java programmers *DO NOT* care about speed as if it were a thing from past. I have seen many java programs taking up 80+ MB for Memeory while running and makes 933 Mhz P3, 256 MB RAM PC into a crawler. So, why would they care about compilation speed??? lol. :) ;) ;P :-D :cool: Farhan Noor Qureshi

[CodeGuy]

I'm sorry, man, but that doesn't make much sense ... the compiler has to be searching for your classes in your CLASSPATH as it compiles your project. The more directories/classes it has to search through, the longer it's going to take to compile. CodeGuy

[Alvaro Mendez]

Hi Codeguy, Typically when you use a tool, like Kawa or JBuilder to build the .java files in your project, you specify in the project settings (or something equivalent) what directories, and/or packages (in the form of .jar or .zip files) you want in your CLASSPATH. I guess what I'm saying is: you, the developer, control the CLASSPATH, and you should only make it what you need. So it's not something that's out of your control and just keeps growing and growing. I suppose it could technically grow if, for example, a JAR file specified in it also gets bigger when you manually update it. But it's not the usual case. In any case, I'm currently working on a project with around 200 .java files. When I do a "Rebuild All" inside Kawa, it takes around 30 seconds to complete on my P800/512RAM. Of course, the CPU gets maxed out, but that's another story - Java compilers are CPU hogs. But 30 seconds (for ALL the files, which I don't usually do) is pretty damn good for that many files. I wonder how long 200 C++ files would take on an equivalent machine... Regards, Alvaro

[CodeGuy]

Good points. What Java version are you using, 1.3? That is surprisingly fast. Best regards, CodeGuy CodeGuy The WTL newsgroup: 880 members and growing ... http://groups.yahoo.com/group/wtl

[Alvaro Mendez]

Yep, JDK 1.3. But I've always seen Java files compile quickly. I guess the process of converting them to byte codes is not very time consuming. I'm sure my CPU would disagree. Regards, Alvaro