I have no conerns about development on the server/application server side. I do have concerns about making sure that my web designers do -not- have to learn a programming language of any kind. (Setting them up with simple tags to work with is easy, as that fits into their mindset of working with HTML as it is).
I have looked at Enhydra - very interesting model in there. Though, I found with it, when reading through the docs, that you still end up having java code involved with presentation - just separate (having code involved with building presentation separate from presentation bothers me in some environments).
I still want to take a run with building an application with Enhydra, however, as it appears to be an interesting environment.
I'm amused to have had the article marked as 'troll'. Granted - I took a rather strong tone in it, but then again, one should see the tone regarding JSP in the velocity article. (It is a shame, actually, that the YMTD article will be many people's first exposure to velocity - as it looks like it could be a very useful tool... Had my first readings on velocity been some of the other documents on their site, I would have probably written off the YMTD article as a marketingish blurb (though, I still would have felt the need to correct some of their assertions about JSP:) ).
Of course, speaking as a developer who uses java (I use too many other languages to be able to just call myself a 'java developer') - i can understand a lot of the java hatred out there. People trying to pound square pegs into round holes and getting pissed that it doesn't work that way, and all that. I know people who still think java is a crappy language because applets, as a general rule, suck ass. Personally, i've found java very useful on the server and on the middleware side. But i'm a crack-head like that.
(Of course, i'd be very surprised if I was still using java in 5 years, i'm sure by that point, there would be other technologies to move on... Real Software Developers can develop with the tools at hand (hopefully choosing the Right Tool[tm]) - and aren't limited to one, maybe two tools:)
My issue was less with Velocity per se, than with what I viewed as gross inaccuracies regarding JSP presented in that article. Not to mention the fact, that article was presented as "JSP still has its flaws" in the post I was responding to. So, I hit the velocity article from the standpoint of debunking it's perceived flaws of JSP - not so much as a debunking of velocity. Granted - I can understand where a lot of them came from, as they're not unlike first impressions I had on JSP, as well as first experiences with JSP code. It's entirely possible that our development group uses JSP in a fashion -very- different from the average JSP developer.
Alas, juggling two jobs doesn't leave me a lot of time to dive deeply into a conversation on this, but I will make this point. My personal perference is to have as -little- logic of any kind in display pages. Whether it's JSP augmented by tags, or Velocity, or any of the half dozen other page description languages out there. (If things ease up work wise for me, I may join the discussion of velocity - if only because I saw a handful of things in my going back and reading the user docs on it that could possibly use some improvement).
It seems to me that where velocity will succeed is in having a very strictly defined, minimal syntax outside of the html code. My personal -preference- here is for syntaxes that line up more naturally with an XML style, however. It would be fairly straightforward for me to provide my web designers with a set of tags that pretty much provide the Velocity functionality (sans the macros, but that's okay for a variety of other reasons).
I wish the velocity crew the best, and may very well put up a velocity environment for play here once I get some of my other dev projects finished. It just tends to put a foul taste in my mouth when my first exposure to a project is laced with as many inaccuracies as the YMTD. (But, as I mentioned above, the YMTD -is- probably correct in terms of how the average JSP developer might end up using JSP pages.)
Funny, but most of his comments seemed to be geared towards other issues, such as ease of development/deployment and extensibility.
I'd rather have my page designers working with jsp, giving them a handful of well documented, custom tags to do the dynamic stuff, than try to either a) have java programmers do page design or b) page designers to java programming.
No, shit, really? I've done implemntation work for jsp, I know what goes on in jsp engines. One of the reasons we use jsp is -because- we can provide well defined tags that our HTML designers can use and be happy with.
I wouldn't expect a designer to code in velocity anymore than I would expect them to write scriptlet code. But I can have them put tags around their page to ensure that we can template the look and feel of the page in a trivial fashion, or use tags that automatically backfill from previously entered data (or pull their data from a supplied object).
I have issue with a lot of the 'points' raised in this article, however...
(Let's ignore the fact that they're using a rather idiotic way of using jsp in their article - and in fact, it's rather plain to see that the article is written in a way that displays only a very minimal knowledge of jsp).
So - their first point, is that since Velocity code isn't embedded between tags, it makes it 'easier to see what's going on' when you bring up the page in a browser... Forget the fact that the way Velocity does things would completely destroy the appearance of layout if you just bought the page up in the browser (compared to, most of the jsp pages on the project that I work on, which a browser can actually display most of the layout with very few issues).
Honestly, though, when i have code in a jsp page (or a cgi script, or a, or a) - i almost -never- load it up straight into a browser. There's too much context that would be missing (and this is ALSO true for velocity!)
So - their first point is a weak one.
Let's go on to the second one...
They complain about the way that JSP works, in that it compiles down to java/class files, and that a temp directory could 'grow without bounds'! First off, I've been running production jsp engines for nearly a year and a half now - and I have -never- seen a temp directory grow in the way that they're afraid of, even in a development environment.
In addition, they also seem to be under the mistaken impression that JSP output isn't buffered by default. For a group that's working in the context of Apache's Jakarta project, i'm surprised that they don't seem to understand that JSP output IS in fact buffered.
Last but not least, they use a set of what the java generated from jsp looks like... Here's a clue - end developers never even need to see that stuff...
Now, onto their complaints about error handling...
This section is actually halfway decent, and isn't as full of the erroneous assumptions of other sections, but again, they use bad code examples (e.g. they do an if( true ) throw Exception() and then complain that there's a 'statement not reached' error because of code generated further on in the page - please...) They also completely miss the fact that if you want to - you can handle exceptions right in the page, in fact, I didn't see anything in their comparision about how to handle runtime errors such as this in the velocity engine. tsk. tsk.
I will grant them that at times, a JSP engine can throw out ugly errors, but i've never had it throw anything out that was difficult to deal with (and most of the time, the jakarta engine gives enough proper line number information to be able to find the exact line of the error).
They then go on in the next section to complain about how java beans are accessed in JSP pages... In our 200+ page JSP application, we don't have a single jsp:useBean definition. Nope - instead, we have defied jsp tags (*gasp* - yes, they seem to be so far ignoring the fact that you can define your own set of tags for jsp) that export necessary objects and provide needed functionality. Our application design is separated enough that it's a rare thing to have actual java code/scriptlets in our pages. (Unfortunately, I can't see a way to do a velocity page without their velocity code)
Of course, they do finally hit on tags, but again seem to be doing stupid things with their tags. Honestly, between you and me, if I ever had a (non-junior) developer underneath me write JSP code like this, I would either a) have them rewrite the code or b) fire them on the spot.
They seem to feel that extra typing is a bad thing (even if it makes the layout inconsistent - and yes - throwing #blah tags into the middle of an HTML page is inconsistent compared to a well formed XML document.
They also go on to claim that JSP is pigeonholed to -just- produce HTML. Man, am I glad they cleared that up for me, I must be doing something horrifically wrong, what with outputting XML and WAP, along with HTML, as well as formatted text.
Now - they finally get on to something that Velocity -may- have an advantage in at this point, embedding in other applications. However, this is an implementation issue, not a language/syntax issue. (And in fact, I have been able to embed jasper with relative ease into my applications - yes, you need to gasp *know java* to be able to do it...)
They then move on to some FUD, that because JSP is a 'new' standard it is unstable (and where, pray tell, is velocity's standard? Oh, that's right, its on their TODO list), and feel that the advantage to velocity is that there's only one implementation (as opposed to multiple jsp implementations (which, for the record, I have not had any problem moving code between)).
They then move into a hosting argument, that allowing people you host for to put java into their pages is a bad thing, because they could write something that uses up system memory! (Like, oh, say a CGI...). Of course, because velocity only has foreach, and no for, there's no way to do an 'infinite' looping situation to build up memory (poor, poor, naive developers, give me a day with velocity, and i can probably write something that will throw your server down to the ground performancewise:). They also completely miss the fact that it's fairly easy to limit functionality with Java's security mechanisms... Of course, the gods forbid that someone managing a server that does hosting -understand- what they're providing.
This document is FULL of FUD, up one side and down the other. And it is a shame, because it looks like velocity may actually have the potential to be useful, but to build their entire argument on a set of horrific misconceptions about jsp development, without trying to -really- understand what's going on... well, that pretty much ensures that it will never be used on any development project I work on. (Sorry, I'd really rather not use a project bourne out of such naivite). This strikes me as a project that was started up because someone spent a day with JSP, got discouraged, and started thinking of other ways to do things - re-inventing all the problems of older CGI/scripting solutions. Yippie. (Gee, what will we see first, an HTML editor that understands JSP or an HTML editor that understands velocity? Hrm....:)
I'm sure there may be deeper benefits/issues to velocity - this is based soley on this one particular article 'justifying' velocity's existence, and showing all the 'problems' with jsp.
It depends on the background of the java developer...
I've found that java developers who come from a heavy c/c++/unix background tend to know what's going on underneath the language -fairly- well, and understand how to do things like work in a debugger, work with a profiller (and interpret the results from said profiler!) - as well as handle a lot of things outside of direct development, i.e. system maintenance, development environment tuning, etc... etc... etc...
I find that developers for whom java is their first programming language, tend to be very weak all the way around. (Then again, i've found that to be true for most developers who are on their 'first programming language').
(I do want to get back into doing regular C++ programming, it's been about 2 years for me, hrm, perhaps its time to re-install that BeOS cd...)
...to see mention of java servlets, but NOT jsp... where i work we use a combination of jsp's and servlets (all the 'hard' logic and stuff sits in the servlets, the jsps are for page design).
I love it, it means our java developers can concentrate on logic, and our HTML designers only need to learn a small handful of JSP tags, but can concentrate on their display.
The Sun Rays are basically dumb, network attached frame buffers. There is VERY little logic on these things, the network requirements are very high for them, since all audio/video has to be blasted across the network (as opposed to X terminals, which send X events).
They run pretty well, though, the more sun rays you hook up to a server, the beefier your network and servers need to be.
Sun had serious issues with the Sun Ray's at JavaOne last year.
But full-length CDs only account for 92% of the RIAA's revenue. They did have weak performance in the other 8%. CD singles, as laready noted, dropped revenue by 36%. But the real casualty percentage-wise was cassingles, which lost over 90% of its revenue from last year.
He never recognizes CD singles as 8%. He recognizes 'non full-length CD sales' as 8%. That 8% includes cassettes, cassingles, single cds, etc... etc... etc...
This is why myself and others are working on forming record labels that keep copyright and master ownership with... (take a deep breath here folks) the band.
The particular model i'm setting up with Silent Noise is we're basically a services organization for bands. They contract us to perform services such as CD distribution, promotion, etc... In turn, we get paid for our services out of the sales of CDs and related activities. Without ever dipping into the Band's royalties. So, bands on s/n will be getting their royalties from day one, instead of having to 'pay back'.
There are elements of the business model still being worked on. We'll really only work well with self produced bands (since we aren't acting as a loan organization, for financing recording), and we're bouncing around ideas of co-investing with the bands to cover spin up costs (e.g. getting that first run of CDs done, etc...). But in the end, the band still owns everything.
If you want more info on what Silent Noise is doing, and how we'll be working, feel free to email me at dgarcia@silentnoise.org. I'd be more than happy to answer questions about how we'll be working. Once the website is finished, all that information will be up there as well.
The SunRay is basically a framebuffer hooked up to the network. Applications don't get downloaded to the sunray. The only thing that gets downloaded to it is audio and image data.
www.airbornelaser.com - it's kind of funny, and very surreal.
I thought it was a joke the first time I saw it, and watching the promo films on there made me think of the opening to Real Genius.
Gotta love it...
TROLL:
This only blocks SMTP ****MAIL****, not websites. What kind of bullshit is that? "They can't go to their websites" blah blah blah, some more stuff i made up, blah blah blah.
Let's respond to this one... You're wrong here. Very very wrong here, and ignorant. If you couldn't be bothered to look up what you were blathering about, what right do you have to rip the author of this article?
Let's see, look around the maps site, a little bit, ahhh, here it is... two clicks from the front page...
"Subscription via Multihop eBGP4. This is the oldest (and for a while, the only) mechanism for MAPS RBL usage by third parties (which means anybody other than us)."
Wow, they were doing this before the dns method you were talking about.
In the future, check your facts before spewing them out, in the case of INFORMATIVE, your fingers, or in the case of TROLL, your ass.
What's even dumber is that there's a company out there called mypoints that's been doing this for quite some time (though, granted, you have to actually signup to get the server/mailings, sounds like this guy would use it for spamming).
I had been under the impression that he had already plead guilty to another set of charges, and in fact, he was serving time for those charges while awaiting trial for others. Perhaps people should check up on these things more? (I'll be the first to admit i'm wrong if someone can document otherwise:)
Slashdot Mirror
It's the difference between being a software developer who uses java and a java programmer who can't develop software :)
It's my humble belief that strong software developers should be able to develop in ANY language...
Cheers,
I have no conerns about development on the server/application server side. I do have concerns about making sure that my web designers do -not- have to learn a programming language of any kind. (Setting them up with simple tags to work with is easy, as that fits into their mindset of working with HTML as it is).
Cheers,
I have looked at Enhydra - very interesting model in there. Though, I found with it, when reading through the docs, that you still end up having java code involved with presentation - just separate (having code involved with building presentation separate from presentation bothers me in some environments).
I still want to take a run with building an application with Enhydra, however, as it appears to be an interesting environment.
Cheers,
I'm amused to have had the article marked as 'troll'. Granted - I took a rather strong tone in it, but then again, one should see the tone regarding JSP in the velocity article. (It is a shame, actually, that the YMTD article will be many people's first exposure to velocity - as it looks like it could be a very useful tool... Had my first readings on velocity been some of the other documents on their site, I would have probably written off the YMTD article as a marketingish blurb (though, I still would have felt the need to correct some of their assertions about JSP :) ).
:)
Of course, speaking as a developer who uses java (I use too many other languages to be able to just call myself a 'java developer') - i can understand a lot of the java hatred out there. People trying to pound square pegs into round holes and getting pissed that it doesn't work that way, and all that. I know people who still think java is a crappy language because applets, as a general rule, suck ass. Personally, i've found java very useful on the server and on the middleware side. But i'm a crack-head like that.
(Of course, i'd be very surprised if I was still using java in 5 years, i'm sure by that point, there would be other technologies to move on... Real Software Developers can develop with the tools at hand (hopefully choosing the Right Tool[tm]) - and aren't limited to one, maybe two tools
Cheers,
My issue was less with Velocity per se, than with what I viewed as gross inaccuracies regarding JSP presented in that article. Not to mention the fact, that article was presented as "JSP still has its flaws" in the post I was responding to. So, I hit the velocity article from the standpoint of debunking it's perceived flaws of JSP - not so much as a debunking of velocity. Granted - I can understand where a lot of them came from, as they're not unlike first impressions I had on JSP, as well as first experiences with JSP code. It's entirely possible that our development group uses JSP in a fashion -very- different from the average JSP developer.
Alas, juggling two jobs doesn't leave me a lot of time to dive deeply into a conversation on this, but I will make this point. My personal perference is to have as -little- logic of any kind in display pages. Whether it's JSP augmented by tags, or Velocity, or any of the half dozen other page description languages out there. (If things ease up work wise for me, I may join the discussion of velocity - if only because I saw a handful of things in my going back and reading the user docs on it that could possibly use some improvement).
It seems to me that where velocity will succeed is in having a very strictly defined, minimal syntax outside of the html code. My personal -preference- here is for syntaxes that line up more naturally with an XML style, however. It would be fairly straightforward for me to provide my web designers with a set of tags that pretty much provide the Velocity functionality (sans the macros, but that's okay for a variety of other reasons).
I wish the velocity crew the best, and may very well put up a velocity environment for play here once I get some of my other dev projects finished. It just tends to put a foul taste in my mouth when my first exposure to a project is laced with as many inaccuracies as the YMTD. (But, as I mentioned above, the YMTD -is- probably correct in terms of how the average JSP developer might end up using JSP pages.)
Cheers,
Funny, but most of his comments seemed to be geared towards other issues, such as ease of development/deployment and extensibility.
I'd rather have my page designers working with jsp, giving them a handful of well documented, custom tags to do the dynamic stuff, than try to either a) have java programmers do page design or b) page designers to java programming.
No, shit, really? I've done implemntation work for jsp, I know what goes on in jsp engines. One of the reasons we use jsp is -because- we can provide well defined tags that our HTML designers can use and be happy with.
I wouldn't expect a designer to code in velocity anymore than I would expect them to write scriptlet code. But I can have them put tags around their page to ensure that we can template the look and feel of the page in a trivial fashion, or use tags that automatically backfill from previously entered data (or pull their data from a supplied object).
--Dg
I have issue with a lot of the 'points' raised in this article, however...
:). They also completely miss the fact that it's fairly easy to limit functionality with Java's security mechanisms... Of course, the gods forbid that someone managing a server that does hosting -understand- what they're providing.
:)
(Let's ignore the fact that they're using a rather idiotic way of using jsp in their article - and in fact, it's rather plain to see that the article is written in a way that displays only a very minimal knowledge of jsp).
So - their first point, is that since Velocity code isn't embedded between tags, it makes it 'easier to see what's going on' when you bring up the page in a browser... Forget the fact that the way Velocity does things would completely destroy the appearance of layout if you just bought the page up in the browser (compared to, most of the jsp pages on the project that I work on, which a browser can actually display most of the layout with very few issues).
Honestly, though, when i have code in a jsp page (or a cgi script, or a, or a) - i almost -never- load it up straight into a browser. There's too much context that would be missing (and this is ALSO true for velocity!)
So - their first point is a weak one.
Let's go on to the second one...
They complain about the way that JSP works, in that it compiles down to java/class files, and that a temp directory could 'grow without bounds'! First off, I've been running production jsp engines for nearly a year and a half now - and I have -never- seen a temp directory grow in the way that they're afraid of, even in a development environment.
In addition, they also seem to be under the mistaken impression that JSP output isn't buffered by default. For a group that's working in the context of Apache's Jakarta project, i'm surprised that they don't seem to understand that JSP output IS in fact buffered.
Last but not least, they use a set of what the java generated from jsp looks like... Here's a clue - end developers never even need to see that stuff...
Now, onto their complaints about error handling...
This section is actually halfway decent, and isn't as full of the erroneous assumptions of other sections, but again, they use bad code examples (e.g. they do an if( true ) throw Exception() and then complain that there's a 'statement not reached' error because of code generated further on in the page - please...) They also completely miss the fact that if you want to - you can handle exceptions right in the page, in fact, I didn't see anything in their comparision about how to handle runtime errors such as this in the velocity engine. tsk. tsk.
I will grant them that at times, a JSP engine can throw out ugly errors, but i've never had it throw anything out that was difficult to deal with (and most of the time, the jakarta engine gives enough proper line number information to be able to find the exact line of the error).
They then go on in the next section to complain about how java beans are accessed in JSP pages... In our 200+ page JSP application, we don't have a single jsp:useBean definition. Nope - instead, we have defied jsp tags (*gasp* - yes, they seem to be so far ignoring the fact that you can define your own set of tags for jsp) that export necessary objects and provide needed functionality. Our application design is separated enough that it's a rare thing to have actual java code/scriptlets in our pages. (Unfortunately, I can't see a way to do a velocity page without their velocity code)
Of course, they do finally hit on tags, but again seem to be doing stupid things with their tags. Honestly, between you and me, if I ever had a (non-junior) developer underneath me write JSP code like this, I would either a) have them rewrite the code or b) fire them on the spot.
They seem to feel that extra typing is a bad thing (even if it makes the layout inconsistent - and yes - throwing #blah tags into the middle of an HTML page is inconsistent compared to a well formed XML document.
They also go on to claim that JSP is pigeonholed to -just- produce HTML. Man, am I glad they cleared that up for me, I must be doing something horrifically wrong, what with outputting XML and WAP, along with HTML, as well as formatted text.
Now - they finally get on to something that Velocity -may- have an advantage in at this point, embedding in other applications. However, this is an implementation issue, not a language/syntax issue. (And in fact, I have been able to embed jasper with relative ease into my applications - yes, you need to gasp *know java* to be able to do it...)
They then move on to some FUD, that because JSP is a 'new' standard it is unstable (and where, pray tell, is velocity's standard? Oh, that's right, its on their TODO list), and feel that the advantage to velocity is that there's only one implementation (as opposed to multiple jsp implementations (which, for the record, I have not had any problem moving code between)).
They then move into a hosting argument, that allowing people you host for to put java into their pages is a bad thing, because they could write something that uses up system memory! (Like, oh, say a CGI...). Of course, because velocity only has foreach, and no for, there's no way to do an 'infinite' looping situation to build up memory (poor, poor, naive developers, give me a day with velocity, and i can probably write something that will throw your server down to the ground performancewise
This document is FULL of FUD, up one side and down the other. And it is a shame, because it looks like velocity may actually have the potential to be useful, but to build their entire argument on a set of horrific misconceptions about jsp development, without trying to -really- understand what's going on... well, that pretty much ensures that it will never be used on any development project I work on. (Sorry, I'd really rather not use a project bourne out of such naivite). This strikes me as a project that was started up because someone spent a day with JSP, got discouraged, and started thinking of other ways to do things - re-inventing all the problems of older CGI/scripting solutions. Yippie. (Gee, what will we see first, an HTML editor that understands JSP or an HTML editor that understands velocity? Hrm....
I'm sure there may be deeper benefits/issues to velocity - this is based soley on this one particular article 'justifying' velocity's existence, and showing all the 'problems' with jsp.
--Dg
It depends on the background of the java developer...
I've found that java developers who come from a heavy c/c++/unix background tend to know what's going on underneath the language -fairly- well, and understand how to do things like work in a debugger, work with a profiller (and interpret the results from said profiler!) - as well as handle a lot of things outside of direct development, i.e. system maintenance, development environment tuning, etc... etc... etc...
I find that developers for whom java is their first programming language, tend to be very weak all the way around. (Then again, i've found that to be true for most developers who are on their 'first programming language').
(I do want to get back into doing regular C++ programming, it's been about 2 years for me, hrm, perhaps its time to re-install that BeOS cd...)
I love it, it means our java developers can concentrate on logic, and our HTML designers only need to learn a small handful of JSP tags, but can concentrate on their display.
For that matter, where do you think C comes from?
Which is why amihotornot came online in October while 'amifuckedornot.com' wasn't registered until november....
I love how time works for you.
Because they were signed a contract for X months of service - and can't just back out without having to pay out that contract, most likely.
The Sun Rays are basically dumb, network attached frame buffers. There is VERY little logic on these things, the network requirements are very high for them, since all audio/video has to be blasted across the network (as opposed to X terminals, which send X events).
They run pretty well, though, the more sun rays you hook up to a server, the beefier your network and servers need to be.
Sun had serious issues with the Sun Ray's at JavaOne last year.
(Man, I wish they still called them corona...)
He never recognizes CD singles as 8%. He recognizes 'non full-length CD sales' as 8%. That 8% includes cassettes, cassingles, single cds, etc... etc... etc...
The particular model i'm setting up with Silent Noise is we're basically a services organization for bands. They contract us to perform services such as CD distribution, promotion, etc... In turn, we get paid for our services out of the sales of CDs and related activities. Without ever dipping into the Band's royalties. So, bands on s/n will be getting their royalties from day one, instead of having to 'pay back'.
There are elements of the business model still being worked on. We'll really only work well with self produced bands (since we aren't acting as a loan organization, for financing recording), and we're bouncing around ideas of co-investing with the bands to cover spin up costs (e.g. getting that first run of CDs done, etc...). But in the end, the band still owns everything.
If you want more info on what Silent Noise is doing, and how we'll be working, feel free to email me at dgarcia@silentnoise.org. I'd be more than happy to answer questions about how we'll be working. Once the website is finished, all that information will be up there as well.
Cheers,
dumbass
The SunRay is basically a framebuffer hooked up to the network. Applications don't get downloaded to the sunray. The only thing that gets downloaded to it is audio and image data.
www.airbornelaser.com - it's kind of funny, and very surreal. I thought it was a joke the first time I saw it, and watching the promo films on there made me think of the opening to Real Genius. Gotta love it...
Let's respond to this one... You're wrong here. Very very wrong here, and ignorant. If you couldn't be bothered to look up what you were blathering about, what right do you have to rip the author of this article?
Let's see, look around the maps site, a little bit, ahhh, here it is... two clicks from the front page...
"Subscription via Multihop eBGP4. This is the oldest (and for a while, the only) mechanism for MAPS RBL usage by third parties (which means anybody other than us)."
Wow, they were doing this before the dns method you were talking about.
In the future, check your facts before spewing them out, in the case of INFORMATIVE, your fingers, or in the case of TROLL, your ass.
What's even dumber is that there's a company out there called mypoints that's been doing this for quite some time (though, granted, you have to actually signup to get the server/mailings, sounds like this guy would use it for spamming).
how to you know that the java code downloaded from netcom is not what activates the server, not some bug in netscapes's own java?
Because, Netscape's own java should NOT allow this server to run. The fact that this server is allowed to run is the bug itself.
I had been under the impression that he had already plead guilty to another set of charges, and in fact, he was serving time for those charges while awaiting trial for others. Perhaps people should check up on these things more? (I'll be the first to admit i'm wrong if someone can document otherwise :)