Weiqi Gao: The Number One Ill of Java

Discussions

News: Weiqi Gao: The Number One Ill of Java

  1. Weiqi Gao: The Number One Ill of Java (35 messages)

    Weiqi Gao has posted "The Number One Ill of Java ..." saying that Java's requirement for the "stupid 'directory structure reflecting the package hierarchy' (mis)feature." No mention of the bloated JRE, or the license issues, or the confusing classloader issues, or ...
    [The number one ill of java...] ... is its stupid "directory structure reflecting the package hierarchy" (mis)feature. I was "helping" 20-year programming veterans to "understand" this (mis)feature in 1998. I'm still "helping" people to understand it now. "I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?" There is no good answer to this question. Sure, you can get use to it. You can even be proud that you are among the 5% programmers who persevered in understanding it. But it doesn't make it right! You can label the on switch "off" and the off switch "on". People will get used to it. But that doesn't make it right. It causes unnecessary problems. And its another barrier to true understanding. That, and zero-based array indexing, have got to go.
    What do you think? Any votes for the date-handling? The security manager? Serialization? XML handling? (Oh yeah - last thought. Anyone reading who's in the 95% who Weiqi says don't understand the package structure in Java?)

    Threaded Messages (35)

  2. Organization is a good thing[ Go to top ]

    I prefer having packages that reflect the directory structure. In my favorite IDE, I can easily view the folders and visualize the project structure. I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.
  3. Java's package structure: The file per class, and package/file structure is better than hunting for the files that implement a package. If there's anything wrong, it's the fact that the package nesting itself doesn't really mean anything. Packages should represent versioned component boundaries, and you should be able to have multiple versions of a package co-existing peacefully. If you run a strongly connected components algorithm on static references, the correspondence between jar files and strongly connected components should be good enough to automate high level documentation/component refactoring. THAT would be an improvement. But the way that Java does packaging is underdeveloped, but not anywhere near what is worst about Java. Zero based arrays: Array indices starting at 1 is a bad choice because it forces you to deal with silly issues that are only the result of not basing on zero. Ex: - arrays are often implemented with pointer arithmetic as arrayBase + sizeof(type)*index so, if you use 1 based arrays, the underlying assembler has to subtract 1 EVERY TIME an array is indexed (with exceptions for indices being reused in various ways). - a lot of algorithms need to use the mod function. the code is much more straightforward if you dont have to play a lot of games with the index to make it 1 based. myArray[ i % myArray.length ] vs myArray[ ((i-1) % (myArray.length)) + 1 ] - Like the above example, many algorithms depend on the numerical properties of the index, like using bit shifts in a heapsort for instance. If you have 1 based arrays, then you waste time translating indices. I would say that almost all array based algorithms are simplified by using a zero based index. This seems to be especially true in the cases where most of the work is actually 1..N based, but having extra slots at 0 and N+1 cause corner cases to disappear. - Most algorithm texts are zero based, so you would have to carefully translate to a 1 based system when you code it. Counting from zero is not a wierd concept at all. If you are programming computers for a living, then you need to think mathematically anyhow.
  4. Don't forget ever array access (unless done with a value resolved at compile time) would result in an additional ALU operation to subtract 1 from the specified index to compute the correct memory address.
  5. You sound quite offset ...[ Go to top ]

    .. But! your comments are very reasonable. The original author's sentiments are actually reasonable as well. However, they are precisely that, sentiment, and do not stand the scrutiny of expert consideration. Same problems haunt the server side Java (the technology I mean ) but regrettably, on the server side, the sentimentalists have had their way ... "really, why do we need all those "stupid" deployment descriptors all over the place? Can't we just put it in the javadocs??" .. /R
  6. So... .NET got it right then?[ Go to top ]

    I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.
    +1 I do Java 99% of the time, and have dabbled in .NET. The first time I realised that com.foo.Bar didn't need to live in the com/foo directory in .NET, I sighed a mighty "WTF....!". I'd still be open to understanding the benefits of being able "package" stuff as .NET allows if anyone can explain it. I'm guessing the author is a .NET fanboy or has recently had a lobotomy if Java packaging is too hard to understand.
  7. Re: So... .NET got it right then?[ Go to top ]

    I've also worked in the .NET world where packages (namespaces) do not need to reflect the project structure and, in my opinion, it tends to lead to a bit of disorganized chaos because the directory hierarchy is not enforced.

    +1

    I do Java 99% of the time, and have dabbled in .NET. The first time I realised that com.foo.Bar didn't need to live in the com/foo directory in .NET, I sighed a mighty "WTF....!". I'd still be open to understanding the benefits of being able "package" stuff as .NET allows if anyone can explain it.

    I'm guessing the author is a .NET fanboy or has recently had a lobotomy if Java packaging is too hard to understand.
    Guess that is why they choose to call them Namespaces. :) The good news is that one can match the folder structure to the Namespace. It just doesn't happen by default. :( But the really bad part about .Net Namespaces is that the Namespace is "wild-carded". And that kicks my behind all the time.
  8. Imagine a scenario. directory com.xxxx.dao.hib.impl contains XYZ.java and I Can find that out by looking at the code. But our talented friends says that he wants to by-heart the location. NOt only that, he wanted to by-heart the locations of remaining 12,000 files in the app too!! Go ahead, be my guest. yOu can do that even with package names. wHy not by-heart a bat script too, that will change current directory and run the compiles. BUt give me my option of packages.
  9. Imagine a scenario.
    directory com.xxxx.dao.hib.impl contains XYZ.java

    and I Can find that out by looking at the code.

    But our talented friends says that he wants to by-heart the location.
    You know I have a friend/working collegue who insists on using UEdit to write java code, or notepad if UEdit isn't available. So I guess people like him would probably concur on the initial post :o) a++ Cédric
  10. Re: Organization is a good thing[ Go to top ]

    I just have to agree with the rest here. After 15+ years of c++ programming before starting java coding, i have nothing but good things to say about the directory structure / package structure connection. I wish C++ namespaces forced the same restriction, but there are good reason why (yep, c++ is one weirdo)
  11. You can even be proud that you are among the 5% programmers who persevered in understanding it.
    Yeah, right. That's probably because it's really, really difficult to understand that the source file for foo.bar.Baz is located in the source tree under foo/bar/Baz.java. Great to have a genius like Weiqi Gao around!
    That, and zero-based array indexing, have got to go.
    Eh? So what's your suggestion? 5-based? 8-based? Seriously, that was the worst article in a very long time. Hoogla Boogla PS: I know he probably wants 1-based arrays, no need to point out you've missed something.
  12. Number One ill?[ Go to top ]

    I can understand the 0 based array index, it's not difficult as you can easily get used to it but is counter intuitive, thats for sure. But package structure... Number one ill???? come on!! no one who can honestly say they are veterans in programming would take more than five minutes to figure it out.
  13. Bah[ Go to top ]

    One of *the* things I liked about Java is how it forced you to place one class per file and one package per directory. You won't believe the kind of messed up hierarchies C/C++ people come up with! Java forces you to be clean, if you don't like it too bad. His complaint about zero-based array indexes also makes me laugh. It's subjective, different people prevent different approaches. If you decide to modify zero-based array indexes be sure to modify anything else that is zero-based in the language. As a sidenote, I believe it was Joshua Bloch that recently said that he regrets that Java did not incorporate unsigned integral types into Java from the onset. One reason being that array indexes are naturally unsigned values and Java is currently running out of index space for arrays (32-bit signed integer is not enough for some applications). It would be interesting to see how things unfold going forward but I would like to see Sun lean more towards language/code cleanup in the future even if it means breaking backwards compatibility.
  14. Re: Bah[ Go to top ]

    Files and directories aren't actually relevant to programming, they're just what our crummy languages/environments make us deal with. Most of the time when I'm using IDEA I don't think about files, and hardly ever about directories - I just ask for the source for a certain class and start editing it. That could work the same way even if I could have more than one class per file.
  15. How did this narrow minded drivel make it to the TSS homepage?
  16. 50% Agree[ Go to top ]

    If I understood you correctly; you're complaining about javac needing the top directory of your project source files; that I agree with; SUN needs to fix that. But the zero array indexing is the norm now in all C like languages; we kinda got use to it; and I don't think changing it now is possible with all the apps out there in Java.
  17. What ever[ Go to top ]

    of all the things to bitch about in Java, the directory structure "shouldn't" be number 1. Try using Visual Studio .NET and the flat structure. Having done that, I find it a nightmare to manage if you have say over 10K files. I suppose those who don't like well structured code prefer to write everything in 1 huge file and grep. by the way, that's a joke. though I have seen bad programmers cram everything into one huge file with 50K lines. peter
  18. So how does one get their random thoughts from the blog posted as a real news article of interest to the community? I'm going to go post on how the number one problem with Java is how they won't let us start variable names with numbers. Seriously, why not? I know you guys are dying to read it! On a completely unrelated note, the login page has some bad code. Instead of seeing the actual title in between the title tags, people see this:
  19. The only valid reason I can think of for complaining about the class naming and location requirements of Java is that it causes problems when you need to move or rename things in a lot of source control packages. Of course, lucky people using svn don't have that concern.
  20. I'd vote for Date Handling[ Go to top ]

    The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill. Classloader issues are a close Number Two IMHO, i'd love to get a warning when the same class is found multiple times on the classpath...
  21. Re: I'd vote for Date Handling[ Go to top ]

    The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill.
    +1. Yep, immutable legal dates (yyyy/mm/dd or whatever). Ones that stay just as the user entered them and don't keep changing as they are persisted, transferred between JVMs, or shown to a user in a different time zone. 1 based array indexes? I remember them. I used to have to deal with them in GWBasic. All that having to add or subtract 1 every time you used a variable as an index.
  22. Re: Blocked classes[ Go to top ]

    The Date/Calendar/milliseconds conversions are a major PITA, fully qualifying for Number One Ill.

    Classloader issues are a close Number Two IMHO, i'd love to get a warning when the same class is found multiple times on the classpath...
    You could use Classpath Helper to show you this. It shows you blocked classes with the same bytes as well as different bytes. It's available as Eclipse plug-ins. http://classpathhelper.sourceforge.net/
  23. Misstated complaint[ Go to top ]

    While the complaint may be manifested about the directory structure of packages, the real issue is ClassLoaders. Because that's what the directory structure is enforced by. I can create a file: package com.serverside.example; public class Test { public Test() { } } I can put that in any directory I want and compile it, and I'll get a Test.class file with the "com.serverside.example.Test" class in it. But the default ClassLoader relies on the directory mechanism for arranging the classes, so if that file is not in the right place, the standard Java ClassLoader "can't find it". You can easily create a ClassLoader that relies soley on the filename, for example. Or whatever your want. The JAR ClassLoader for example doesn't rely on directories at all, it relies on the internal structure of the JAR file (which conveniently creates directories when you explode it, but that's coincidence). Of course, the directory structure is a natural way on modern filesystems to organize hierarchies and namespaces. But just like "http://example.com/this/that/x.html" has nothing to do with directories (but can conveniently be represented that way on a server), com.serverside.example.Test has nothing to do with directories. This is a ClassLoader problem, and I'll be upfront to say it's one of the most complex aspects of the Java Runtime.
  24. What??[ Go to top ]

    ? It is one of the better features of Java. I worked on very large C++ project (> 1 mil LOC) and good luck finding the class without grep or without a modern C++ IDE which allows you jump to definition. Also the restriction of one public class/file is a godsend, but result in many files. Hey, there are always trade off but this one I can live it.
  25. Hot class re-loading?[ Go to top ]

    I'm surprised nobody bitched about slow re-deployment. Could be mostly avoided by adding support for real hot reloading of classes (instead of current 'only method bodies are re-loadable'). /Henri Karapuu
  26. How did this get onto the site?[ Go to top ]

    Lol. How did this get onto TheServerSide? Are we going to see more Springereque slap-fights over daft things like this? But seriously, even if this is a serious point for discusion it should never have been allowed to go up without being properly editted or returned to the author for editting. Onto the actual subject that merits discussion; I can see the sense in 1-baased arrays for newcomers (oldies get used to it), and perhaps the compiler can take care of the -1 rather than the ALU at runtime; I write myArray[1] but the bytcode says myArray[0] (in bytcode obviously). That wouldn't take care of the algorithm problems.
  27. The problem is that array indexing is usually done through variables, which typically live on the stack. There's really not much room for optimization in terms of subtracting, since the value can't be known until runtime. Only compile time resolvable expressions could be optimized, such as myArray[1]. It's a waste of cycles for something that is not really an issue. Programmers in most languages have been dealing with this for a long time. Even VB gives the programmer the option of using 0 indexing to save the cycles.
  28. It's more than 10 years I'm using Java and never heard such a complaint about Java. Around 2001 I joined a Microsft shop to help them migrate from asp based development to jsp/servlet world. One thing I heard almost from all those experienced VB/ASP developers was they love the fact that "directory structure reflecting the package hierarchy" and believe it makes organizing the code easier. By then I had never thought about this aspect of Java!
  29. LOL![ Go to top ]

    Trash. 'Nuff said.
  30. The point about directories having to match file structures being an 'ill' took me by surprise. I think 20-yr programming veterans the author referred to, would have appreciated it right away. But honestly, classpath issues esp. those in application servers need to be simplified and standardized.
  31. I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?
    javac -d If you have been teaching java since -98 and havent figured that out...?
  32. I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?


    javac -d

    If you have been teaching java since -98 and havent figured that out...?
    I beleive he was referring to the fact that you can't easily compile, from the command line, all java files in the current directory if there are references to other source files. For example: com.foo.bingo.Baz refers to com.foo.Toto javac -c Baz.java will fail because Toto isn't in the CP. This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java. To which I don't think the -d option will help much, am I wrong? That being said, it doesn't stop me from sleeping :o) a++ Cédric
  33. I have a directory full of Java sources right here. Why do I have to tell javac or my IDE that the sources are three directories up?


    javac -d

    If you have been teaching java since -98 and havent figured that out...?


    I beleive he was referring to the fact that you can't easily compile, from the command line, all java files in the current directory if there are references to other source files.

    For example: com.foo.bingo.Baz refers to com.foo.Toto

    javac -c Baz.java will fail because Toto isn't in the CP.

    This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.

    To which I don't think the -d option will help much, am I wrong?

    That being said, it doesn't stop me from sleeping :o)

    a++ Cédric
    eh? javac -d -classpath ... Or what?
  34. This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.
    Hum, comparing the C/C++ compilation/linkage process with Java is really straight forward: when javac compiles, it means everything needed was found and the JRE works with same classpath. When your .c file is compiled, you just have a .o ! You still have to link all your object files against libraries to get an executable... and it is not obvious it runs then. So Java is better but not perfect: who never gets a NoClassDefFoundError or a LinkageError ? Yves
  35. This was hard part for me when I jumped from C++ to Java that took me about .5 minutes to understand: the #include statement in C/C++ doesn't have the same effect as the #import statement in java.


    Hum, comparing the C/C++ compilation/linkage process with Java is really straight forward: when javac compiles, it means everything needed was found and the JRE works with same classpath.
    When your .c file is compiled, you just have a .o ! You still have to link all your object files against libraries to get an executable... and it is not obvious it runs then.

    So Java is better but not perfect: who never gets a NoClassDefFoundError or a LinkageError ?

    Yves
    Not to mention how much smoother dynamic classloading is in Java compared to dlopen/ld/dll hell(s) in C et al. Of course this also means that it is sometimes over-used....
  36. Java, as a language, do not force any directory structure. It is the compilation environment that use, by default, some assumption about directory structure to find classes; but even with javac, you are not really forced to build a directory structure that map the package structure; for exemple, you can use the cc style and give a complete and explicit list of Java files to compile as arguments; in this case, javac don't care where the files are. I used this technique a couple of times to avoid what i think most of us agree it is the real pitfall of the package structure: Java packages are namespaces, not modules, and using namespaces to limit visibility is a way to "emulate" real modules. This solution work in simple case, but it doesn't when you want to have submodules; you end up using subdirectories, that by default are nested packages, i.e. just different namespaces; than you need to make give public visibility to the API between submodules, that is surely not what you want, and you are finally screwed. One alternative is to use subdirectories for the submodules, but to not use a different namespace, using the available javac compiling options; you don't have isolation between submodules, but you have isolation between the module and the external world.