i have to admit, i'm turning out to not be a big fan of Java.
Let me clarify things a bit. i'm ok with Java the language. Yes, it's strongly bound and early binding which makes it less flexible than the stuff i'm used to dealing with, but since it's mostly object based, it's not like it's completely evil.
No, what starting to really drive me nuts is the various, weird, house of cards relationships that need to be established before anything works right. Take Tomcat for instance. It's the java interpretor that sits on top of Apache and allows you to write page templates with java in them. Now, one would think that it being layered on Apache, it would work like mod-perl, PHP, mod-python, or any of the other template languages layered on top of apache.
No, it doesn't.
It requires multiple XML based configuration files, associated error files, helper frameworks and applications, more xml settings files, and then various callback functions in java before things can even get started. And may Sun have mercy on your soul if you don't get things exactly right. It kinda makes you wonder why the hell they even bothered bringing Apache into the picture, but that's when you realize that Java is the Katamari Damacy of languages, where you keep rolling things in making larger and larger balls of code until eventually they become small planets you can live on. (Seriously, i thought Perl was bad about it, but it's got NOTHING on Java.)
This week, i'll enter my third week of utter frustration in order to get a configuration set up so i can test my 14 line modification to a class file. It took me less time to cobble together a build environment from close to 100K lines of C & C++ using gdb and tail -f, most of which was never checked into a code management system.
i just want to get an environment up that works. Because once that's in place, i am SO going to figure out some packaging structure so that i'm the last guy to ever have to go through this crap.
Interesting the number of people who leave the purple corp and bemoan th e lack of anything like yinst. You would have thought that this was all figured out.
Devel 2.0 was good. Sigh.
You don't need Apache to run Tomcat, you can run it (quite easily) as a standalone server. As for all the XML files, yeah…well, the Servlet/Tomcat camp was born around the time of XML's ascension so it's not surprising that they used that hammer to bang in every nail, screw, pencil and whatever else they could get their hands on.
It's not Java's fault, though. You could easily have written such a convoluted system in Perl, C++, Python or Ruby. The people who wrote Tomcat are tools, that's all. Java itself is an amazing virtual machine and a decent language. Sure, mookie, it takes you 20 lines of code to open read and close a file, but who cares? That 20 lines of code (you can actually do it in less) is easy to write (not to mention you should only have to do it once). Try writing an asynchronous HTTP server in Java and compare it to the effort it takes in other languages.
I don't care if a language makes easy problems easier, I care if it makes hard problems easier.
I wouldn't exactly use the word "bemoan". I recall having to do funky things like copying the markdev device driver over by hand, and initializing it, so that I could install the proxyio yinst package which required the markdev device driver to install, so that I could install the actual markdev yinst package which depended on proxyio. Then there was the issue that yinst didn't handle layered dependencies very well (for large numbers of intermingled dependencies, it didn't always get the install order right… ie it knew that it needed B for A and C for B, but would try to install B first so that it could install A, and fail because C wasn't installed yet — you have to issue a yinst B to get B and C, and then yinst A to finish). I think it requred 4 or 5 seperate yinst commands, and the manual step of copying and initializing markdev to install fresh machines for the product I worked on. Figuring out the special order to issue the commands was a major pain in the ass of repeated trial, and yinst install errors.
I also recall being "assigned" as the maintainer of a package that I never had anything to do with other than happening to have checked in a 2 line fix to an existing perl module 2 years before yinst got started, and subsequently getting calls about problems with a package I knew nothing about because I had never ever touched it.
Don't get me wrong, packages are good, but the effort spent writing yinst would have probably been better spent organizing the code and packages so that the packages written for something like rpm or apt (both of which are open source and already existed) worked right.
That said, I'm sure in the time since I was circumventing around yinst to get it to work at all, that the packages and system have gotten better. But from the point in time I used it, I am certainly not bemoaning not having it. ;)
@josh
I find it amusing that you take the time to complain how the installer was not open sourced and couldn't figure out the complicated dependency chain of the non-open source network comm library.
You are talking about a Y! from yesteryear. Everything was home brewed. That was the facts of life. Whether it was true or not, most of the software solutions out there didn't cut it for Yahoo!, so it built its own. From the filo server to proxyio to yinst. There were big problems and engineers with fairly creative solutions to those problems.
Kids these days take open source software for granted. Need a comm library? I bet google code has one. Need an installer? Check that one off the list.
Is there really any more code left to write? Can't we just put the internet on autopilot and let Google figure out the dependency chains for us these days? I mean really? It's only 1s and 0s…
@pmp –
apt and rpm have dependancy handling, and did back in 2002 or so when yinst was developed. The problem that the nested dependancies weren't defined well was a packaging problem and not a "yinst" problem. If that was not clear, I apologize.
Streamlined, my points were:
1) the packages were not very well tested/defined at that time
2) even when the packages were correct, yinst was buggy and didn't do the right thing
3) using an existing system such as dpkg/apt, and spending the time designing packages with correct dependancies instead of writing a new packaging program would have solved #2, and might have solved #1 much sooner
(seriously, #2 was a pretty MAJOR bug for code released into the wild, and #1 in the case of odd obscure packages would have been expected as part of designing a package tree, but proxyio and markdev were required pretty much everywhere, and nobody ever tested installing them on a clean BSD box straight from IT?)
Save This Page
i love how it takes like 20 lines of code in java to open, read, and close a text file. damned brilliant language.