en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2004/2/12/d9b8aeff0500532a6ebed6ec1869a76b.html Thu, 12 Feb 2004 13:51:25 -0700 http://www.keithwatanabe.net/blogs/2004/2/12/d9b8aeff0500532a6ebed6ec1869a76b.html http://www.keithwatanabe.net/blogs/2007/7/2/4d1bee63a849d03072f7311406c3ed77.html
let me justify myself a little. Eclipse is a cool tool. but it's so fucking PHAT that unless you have a shitload of memory, you'll only be able to get that plus a few more items loaded on your desktop. i think this mostly stems from the fact that Java is such a memory hog. i don't know how people can optimize with Java in terms of memory. waiting until the garbage collector kicks in just doesn't cut it for me either.

then you have library dependency hell. if you're not using a good IDE like eclipse (or if you're into torture by doing everything by hand), you're pretty much screwed when getting everything together. there was, for instance, a nasty little problem with the antlr jar file that i found against WebLogic. if you use Hibernate and WebLogic together, you're going to run into this problem. solution? make antlr appear before WebLogic's version on the classpath.

then you have the monstrous XML configuration hell. no wonder Ruby on Rails is so popular. because you have to package everything up into an ugly little war file, you can't simply put all your configurations into one spot easily. if you're running in production, you have to externalize some configuration files and even then stop and restart the web server. geeze!

and then there's the whole J2EE server vs J2EE server crap. i thought the whole idea was to write once, deploy anywhere? you still have to deal to some level with reconfiguring things (at least with our application). for instance, the antlr issue with Hibernate. and don't get me started on EJBs.

the other thing Java severely is in need of is inlining or variable interpolation. variable interpolation would make one's life so easy. also, i just can't see the point in having types in Java for webapps. you end up being forced to check to see if a string is a number and then converting to a number regardless rather than doing some magic during runtime like PHP or perl.

the thing that miffs me the whole is just the whole process of having to compile, war, and deploying something in several different steps compared to fixing a file and refreshing a page.

someone once told me that Java is the new Cobol. Can we call Java COBOL 2.0? i'm starting to believe it....]]> Mon, 02 Jul 2007 10:46:04 -0600 http://www.keithwatanabe.net/blogs/2007/7/2/4d1bee63a849d03072f7311406c3ed77.html http://www.keithwatanabe.net/blogs/2007/7/20/dcc697532c76e77379c0afc6606cbb72.html
I'm being convinced daily that Java is a terrible language for the web. Even with all the various frameworks and such, the incredible number of dependencies and difficulties with configuration and dependency hell makes Java incredibly brittle. It's without a doubt a horrible language for small sites, considering the overhead.

At this point, the only chief advantage I truly see in a language like Java is the large amount of corporate support, services and major API/frameworks and systems. However, as more open scripting languages mature, I think they will slowly overtake Java once large employers see the advantage of the agility for development. You can still get stability through scripting, open languages, just not the support (which to me is massively overrated).]]> Fri, 20 Jul 2007 22:13:19 -0600 http://www.keithwatanabe.net/blogs/2007/7/20/dcc697532c76e77379c0afc6606cbb72.html http://www.keithwatanabe.net/blogs/2007/7/25/32de1e078bae0ed646485aa9ca8d8be9.html {
public void abuse(String type) throws AbuseNotFoundException;
}

public class Alfred implements KeithsPet
{
public static final int ALL = 1;
public void abuse(String type) throws AbuseNotFoundException
{
KeithsAbuseFactory f = KeithsAbuseFactory.getInstance();
Abuse abuse = f.createAbuse(type);
abuse.mentalTorture(ALL);
}
}


public static void main(String[] args)
{
Alfred baku = new Alfred();
try {
baku,abuse("mental");
baku.abuse("body size");
baku.abuse("sleep deprivation");
}
catch (Exception e)
{
baku = null;
}
System.out.println("merry xmas")
}

....your sense of humor devolves into this....]]> Wed, 25 Jul 2007 23:05:39 -0600 http://www.keithwatanabe.net/blogs/2007/7/25/32de1e078bae0ed646485aa9ca8d8be9.html http://www.keithwatanabe.net/blogs/2007/8/7/9fd8a694e22bb98e7c67f3707bcf2279.html
My answer: Java doesn't help this.

