We use Tomcat pretty extensively over here (major league northeastern university). I have heard that Jetty and Resin are much faster. I have also heard TONS of praise for Resin (faster, easier to configure, deploy, etc.), so you might want to look into that.
That said, Tomcat is perfectly adequate. Unless you are running Ebay or Amazon.com or something, your main bottleneck will probably be your database IO. Typically Tomcat (and any servlet engine, in general) is set up with mod_jk hooked into Apache, so that Apache is the frontend that serves all static files, and *only* those paths which are servlet/jsp get forwarded to Tomcat. In the recent past there seems to have been some flakiness in the Apache->Tomcat connector, but I presume that has been solved by now. Also, until 4.x, the configuration file format, and class loading mechanism were changing each release, but I believe that has settled down.
Like many Apache (or maybe Open Source in general) projects you pay for not having the depth of features a commercial product would, but you get in return breadth of features, and the comfort of a de facto standard with tons of inertia and support behind it. Besides, the J2EE specs are written sufficiently well, that any servlet engine implementation is basically a dime a dozen. You won't lose with going with Tomcat - and you can always switch to a commercial product if/when you feel you need richer/deeper features (I know people who develop on Tomcat, but deploy on Resin).
I must still be naive because I still can't fathom the absolute craptacular $$$,000 amount companies spend on commodity software. Unless there is something you *really* need in a commercial product, it is usually not worth the hassle chaining yourself in.
Make sure what you are doing is legal. In some places, homeschooling more than a certain number of kids together is illegal. Apparently the state wants to prohibit parents working together to educate their kids collectively. Total fascist bullshit.
Uh, how is access to source code (and/or the freedom to modify it) any different from the usual list of product requirements? If propriety software vendors want the business of the government, then they'll provide the features the client wants. I certainly wouldn't want my government procuring military vehicles, for instance, without specification sheets and the ability to repair them, etc.
The details of the source code license can be hammered out seperately, or on a case by case basis, as most features are (e.g., one restriction might be that nobody but the originating company may use the source for commercial profit - which would be fine for gov).
Of course this doesn't need to be legislated as an absolute. IIRC, the Peruvian proposol only says "use open source if there is no better proprietary software that suits the purposes". Nobody is saying "use open source period, end of story, never ever ever ever use proprietary software". That's ridiculous. Where openness of code and protocols and formats is critical, access to source code is just another client requirement.
"Modern Socialism encourages over-breading by burdening the producers of wealth with taxes, and transfering that wealth to the lazy and stupid. The lazy and stupid, for some reason, breed more than normal."
Haha, there couldn't possibly be any correlation between the socioeconomic class of these "lazy and stupid" people and their "over-breading" could there? Maybe you need to reanalyze the causal relation here.
No matter what change you want to effect in the world, ultimately it comes down to the battle of ideas and expressions. If there is no outlet for the ideas you believe in, it doesn't matter where you throw your money because the cause will be stifled, muted, and dwarfed by those in control of the media. So whatever your cause is (uh, well, unless its "maintaining a media monopoly"), you should probably throw some money to decentralized media, grassroots democracy, and watchdog organizations. There is IndyMedia. Democracy Now. Public Citizen. FAIR (Fairness and Accuracy in Reporting). The list goes on... In general, helping putting power back in the hands of the people helps your cause whatever it is (because by deduction, you are part of "the people").
"The Windows server in Windows NT/2K/XP is part of the kernel"
If I remember correctly the "Windows" part of "Windows NT" is simply a "personality" which is hosted under the NT kernel. In the beginning Windows NT wasn't even going to be called "Windows" - it was just "NT". Only part-way through the development of the GUI-agnostic NT kernel, was the Windows personality added on (there was also a short lived OS/2 personality IIRC). So you're statement isn't so accurate. Now perhaps it actually lives in kernel space, or over time has integrated more or less with the kernel proper, but making this claim seems to be a standard "criticism" of NT. For all intents and purposes, operating systems should come with GUIs. I'd be glad if Linux (which is now being pitched as a desktop OS) actually came with real GUI support in the kernel. Or at least shift the video drivers from XFree into the kernel.
It's just a rock. Give her a pebble. It's all the same. If she wants to marry you because of the baubles you can collect and provide her I suggest you tell her to piss off immediately. Or perhaps she can save up her money and get her own fucking shiny rock.
Typical corporate/commercial programming does sort of engender existentialism. I mean, basically you are shifting around little electromagnetic bits. Your craft lies entirely in your head or in some human inaccessible form (at least authors actually have hardcopy). It's hard to feel you *produce* anything. Maybe the solution to the malaise is to find something morally fulfilling to do with your skills, unfortunately most of the more difficult problems in this world will not be solved by computing skills.
Anyhow, it's nice to do something, anything physical. Sometimes I wish I were the groundskeeper outside...at least they *do* something. When they are done they can point at it and see that they have made a physical difference in their surroundings. I guess it's just romanticism. Although if you own a house, you probably have ample opportunity for handiwork. Just the other day it took me about four hours to fix a really old toilet involving two trips to the hardware store because the mechanism was so old. But once I fixed that bitch it felt good. Not like software problems where you fix it and you're like "wow, I spent how long on that stupid shit? because somebody misplaced an operator. yay"
I'll be at the head of the exodus of tech workers become farmers...
ok, I believe you, but only because you rationaly explained it was a "special case". Hey, maybe this speed of light being slower is just a "special case".
"The proposal is being considered no doubt in response to fears like that of MPAA head Jack Valenti who has said that without proper security measures, the industry won't allow its movies to be broadcast because they don't want viewers to record 'perfect copies' of movies."
Fine by me. Keep your mits off my hardware and I promise I won't view any of your pathetic drivel.
"I always wondered why Sun didn't make compilers for the most common OS'es."
Maybe because they already burn lots of money giving Java away for free to ungrateful people who then go and build an industry on it. Sheesh. Write your own native compiler for <your favorite CPU>. Or use GCJ. Or use.NET.
10. Delete all deprecated methods, fields, classes, and interfaces.
While I would also like to see these die, to tell the truth, Java has done an above average job here. In most other (should I qualify that as "practical") languages, there isn't even a concept of deprecated. Deprecated is your client calling you up and telling you something is breaking in a weird way and you say "oh yeah, don't use that". In Java when you deprecate something it means something. The compiler compiles in a flag, and anything that is built against deprecated methods, the compiler will spit out a big fat "THIS IS DEPRECATED" warning. You can't do much better than that. So while I'd like to see these things gone, the reality is that there is a lot of code that is using them, and they really aren't doing much harm. The most "harmful" are the deprecated thread operations. Everything else has mostly been for name changes or additional functionality. Take the most out of your own eye first and all... This is just a library issue, not a language issue.
9. Fix incorrect naming conventions.
Amen. Given that we adhere to whatever we resolve to do with deprecations, fine. But again, Sun has done a terrific job, and if you look through the libraries, I'd say 90% or greater (including deprecated stuff) adheres pretty well to the standard. Again, this is just a library issue, not a language issue.
Meh. I don't use Unicode that much, so it's not as relevant to me, I'll trust you on this one. Just don't bloat up good ole US-ASCII character strings.
6. Fix threads.
I generally agree. The first 5 bullets are pretty trivial. I have never ever run into a problem when using threads, even with complicated synchronization implementations. The last bullet is already possible: write your own damn monitor! Nobody is stopping you as long as the sychronization primitives work. Here I'll give you a clue: custom monitor implementations. Easy as cake. I'm not sure what the author is really asking for here. Sun cannot possibly make every single implementation of a monitor somebody would like (ok, well, it *could* but why?). It gives you the primitives and you go from there. That is why you are a programmer.
5. Convert file formats to XML.
No no no no no no NO. XML is not a panacea. Please DON'T turn everything into XML. The formats that exist (properties format, manifest format) are simple and designed for their purpose. XML has its uses, and simple, flat, non-hierarchical, terse data, which has absolutely no expectation of being rendered visually or translated into another form, is not one of them. I don't see any REASON being proposed other than "everybody is using it". Well, if everybody jumped off a bridge...
4. Ditch the AWT.
Meh. I have a better one. Replace AWT with a natively back-ended Swing or Swing-like API, akin to IBM's SWT. Swing is a lovely API, but it is cumbersome to lug all the libraries around, and it is slow. SWT is a nice compromise (nice high-level abstract, generic, Java API - to the metal native implementation).
3. Rationalize the collections.
This is basically an argument against the deprecated classes, for which there are already replacements. I don't see much wrong with the Collections API (i.e. java.util 1.2+), and when generics arrive, it will be much more useful (no tedious subclassing or casting to contained type). The author is making some fuzzy argument that the Collections APIis not cuddly enough or something. It's a starting point - it has the most used structures (hashtable, linked list, growable array, etc.). If you don't like them, feel free to subclass or write your own. They are fine for me, and certainly don't rank up at 3 as far as complaints to Sun go.
2. Redesigned I/O
A bunch of non-arguments here. Again, for something like 90% of the time, this is going to do you just fine. Please DON'T sneak buffering into classes which do not announce this fact. This is the charm of composition, and I think it works nicely. Want a stream buffered? Wrap it with a buffering stream. Want a stream GZipped? Wrap it with a GZip*Stream. Anyway, there IS a new IO API, which promises much better performance (introduces asynchronous I/O), java.nio.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Agreed. This is getting to be a headache. Especially when deploying in application servers/servlet engines that have their own custom classloaders. There probably isn't a good solution other than good documentation, and reduction of unnecessary conflicts when security is obviously not an issue (the whole reason of seperate classloaders to begin with).
Summing Up
Well, this article is largely gripes about the library not the language, and where it gripes about the language, those gripes are already being addressed. I would complain about things like, methods not being first-class objects (callback classes are really annoying), unspecified symbol resolution in the language spec, inner classes not being allowed to have static declarations, lack of enumeration type in the language itself, interfaces unable to declare overridable fields, array types being pseudo objects when they could instead be easily made to be real objects which could be subclassed, etc.
If you have another second to waste on Slashdot, would you mind writing a short laymans explanation of the significance of these two items with regard to the conception of "god". From what I glean from Godel's incompleteness theorem, it seems to indicate there may indeed be things that are "unknowable" or at least "unable to be derived from any given set of knowledge". As I understand it, calculus itself was one of these "non-derived" fields...something that just sprang from Newton's head, but was not "derived from" any other mathematics. I am a weak atheist, empirical agnostic, and Godel's incompleteness theorem to me means that there may be "truths" in this universe that are not obtainable by mere reasoning/rational thought alone, which leaves a tiny niche for the possibility of some notion of "god" or at least something "supernatural". So then, how does the Church-Turing thesis or Reimann Zeta function (sorry, I'm not a mathematician, I have no idea what this is:( ) apply?
"If you think you are oppressed by Microsoft, then I suggest you go study some history and learn what real oppression is all about."
I'll get right to it. After my next paycheck I'll be able to download one hour's worth or 100 pages (whichever occurs first) of Official Microsoft Palladium Certified History Of The World on my MS Lemming PDA. I better make sure nobody is reading over my shoulder or that I draw anti-establishment conclusions from history!
Agreed. The issue is whether by "avoiding" assenting to the GLP/, can one exploit some sort of loop hole. Let's say you buy a Red Hat box, but don't view and agree to the license terms. This wouldn't mean you could then redistribute the source code (because that would be a violation of plain old copyright - since you haven't assented to the GPL you don't have the EXTRA right to distribute source), but would it mean you could distribute binaries (without source)? Binaries are derived from source, but since you produced them yourself, they are not "copies" of any Red Hat copyrighted material. And since you didn't agree to the license, it seems you would be able to redistribute the binaries without the source.
There are two orthogonal things going on here:
The ability to use a product you *purchased* regardless of the license on it.
The ability of an agreed-to license giving you extra rights.
We would like to have both in effect (being able to use proprietary software without agreeing to some draconian privacy-invading license, and being able to hold up the legal strength of the GPL). Somewhere between the two there seems to be a hole by exploiting one (use of licensed software) and relinquishing the other (extra rights granted by license).
It's still true. Although JSDK 1.4 has now introduced the 'assert' keyword, and a command line flag to toggle assertions on or off (so presumably when they are off there is no performance penalty). Granted 'assert' is far from a full fledged logging framework. Actually I think log4j is adequate for large projects which generate lots of types of volume of logging, but for small and medium projects, log4j is a bit unweildy.
Slashdot Mirror
Yeah, you don't need a modem, just leave the phone nearby...
Bellbottoms are coming back. 'Nuff said.
Actually the sun does go around the earth. In fact, the whole universe spins around the earth. ;)
Isn't that called FreeNet?
"Would that tool alleviate this problem?"
a nager-howto.html
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/m
"If we need to deploy a new context, then restarting tomcat brings with it a 30-45 second outage."
Remember, in 4.x, a command-line admin tool to insert/reload contexts at runtime has been added. A GUI is planned to follow.
We use Tomcat pretty extensively over here (major league northeastern university). I have heard that Jetty and Resin are much faster. I have also heard TONS of praise for Resin (faster, easier to configure, deploy, etc.), so you might want to look into that.
That said, Tomcat is perfectly adequate. Unless you are running Ebay or Amazon.com or something, your main bottleneck will probably be your database IO. Typically Tomcat (and any servlet engine, in general) is set up with mod_jk hooked into Apache, so that Apache is the frontend that serves all static files, and *only* those paths which are servlet/jsp get forwarded to Tomcat. In the recent past there seems to have been some flakiness in the Apache->Tomcat connector, but I presume that has been solved by now. Also, until 4.x, the configuration file format, and class loading mechanism were changing each release, but I believe that has settled down.
Like many Apache (or maybe Open Source in general) projects you pay for not having the depth of features a commercial product would, but you get in return breadth of features, and the comfort of a de facto standard with tons of inertia and support behind it. Besides, the J2EE specs are written sufficiently well, that any servlet engine implementation is basically a dime a dozen. You won't lose with going with Tomcat - and you can always switch to a commercial product if/when you feel you need richer/deeper features (I know people who develop on Tomcat, but deploy on Resin).
I must still be naive because I still can't fathom the absolute craptacular $$$,000 amount companies spend on commodity software. Unless there is something you *really* need in a commercial product, it is usually not worth the hassle chaining yourself in.
Make sure what you are doing is legal. In some places, homeschooling more than a certain number of kids together is illegal. Apparently the state wants to prohibit parents working together to educate their kids collectively. Total fascist bullshit.
Uh, how is access to source code (and/or the freedom to modify it) any different from the usual list of product requirements? If propriety software vendors want the business of the government, then they'll provide the features the client wants. I certainly wouldn't want my government procuring military vehicles, for instance, without specification sheets and the ability to repair them, etc.
The details of the source code license can be hammered out seperately, or on a case by case basis, as most features are (e.g., one restriction might be that nobody but the originating company may use the source for commercial profit - which would be fine for gov).
Of course this doesn't need to be legislated as an absolute. IIRC, the Peruvian proposol only says "use open source if there is no better proprietary software that suits the purposes". Nobody is saying "use open source period, end of story, never ever ever ever use proprietary software". That's ridiculous. Where openness of code and protocols and formats is critical, access to source code is just another client requirement.
"Modern Socialism encourages over-breading by burdening the producers of wealth with taxes, and transfering that wealth to the lazy and stupid. The lazy and stupid, for some reason, breed more than normal."
Haha, there couldn't possibly be any correlation between the socioeconomic class of these "lazy and stupid" people and their "over-breading" could there? Maybe you need to reanalyze the causal relation here.
No matter what change you want to effect in the world, ultimately it comes down to the battle of ideas and expressions. If there is no outlet for the ideas you believe in, it doesn't matter where you throw your money because the cause will be stifled, muted, and dwarfed by those in control of the media. So whatever your cause is (uh, well, unless its "maintaining a media monopoly"), you should probably throw some money to decentralized media, grassroots democracy, and watchdog organizations. There is IndyMedia. Democracy Now. Public Citizen. FAIR (Fairness and Accuracy in Reporting). The list goes on... In general, helping putting power back in the hands of the people helps your cause whatever it is (because by deduction, you are part of "the people").
"The Windows server in Windows NT/2K/XP is part of the kernel"
If I remember correctly the "Windows" part of "Windows NT" is simply a "personality" which is hosted under the NT kernel. In the beginning Windows NT wasn't even going to be called "Windows" - it was just "NT". Only part-way through the development of the GUI-agnostic NT kernel, was the Windows personality added on (there was also a short lived OS/2 personality IIRC). So you're statement isn't so accurate. Now perhaps it actually lives in kernel space, or over time has integrated more or less with the kernel proper, but making this claim seems to be a standard "criticism" of NT. For all intents and purposes, operating systems should come with GUIs. I'd be glad if Linux (which is now being pitched as a desktop OS) actually came with real GUI support in the kernel. Or at least shift the video drivers from XFree into the kernel.
"Could the city be rebuilt if destroyed? Should it?"
Naw, just build a layer on top of it and leave the old ruined city underground for the mutants...
"And try to keep to the Hillary Rosen, DMCA references to topic that's actually on that subject"
The point you seemed to miss is that you don't ask the plaintiff whether a certain behavior is a crime, because obviously they believe it is.
It's just a rock. Give her a pebble. It's all the same. If she wants to marry you because of the baubles you can collect and provide her I suggest you tell her to piss off immediately. Or perhaps she can save up her money and get her own fucking shiny rock.
Typical corporate/commercial programming does sort of engender existentialism. I mean, basically you are shifting around little electromagnetic bits. Your craft lies entirely in your head or in some human inaccessible form (at least authors actually have hardcopy). It's hard to feel you *produce* anything. Maybe the solution to the malaise is to find something morally fulfilling to do with your skills, unfortunately most of the more difficult problems in this world will not be solved by computing skills.
Anyhow, it's nice to do something, anything physical. Sometimes I wish I were the groundskeeper outside...at least they *do* something. When they are done they can point at it and see that they have made a physical difference in their surroundings. I guess it's just romanticism. Although if you own a house, you probably have ample opportunity for handiwork. Just the other day it took me about four hours to fix a really old toilet involving two trips to the hardware store because the mechanism was so old. But once I fixed that bitch it felt good. Not like software problems where you fix it and you're like "wow, I spent how long on that stupid shit? because somebody misplaced an operator. yay"
I'll be at the head of the exodus of tech workers become farmers...
That's less funny if you replace "back child support" for "estimated movie/music piracy".
ok, I believe you, but only because you rationaly explained it was a "special case". Hey, maybe this speed of light being slower is just a "special case".
"The proposal is being considered no doubt in response to fears like that of MPAA head Jack Valenti who has said that without proper security measures, the industry won't allow its movies to be broadcast because they don't want viewers to record 'perfect copies' of movies."
Fine by me. Keep your mits off my hardware and I promise I won't view any of your pathetic drivel.
"I always wondered why Sun didn't make compilers for the most common OS'es."
.NET.
Maybe because they already burn lots of money giving Java away for free to ungrateful people who then go and build an industry on it. Sheesh. Write your own native compiler for <your favorite CPU>. Or use GCJ. Or use
10. Delete all deprecated methods, fields, classes, and interfaces.
While I would also like to see these die, to tell the truth, Java has done an above average job here. In most other (should I qualify that as "practical") languages, there isn't even a concept of deprecated. Deprecated is your client calling you up and telling you something is breaking in a weird way and you say "oh yeah, don't use that". In Java when you deprecate something it means something. The compiler compiles in a flag, and anything that is built against deprecated methods, the compiler will spit out a big fat "THIS IS DEPRECATED" warning. You can't do much better than that. So while I'd like to see these things gone, the reality is that there is a lot of code that is using them, and they really aren't doing much harm. The most "harmful" are the deprecated thread operations. Everything else has mostly been for name changes or additional functionality. Take the most out of your own eye first and all...
This is just a library issue, not a language issue.
9. Fix incorrect naming conventions.
Amen. Given that we adhere to whatever we resolve to do with deprecations, fine. But again, Sun has done a terrific job, and if you look through the libraries, I'd say 90% or greater (including deprecated stuff) adheres pretty well to the standard. Again, this is just a library issue, not a language issue.
8. Eliminate primitive data types.
What you want is "boxing" (like C#/.NET/CLR does), and they're already working on it: RFE 4609038 Request auto boxing of primitives in Java.
7. Extend chars to four bytes.
Meh. I don't use Unicode that much, so it's not as relevant to me, I'll trust you on this one. Just don't bloat up good ole US-ASCII character strings.
6. Fix threads.
I generally agree. The first 5 bullets are pretty trivial. I have never ever run into a problem when using threads, even with complicated synchronization implementations. The last bullet is already possible: write your own damn monitor! Nobody is stopping you as long as the sychronization primitives work. Here I'll give you a clue: custom monitor implementations. Easy as cake. I'm not sure what the author is really asking for here. Sun cannot possibly make every single implementation of a monitor somebody would like (ok, well, it *could* but why?). It gives you the primitives and you go from there. That is why you are a programmer.
5. Convert file formats to XML.
No no no no no no NO. XML is not a panacea. Please DON'T turn everything into XML. The formats that exist (properties format, manifest format) are simple and designed for their purpose. XML has its uses, and simple, flat, non-hierarchical, terse data, which has absolutely no expectation of being rendered visually or translated into another form, is not one of them. I don't see any REASON being proposed other than "everybody is using it". Well, if everybody jumped off a bridge...
4. Ditch the AWT.
Meh. I have a better one. Replace AWT with a natively back-ended Swing or Swing-like API, akin to IBM's SWT. Swing is a lovely API, but it is cumbersome to lug all the libraries around, and it is slow. SWT is a nice compromise (nice high-level abstract, generic, Java API - to the metal native implementation).
3. Rationalize the collections.
This is basically an argument against the deprecated classes, for which there are already replacements. I don't see much wrong with the Collections API (i.e. java.util 1.2+), and when generics arrive, it will be much more useful (no tedious subclassing or casting to contained type). The author is making some fuzzy argument that the Collections APIis not cuddly enough or something. It's a starting point - it has the most used structures (hashtable, linked list, growable array, etc.). If you don't like them, feel free to subclass or write your own. They are fine for me, and certainly don't rank up at 3 as far as complaints to Sun go.
2. Redesigned I/O
A bunch of non-arguments here. Again, for something like 90% of the time, this is going to do you just fine. Please DON'T sneak buffering into classes which do not announce this fact. This is the charm of composition, and I think it works nicely. Want a stream buffered? Wrap it with a buffering stream. Want a stream GZipped? Wrap it with a GZip*Stream. Anyway, there IS a new IO API, which promises much better performance (introduces asynchronous I/O), java.nio.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Agreed. This is getting to be a headache. Especially when deploying in application servers/servlet engines that have their own custom classloaders. There probably isn't a good solution other than good documentation, and reduction of unnecessary conflicts when security is obviously not an issue (the whole reason of seperate classloaders to begin with).
Summing Up
Well, this article is largely gripes about the library not the language, and where it gripes about the language, those gripes are already being addressed. I would complain about things like, methods not being first-class objects (callback classes are really annoying), unspecified symbol resolution in the language spec, inner classes not being allowed to have static declarations, lack of enumeration type in the language itself, interfaces unable to declare overridable fields, array types being pseudo objects when they could instead be easily made to be real objects which could be subclassed, etc.
If you have another second to waste on Slashdot, would you mind writing a short laymans explanation of the significance of these two items with regard to the conception of "god". From what I glean from Godel's incompleteness theorem, it seems to indicate there may indeed be things that are "unknowable" or at least "unable to be derived from any given set of knowledge". As I understand it, calculus itself was one of these "non-derived" fields...something that just sprang from Newton's head, but was not "derived from" any other mathematics. I am a weak atheist, empirical agnostic, and Godel's incompleteness theorem to me means that there may be "truths" in this universe that are not obtainable by mere reasoning/rational thought alone, which leaves a tiny niche for the possibility of some notion of "god" or at least something "supernatural". So then, how does the Church-Turing thesis or Reimann Zeta function (sorry, I'm not a mathematician, I have no idea what this is :( ) apply?
"If you think you are oppressed by Microsoft, then I suggest you go study some history and learn what real oppression is all about."
I'll get right to it. After my next paycheck I'll be able to download one hour's worth or 100 pages (whichever occurs first) of Official Microsoft Palladium Certified History Of The World on my MS Lemming PDA. I better make sure nobody is reading over my shoulder or that I draw anti-establishment conclusions from history!
Agreed. The issue is whether by "avoiding" assenting to the GLP/, can one exploit some sort of loop hole. Let's say you buy a Red Hat box, but don't view and agree to the license terms. This wouldn't mean you could then redistribute the source code (because that would be a violation of plain old copyright - since you haven't assented to the GPL you don't have the EXTRA right to distribute source), but would it mean you could distribute binaries (without source)? Binaries are derived from source, but since you produced them yourself, they are not "copies" of any Red Hat copyrighted material. And since you didn't agree to the license, it seems you would be able to redistribute the binaries without the source.
There are two orthogonal things going on here:
The ability to use a product you *purchased* regardless of the license on it.
The ability of an agreed-to license giving you extra rights.
We would like to have both in effect (being able to use proprietary software without agreeing to some draconian privacy-invading license, and being able to hold up the legal strength of the GPL). Somewhere between the two there seems to be a hole by exploiting one (use of licensed software) and relinquishing the other (extra rights granted by license).
It's still true. Although JSDK 1.4 has now introduced the 'assert' keyword, and a command line flag to toggle assertions on or off (so presumably when they are off there is no performance penalty). Granted 'assert' is far from a full fledged logging framework. Actually I think log4j is adequate for large projects which generate lots of types of volume of logging, but for small and medium projects, log4j is a bit unweildy.