 |
|
 |
 |
|
|
 Jack Shirazi's BlogJ2EE ArchivesJava and coolness, a discussionPosted by jacksjpt on September 22, 2004 at 01:04 PM | Permalink | Comments (14)In my last newsletter, I laid into those who criticise Java for what I see as simple jealousy. That lead to the following discussion with one of my readers, who I call "B" (I'm the "J" correspondent in the following discussion). B. I've been a J2EE programmer for 3 years now, and a Java programmer for 6. But, I only use them to pay the bills. Never under any circumstances have I written a personal application in Java. I feel I fall into the category of one who thinks Java is woefully uncool, and knows intimately why. J. Okay, I've been one for 9 years, and written dozens of personal Java apps. And enjoy it all the time. But let's hear what you have to say. B Firstly, you said 'In I.T. it seems, only new or unsuccessful niche things are cool'. Well UNIX is still cool... as is C... and they are both older and more popular and more successful than Java. You can't hop online at all these days without using both of those technologies... the same cannot be said about Java. J. I'd hardly call Thompson and Ritchie's Unix cool. Or BSD. Maybe you mean Linux? Or do you throw in those early ones and the whole of HP/UX, Solaris, RS/UX, to mention but a few? Linux isn't so much cool as a stand against M$. J. And C is cool? I think you are living in the past. C is a workhorse, but cool? To say that a 35 year old language that is still going is more successful than a 10 year old language that is still going is a truism. And Fortran is even more successful than both on that basis - there is still more scientific computing using Fortran than C or Java. Though my experience is that Java is finally weaning them off Fortran. But I don't understand your point about hopping online. Mosaic and IE were written before Java was released, and all commercial browsers are derivatives of these, so that is hardly surprising. Are you suggesting that if Java is a better language, then everyone should quickly move onto a Java based browser? Why? Technology that works should be used until it no longer works - our industry has a woeful inability to eliminate bugs rapidly, so the older the product the less buggy. B. Most of the folks I talk to think C is 'cool' (along with BSD), mainly because coding it gives you the bare-metal feel demanded by hard-core programmers. Its not great for consultants, because of the learning curve, and you have to reinvent the wheel sometimes. But Perl and Python can save you there, with even less code than Java. J. Okay, I guess we'll have to disagree on this one. I just cannot see C or BSD as cool. For "bare-metal" feel, Perl is way nicer, you can hit any sys call in a very flexible way, and it is way more dynamic. I used to do that kind of thing. But nowadays that's real boring. The action for me is a "bare-web" feel. And if you want to hack around the web, Java is perfect. B. Okay, we'll agree to disagree. Let's move on to your 'J2EE is in a thousand successful commercial applications and cannot be considered acedemic'. But you didn't really address the question there. J2EE is woefully academic - they focus far too much on what is RIGHT, as opposed to what makes sense from a practical standpoint. Alas, the most popular piece of the J2EE framework is JSPs, and almost didn't make it into the spec. Its popular in large part because it is INCORRECT. There is no MVC, barely any seperation of components, its all one big mess. Its the most popular piece of J2EE because its least academic, and most like those horrible ASP/PHP frameworks... and nobody at Sun has bothered to understand why. J. But JSP is J2EE. And so is JDBC. And JMS. And Servlets. I suspect you mean EJBs when you are talking about academic. But EJB shortcomings are well known in the Java community. Personally I normally recommend not to use them unless you know why you need them. Why tarnish the whole of J2EE because of EJB? You might as well say Linux is a failure because it has fragmented into multiple versions. You can always find things to pick at in anything. B. Okay, I'll make this point: if J2EE worked as well as other frameworks did, then what would be the purpose of your site? Why on earth would so many people be begging you for performance tuning advice, or tips and tricks for avoiding J2EE pitfalls? J. You've got this backwards. Java made my site possible because there are so many tools for Java and capabilities in the JVM. Kirk and I made the site a success by working damn hard. There are plenty of other tuning sites for different things - like linux, just about every database, C, C++, and much more. When I was researching for my book, I gathered together a whole list of C tuning stuff - and found half a dozen books with one or more chapters on tuning C programs. And I found many C programmers bemoaning that lack of tuning information available for C. I just wasn't interested in writing a 'C tuning' book. There isn't a language that doesn't need tuning, because of human programmer inefficiencies, and because of the number of possible contention points in any complex program - especially concurrent request handling distributed applications. B. Let's move back to the core gripe. I like Java... I just dont like the direction its been heading for the past 3 years, and I dont think it has much of a future. And I'm not alone. Half the Java programmers I know feel the same way... the rest either dont know any other languages better, or have faith that eventually Sun will make things work well. J. Chuckle. Well I guess I'm betting my career that you are wrong. I'm sure there are better things than Java. But not at the moment, at least nothing mainstream is in my opinion - not C, C++, C#, VB, Perl, PHP, Delphi, Python, SQL, Javascript. Which are the next 10 most popular languages nowadays. Of these, Perl is nice, and I still use it for lots of things. But back when I was a full time Perl programmer, we tried to build large scale projects with Perl and found it impossible, the stuff was just unmaintainable no matter how rigorously you tried to follow a set of coding standards. A 7,000 class project in Perl would never be feasible. A 7,000 class project in Java is commonplace. B. My main gripe is that Java peaked in 'coolness' around about Java 1.1. Since then very little work has been done on the 'guts' of Java, and instead they kept focusing on bigger, more academic, and more bloated features. Java 1.2 added 'Swing', the academically correct yet ultimately useless GUI toolkit. J2EE brought us lots of things very few people need (like EJBs, JNDI, and RMI in general), as well as old concepts from people outside the J2EE group entirely (Servlets, JSPs, JDBC, JMS, etc.) Even today, some of the 'coolest' Java work these days is being done by IBM, not Sun. J. I think this is called "making it a success". B. In the minds of hard-core developers, allowing the branching of Java is the only way to ensure it can evolve into a better language. In the minds of consultants and project managers, branching is ALWAYS a nightmare, so it should be stopped. Problem. J. Again, I guess we'll disagree. I see Linux fracturing as one of its really big problems. It would be significantly more successful if there was one guaranteed version rather than a free for all. And that's exactly the reason Windows beat out the other Unix's - MS guaranteed a single reference point compared to the Unix vendors who fought each other into a lose-lose situation. Saying you support Java branching is the same to me as you saying you want .NET to become the monopoly developer environment. B. The most insightful comment I saw on this subject was on Slashdot, where somebody said with all sincerity, that Java will be the next COBOL. Not that Java isn't a better language, but it will be what a lot of overly complex business apps will be written in, for better or worse... and they'll always need to be maintained. Good news - you'll probably always be able to find work if your speciality is J2EE. J. LOL. Everything is the next COBOL. I didn't find that insightful the first time I saw it in the 90's, and you probably saw the millionth incarnation of "X is the next COBOL". B. When the hard-core programmers stop thinking Java is 'cool', they stop making those so-called niche programs that extend it. And where would you be today without those crazy guys? Without Servlets, without JMS, without JDBC, without JBOSS, without STRUTS, without OSCache, and without Log4J. You should be VERY worried that they are leaving Java in droves, while Sun is tightening its grip... because now you have to rely on Sun alone to save Java. J. Except there seem to be more and more projects in Java every day. And no, I'm not in the least worried, because I don't see people leaving Java in droves, I see them coming all the time. I guess we just move in very different circles. When Perl was becoming popular and CPAN was being set up in the mid-90's, I was in there helping do some (a very tiny bit mind you) of the core. The excitement was fantastic, and the result was a set of supporting modules which surpassed anything I ever believed possible. More comprehensive and extensive than anything any other language had. And Java has surpassed that as far as I'm concerned. Only recently mind you. But that's not surprising, its only just beginning to mature. B. "I guess we just move in very different circles.". Bingo... the people you know and trust think Java is 'cool,' whereas the people I know and trust think its 'uncool.' Therefore, I see people leaving in droves, whereas you see people coming. So the question boils down to, which group is more reliable in making that judgement? Probably neither... but I'm still going to rant a bit more. B. I generally attend O'Reilly conferences, since all the other ones are too full of marketing fluff for my tastes. 5 years ago, people were all excited about Java. I talked with a lot of the guys making Tomcat, and the guys who literally 'wrote the book' on a lot of the killer Java technologies, and J2EE. But recently, the people excited about doing work in Java are few and far between. Most of those guys have moved on to new projects, many of which do not use Java. And even those who do still work with Java criticise Sun and Java regularly because they are too focused on bloat, and not on functionality. A lot of them are closet Python or Objective-C bigots. Its really really rare for me to find somebody excited about using Java. And I also see no 'converts' anymore. Nobody who was using Perl or PHP or C who finds Java and says 'now THATS the way to do it!' It used to happen, but not in the past few years. How about you? B. Without those crazy hackers (O'Reilly lamely dubbed them 'alpha geeks') thinking Java is cool and extending it... well... I'm concerned that Java will cease being innovative. Because Sun certainly doesn't get it. Maybe being closer to the Java pulse you know about some cool projects that I dont... but Ive been looking... and everything at java-source.net and sourceforge.com is just the same thing over and over. Extensions of old ideas, or ports of applications from other languages. Nothing new... J. It's those different circles. I see lots of great creative projects hitting exactly the sweet spot for me. Standardized APIs to expert systems, fuzzy logic additions, internet spidering, better data structures, CRM projects, Java games, all the stuff I can use to do the things I want. Again, I guess we'll agree to disagree. Java IDE comparisonPosted by jacksjpt on August 27, 2004 at 02:48 AM | Permalink | Comments (15)There is a "Java IDE shootout" from JavaOne 2004 at here (the pdf is available free and fairly detailed). It presents an overview comparison of IntelliJ, Eclipse, NetBeans, Emacs and JDeveloper Please understand, this is for your information not to start any IDE wars. I'm sure you each have your own favorite IDE, and some of you will prefer to die defending it rather than admit there is any viable alternative. Personally I have to be IDE agnostic because I have to use whatever my customers are using - though surprisingly often now there is a choice. It used to be that when I went consulting, a site would have mandated one IDE, and there was a big process which they went through to select that IDE (you could tell because it left visible scars on some developers). Nowadays, almost every site I get to has no mandated Java IDE, instead you can choose one from a list - or whatever you want in some cases - as long as you can integrate it into the existing development process. I went to a lot of different sites over the years. It used to be the emacs IDE guys who were the loudest about how great their IDE was. Nowadays it is the IntelliJ guys. And I do mean guys, none of the female developers I met used to spout on about her IDE being the best. Integrating HTML validation to my site building processPosted by jacksjpt on July 14, 2004 at 04:46 AM | Permalink | Comments (8)I generate my website using a local servlet container and JSP pages converting text source to html pages, then I upload all the pages to the server. Inspired by reading Cleaning Your Web Pages with HTML Tidy, I decided it was about time I had my HTML validated. But I wanted to do it as an integral part of the build process, not as an afterthought. That way, if HTML errors crept in to the pages for whatever reason, they would be flagged immediately. It turned extremely easy to do so. First off, I am already building my pages locally using a Java program which connects to my local servlet container and asks for each page then stores it locally. This allows me to have a dynamic page display process for building my pages, giving me all the power and flexibility of servlets and JSPs. The result is a set of static pages which I can upload to my internet site, providing extremely fast downloads of pages from my internet site JavaPerformanceTuning.com. So all I had to do to add HTML validation was add one method to my build process. Once each page is complete and loaded into a local file, I simply added a call to a new validateHTML(File destinationfile) method. My validateHTML method basically calls the "Tidy" executable on the newly created HTML file, (Tidy validates and corrects HTML, and is available here). Then I check Tidy's output for anything I'm interested in. If there is a problem, I throw an exception. I use Process to execute Tidy as an external process. I could process Tidy's stdout and stderr directly from the program, but there is no need, it is much simpler to use Tidy to dump these to files and check those files. I don't actually use Tidy's HTML output for my web pages, I'm really using it only as a validator. It is worth noting that the W3 organization has a validator at http://validator.w3.org/ if you only need to check some pages, but in my case I wanted to have all my pages checked each time I re-built the site. I am only interested in the line notifcation warnings and errors that Tidy emits, so I use a regular expression to detect and parse those lines. In addition, there are some warnings that I don't really care to fix at the moment, so I have added the ability to ignore those, either on a per file basis or globally (see the two entries in the TidyNoficationsToIgnore HashMap for examples). Finally, if I do find a problem, I like to print the error and relevant line from the HTML file so that I can see where it is and what to fix Here's the code in case anyone else needs to resolve this problem in a similar way. If you have problems getting Tidy to execute, it's probably a path issue so you might try using the path to the executable in the command, e.g. .\Tidy or ./Tidy
//Note I am putting this code fragment in the public domain
public static final Pattern TidyHTMLLineNotification = Pattern.compile("^line\\s+(\\d+)\\s+column\\s+(\\d+)\\s+\\-\\s+(.*)$");
static HashMap TidyNoficationsToIgnore = new HashMap();
static
{
TidyNoficationsToIgnore.put("newsletter013.shtml+Warning: discarding unexpected </p>", Boolean.TRUE);
TidyNoficationsToIgnore.put("Warning: trimming empty <p>", Boolean.TRUE); //always ignore
}
public static void validateHTML(File destinationfile)
throws IOException, InterruptedException
{
//Stdout to tt.txt, stderr to t2.txt.
//tt.txt contains fixed HTML if you want it.
//t2.txt contains Tidy's warnings and errors
String command = "Tidy -o tt.txt -f t2.txt " + destinationfile;
Runtime.getRuntime().exec(command).waitFor();
BufferedReader rdr = new BufferedReader(new FileReader("t2.txt"));
String line;
while( (line = rdr.readLine()) != null)
{
//Only interested in lines beginning with "line"
if (line.startsWith("line "))
{
Matcher m = TidyHTMLLineNotification.matcher(line);
if (m.matches())
{
String linenumstr = m.group(1);
String colnum = m.group(2);
String message = m.group(3);
if ( (TidyNoficationsToIgnore.get(message) != Boolean.TRUE) &&
(TidyNoficationsToIgnore.get(destinationfile.toString()+'+'+message) != Boolean.TRUE) )
{
//line number in destinationfile of problem. Read the file
//and get that line and the line before
int linenum = Integer.parseInt(linenumstr);
BufferedReader rdr2 = new BufferedReader(new FileReader(destinationfile));
String l2 = null, l1 = null;
for (int i = 0; i < linenum; i++)
{
l1 = l2;
l2 = rdr2.readLine();
}
rdr2.close();
rdr.close();
throw new IOException("HTML Validation Problem Identified by Tidy in file " + destinationfile + ": line " +
linenum + " / " + message + System.getProperty("line.separator") + l1 +System.getProperty("line.separator") + l2);
}
}
}
}
rdr.close();
}
}
Java Case StudiesPosted by jacksjpt on July 24, 2003 at 05:03 AM | Permalink | Comments (4)I love looking through case studies. They can teach you so much about what to do, what not to do, what is in vogue, etc. All those useful design patterns came from analyzing lots of case studies and seeing what worked; and sometimes, more importantly, what didn't work. So this year I decided to start listing case studies when I find them. And a great place to start is JavaOne, where lots of the really big case studies get presented. So here they are. The highlights for me: eBay architected for 1 billion page views a day; The Brazilian National Health handling 100 million outpatient procedues a month; 24 million Java Cards used by Taiwan Health Insurance; Capital One Financial handling 80 million transactions each month. http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/1477.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2165.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2186.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2680.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2862.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2882.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/3014.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/3054.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/3264.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/3284.pdf
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/3588.pdf
| |
 java.net RSS Feeds
|