Perhaps, it's my level of expertise in the language, but after dealing with this project, I've come to realize just how HEAVY Java can be. I haven't had a chance to work in detail with the latest version, so I can't say that some of the newer features have made it better (I'm sure it has, but there are still deficiencies in the language). It could be my lack of experience with Eclipse. Maybe I'm not utilizing the right plugins and doing far too much "hand coding" in terms of boilerplate code.

No, the problem is that the language is too bulky and takes itself too seriously.

Read that statement again. Especially the last part.

Let me provide an example.

Let's say you have a primitive type that's supposedly a char and is saved into the database as a number (0 or 1). so in reality you need an int. But let's say another object requires it either as an int or be turned back into a string. So if you try to parse it, you might get an exception rather than letting the language auto-convert it. So you're doing many things here: 1) checking if the value is null; 2) checking if the type can be converted; 3) potentially converting it over to another type; 4) converting it again. And you may have to wrap all these operations in a big try/catch block. If you're working with a database that may contain null values, and you're forced to use primitive types, you're royally screwed. I mean, all you're trying to do is guarantee a value type, but you still need hundreds of checks.

This is just awful. And it's just for one value.

What if you have 40-50 values? How much of this do you have to deal with? What if you have to deal with several operations that require you to do this 40-50 times? What if there's no easy way to loop through the parameters in your object without having to take out the equally bulky Reflection API?

In perl, since objects are glorified (or blessed more specifically) forms of hashes, arrays, scalars or globs, you could, especially if you use a hash, provide a method that can loop through, utilize the Fields pragma, and easily get the same benefit.

In PHP, you can utilize variable interpolation by doing something like this for a dynamic method call:

$obj->$method()

You're pretty much out of luck with Java (at least in doing some easily the same way). You can't naturally take advantage of in-built features to really help you through these situations.

Worse yet, you might be forced to code declaratively in XML because it's nearly impossible to do something easily and dynamically in Java. Take Spring and Hibernate as examples of this.

Out-of-the-box, Java is just a monster of a language. You are forced to employ various plugins, IDEs, frameworks, etc. to really get any significant and immediate benefit. And that can take a while to do as well.

Notice the words used there: "a while." That implies time and implies not moving fast, which in turn implies lack of agility.

More of my friends are turning towards languages like Ruby and being empowered from getting more work done through frameworks like Ruby on Rails. I think people who continue to use Java are quite arrogant in believing too much in Sun's marketing. Java only is good in the hands of those that use it. But for me it's too difficult to get any real benefit that I can see.

The truth is, at the end of the day, you just want to be productive. The language is truly irrelevant as long as you and your peers utilizing it understand in detail how to get the best out of it. I for one see Java as being verbose, cumbersome, and unnecessarily detailed. The flaws that kept a lot of C/C++ programmers away I think never were truly addressed. C/C++ programmers have some advantage over Java people since they have more power and speed naturally.

Overall, if you need to execute something quickly, consider NOT using Java to do the job, unless your people are extremely adept at it. Mine aren't, nor am I so I think I will continue to stay away from it where possible.
]]> Tue, 07 Aug 2007 09:40:50 -0600 http://www.keithwatanabe.net/blogs/2007/8/7/9fd8a694e22bb98e7c67f3707bcf2279.html http://www.keithwatanabe.net/blogs/2007/8/8/dd813dee5dbb08b567377b63eb18ab72.html
Whenever you're tempted to do any of these things, you need to sit back and think about what will do the most good for you and your neighbor over the long haul. If you're going to pour your creative energies into a lump of code, why not make the world a better place while you're at it?

This can really apply to any language. The fact that this statement occurred in the Perl book made me realize the connection of programming, programming languages and their attribute as a philosophical mode of thinking.

Think about the flamewars between Java and scripting languages such as Perl. The core arguments that Perl people have against Java is the verbosity while Java programmers call Perl programmers obscure and lacking thoroughness. Shouldn't the real result be about results you bring to a business?

All of these statements above are loaded philosophical questions. The best programmers, in my view, are those that have an issue or stake involved in such questions. Should each little optimization be so critical for a business? Why not just lie to the company and say optimization is impossible that issue?

Again, it's all philosophical. But the intention behind that philosophy is equally critical. The person who refuses to optimize places importance on immediate results at the sacrifice of performance so that his end of the bargain is complete. The person who prefers verbosity emphasizes thoroughness and process. The person who favors obscurity prefers succinctness.

