Coffeehouse Thread

11 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

why does java have a classpath? ( or why doesn't .NET have one ? )

Back to Forum: Coffeehouse
  • User profile image
    SteveRichter

    So I am seeing that in Java the CLASSPATH is the path of the directory that contains the Java classes your app is running. How is it that Java has a classpath and .net does not?  In .NET all the assemblies are copied to the bin directory of the .exe file. There is the GAC, but how commonly is the GAC used for user written applications? 

    So why doesn't Java do the same thing?  Even the PATH environment variable that is so important in Java and Unix, not so in Windows. Is the difference because Windows apps copy all the binaries into the bin directory?

    I kind of like the CLASSPATH and PATH approach if it enables me to keep from having multiple copies of assemblies across the system. But maybe that convenience breaks down as each app is built against a different version of the same named assembly.

    Interested to know the official rational for Java having a classpath but not .NET.

     

  • User profile image
    kettch

    @SteveRichter: Having struggled with various applications killing each other off in DLL hell, I'd rather each application have it's own binaries. XCopy deployment rocks.

    http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx

    MSDN said:

    You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required.

  • User profile image
    Jim Young

    , SteveRichter wrote

    I kind of like the CLASSPATH and PATH approach if it enables me to keep from having multiple copies of assemblies across the system. But maybe that convenience breaks down as each app is built against a different version of the same named assembly.

    But isn't that the purpose of the GAC? CLASSPATH is not necessarily global to the system. When executing a Java application you can specify CLASSPATH to point to a particular location. Also by using strong assembly naming in .Net you can have multiple copies of the same assembly (by file name) on a system and the .Net runtime will bind to the correct one by version.

  • User profile image
    figuerres

    windows does use path also, like unix first you see if the binary is in the current folder, then you check the default system bin folder then you search the path to see if any of them has what you need.

    local folder is the default place to load from if you are using the file system.

    java came first, then .net so java already had it's stuff going and they did not change what they did.

    classic windows apps in the past used to toss stuff into the system32 folder and register it.

    that was part of the old "dll hell" problem.

    .net said stop the madness and keep your bits local to your app so that installing your app will not break some other app.

    folks generally leave the gac as they are not sure about changes and who might want to share bits.

    and with the freaky huge disks and ram it keeps things simple that way.

     

  • User profile image
    wkempf

    The CLASSPATH in Java is a horribly broken concept, IMHO. For instance, did you know there's more than one CLASSPATH? There's the normal CLASSPATH and a "boot CLASSPATH". You hardly ever have to care about that, but when you do, confusion ensues. Not to mention all of the other nightmares involved that you can easily find by Googling on Bing. In fact, it's such a pain that tools like JWhich were created to help you figure out what's going on.

    Sharing binaries seemed like a good idea in the 90s, but I think we're mostly in agreement that XCopy is the way to go today.

  • User profile image
    Sven Groot

    Java's reliance on the environment (including CLASSPATH) is pretty annoying.

    I dealt with Java a lot through my work with Hadoop, and basically everything in the Hadoop ecosystem (including Hadoop itself) must be launched through bash scripts (that are often 100s of lines) just to make sure the environment (like JAVA_HOME and CLASSPATH) is set up correctly.

  • User profile image
    ScanIAm

    , Sven Groot wrote

    Java's reliance on the environment (including CLASSPATH) is pretty annoying.

    I dealt with Java a lot through my work with Hadoop, and basically everything in the Hadoop ecosystem (including Hadoop itself) must be launched through bash scripts (that are often 100s of lines) just to make sure the environment (like JAVA_HOME and CLASSPATH) is set up correctly.

    ++++++

    Oh, and oracle suffers from the same stupidity.

  • User profile image
    Bass

    More modern Java systems use OSGi to discover application dependencies these days. Although using ghetto bash scripts is cool too.

  • User profile image
    felix9

    I think .NET assemblies looks like normal executables, like .exe/.dll so we can use normal PATH variable and let the OS find them. while Java uses .class/.jar and the OS knows nothing about these.

    and, since Mono works like Java, it does have a MONO_PATH variable.

  • User profile image
    Ion Todirel

    @felix9:no

  • User profile image
    Ray7

    , Bass wrote

    More modern Java systems use OSGi to discover application dependencies these days. Although using ghetto bash scripts is cool too.

    Yup, not really a problem now, but in the old days - oi!

    Most Java frameworks and/or IDEs handle all the dependency stuff for you; I can't remember the last time I had to fiddle with CLASSPATH (though you still need JAVA_HOME in a lot of cases).

    I guess the reason the classpath came about is because Sun wanted a system that could be implemented easily on any platform; they went for the skinny approach.

    And in my opinion, the classpath is not nearly as big a problem as their decision to tie the package structure to the operating system directory structure. What were they thinking?

    When I was developing web services on Windows this was a huge problem because the XML binding stuff would generate package structures too deep for Windows to cope with.

     

     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.