I think those who practice programming philosophy rather than simply programming are those who are looking or have their own set of best practices. This is one area which isn't well defined. Certainly, there are tons of books, online articles and whatnot prescribing sets of best practices, but like any philosophy, there are numerous variations that really fit with a person's core value system.]]> Wed, 08 Aug 2007 18:11:57 -0600 http://www.keithwatanabe.net/blogs/2007/8/8/dd813dee5dbb08b567377b63eb18ab72.html http://www.keithwatanabe.net/blogs/2007/8/24/ea6c303c84408b714ec53722529e809c.html
Going from SUNW to JAVA for the company stock ticker?

I honestly don't know where this guy gets his ideas from. Wherever that place is, it surely isn't from sound judgment. I can't see his reasoning in changing a branded company and seeing some sort of value involved in this. My feeling is that this is his political move to show that he instigated a major change for the company. But truthfully, everything eventually boils down to the products and services the company provides along with the real return on investment. I don't feel Sun provide any of these under Schwartz's "leadership".

My gut feeling is that Sun has gotten too massive and unfocused as a company and not putting enough money at the right places. They want to be a top to bottom solutions company from the consulting services right down to the hardware level. It's too overwhelming and underspecialized to make a statement for me.

But the thing that goads me here is the gall for Schwartz to believe that firmly in Java as to desecrate Sun's remaining legacy with possibly it's biggest failures (say what you want, I'm a believer that Java has done more harm than good to the IT industry as a whole). But now what he's saying is that Java has more value than their servers, which to me is a huge laugh.

Java is a growing fossil. It's like a decaying piece of meat in your garden, decomposing and making everything else stink. Or worse yet, it decomposes everything around it.

I think Sun needs to stop proposing myths about itself, and more importantly Java. After working with all these "best practices" in industry, I'm firmly convinced that these are not truly "best practices" but just methods to ensure job security for wannabe bureaucrats. And to leave with my last thoughts, Java was never useful from the beginning. The industry (NOT SUN) made java use-able.]]> Fri, 24 Aug 2007 10:04:07 -0600 http://www.keithwatanabe.net/blogs/2007/8/24/ea6c303c84408b714ec53722529e809c.html http://www.keithwatanabe.net/blogs/2007/8/27/83e223d89f19c3308f4c1eca1067d093.html
I just don't get it.

Half the features in WebLogic probably will never be touched by most people. I'm certain that EJBs are dying a prolongated death as people realize that it was typical Sun overpromising and underdelivering. I have no idea why people would want to use a session facade, using session beans. The books I've read warn people away from entity beans (and I wholeheartedly agree!). And if you really need messaging, just find something that focuses exclusively on messaging!

The funnier thing is that I know a lot of places that are considered "entrprise class" have legacy databases with tons of stored procedures running. If you're desperate and require a Java layer, iBatis seems like a good substitute. Otherwise, you'd spend a crapload of time attempting to create an entity bean using BMP.

I think ORMs are okay, but mostly overrated. Highly tuned SQL seems more reliable and comforting for people than object-relational modeling. If you're expecting a ton of incoming hits or transactions, maybe something like Hibernate might be worth investigating. However, EJBs to me are just too painful to implement, even with the 3.0 spec coming out. Perhaps, it's a case of too little too late for EJBs.

Anyway, today we finally made it to SIT and the WebLogic server basically got overloaded since the application apparently was too heavy and memory intensive. We were barely hitting 4 people hitting the application simultaneously. Very sad.

My laptop contains WebLogic as well. The thing is pathetically fat and slow. There should be a way to disable features (maybe I haven't seen it; then again I'm no WebLogic expert and don't have a manual readily available). That said, for what we're doing Tomcat with clustering probably would've sufficed and then some (like save us a few hundred grand in licensing!)

I'm actually quite happy that I had the opportunity to work with WebLogic. I've worked with Tomcat, JRun, JBoss and now WebLogic and can safely say that I am pretty disappointed with this whole J2EE crud. I think I'm going to stick with PHP and mod_perl and attempt to retain my sanity.]]> Mon, 27 Aug 2007 07:12:04 -0600 http://www.keithwatanabe.net/blogs/2007/8/27/83e223d89f19c3308f4c1eca1067d093.html http://www.keithwatanabe.net/blogs/2007/11/16/f751ae16a2b9ec6dea6e368cca0ee9ee.html Fri, 16 Nov 2007 21:29:41 -0700 http://www.keithwatanabe.net/blogs/2007/11/16/f751ae16a2b9ec6dea6e368cca0ee9ee.html