Please, get it right. Sun is the company that has been an ass over this issue, not Microsoft. Microsoft has given us XSL and XML Schemas, both of which are very nice. Sun has fought MS all the way. Sun has acted as bad as MS before the DoJ investigation....
Everything has pretty much been accepted except for XML Schemas. The time for comments for the "final recommendation" will be closed on Dec. 15. Thus, the standard should be out early next year. That said, XML Schemas have been pretty static since April.
XSL and XML Schemas, as implemented by IE, are not quite standard. Of course, both technologies were generously gifted to us from Microsoft, and their implementation was out >2 years before Sun stopped bickering enough to agree that MS' proposals were pretty damned good.
I live in Aberdeen, Scotland. I've had ADSL for a couple of months. Here's my experiences.
I asked about 6 (probably more) people at BT if ADSL were available here. They all said "no", but I had circumstantial evidence to the contray. Well, after basically giving up, I went to a local ISP, Internet For Business (www.ifb.co.uk) to sign up for ISDN instead. Lo and behold! They could offer me ADSL (through BT, of course). Well, I signed on the dotted line (yes, I got a "business" connection), and they regretted to tell me that it would take 5 days to install it! 5 days!!! It took me 32 days in Houston, TX, to get DSL set up! And these guys were apologizing.
I have since had several other positive experiences from IFB. They're a good company, I tell you. And, no, I am in no way affiliated with them.
Well, the moral of the story is don't buy your high-speed internet from regional monopolies. BT sucks. And, if you live in Scotland, I strongly recommend you investigate IFB.
It would be nice to see an implementation of a client using a set of Java classes. If designed properly, these Java classes could then be wrapped in a Swing-based GUI (client-side application) or in a JSP-based tag library (server-side application). The end result would be the same core libraries providing both a client-side app and a server-side app.
If properly designed, this would allow multiple web-based clients--one for WAP, one for HTML + Javascript, one for plain HTML, etc. And client-side Java under JDK1.4 (not out yet--I've seen some alpha-tests) is really quite acceptable. The main advantage, though, is that you'd be using the same core for multiple clients. If you add a feature in the core, all the clients get the feature.
Of course, the client application should also be sufficiently disassociated from the server application, allowing native clients (C++ or C or whatever) as well. But there is a real advantage to having a sample implementation done in Java.
One reason not to use C++: server-side programming. Java outperforms C++ in this instance, due to the per-request startup time incurred in C++. JSPs and Servlets make heavy use of object pooling. For server-side programming, Java kicks the crap out of native languages. Only mod_perl & mod_php handle more requests per minute than JRun, the current servlet engine performance leader.
Compiling the Java source into native bytecode doesn't help. First, you lose all the benefits of server-side Java (the program ends up just like C++ in this instance--no object pooling).
Now, I have no idea what the original author is trying to do. But this response simply doesn't make sense for server-side programming. Generallly, server-side programming is one area that is well suited towards creating large amounts of threads.
One thing the author could try to do is to either run WinNT or Solaris. Both of these OSes have much more effective threading models than the 2.2.x kernels (shudder--WinNT is better at something than Linux!). I'd recommend Solaris, personally. It scales much better to large hardware. And you still get the Unix environment.
Sun also makes a plugin that works with Netscape (under Linux & Windows) and IE (of course, only on windows). This provides a consistant VM across all platforms (except Mac--it's supposed to be coming w/ MacOS X)
I use a laptop for most of my computing. A few years ago, I came across one of those hard, cork-lined placemats used for dinner placemats. This thing is wonderful. It fits inside my laptop bag. When I am at a client site, or in an airport, or whatever, I put the thing on my lap. This is much closer to the proper keyboard height (26" is about right for me) than most desks (29" plus the height of my laptop--about 30" or 31"). I get much less strain in my wrists. And, since the thing is cork-lined, my lap doesn't get too hot.
Of course, this does nothing for putting the monitor at the right height. After 6 years of using a laptop as my primary machine, my neck and back muscles have started to compensate. Not an optimal solution, but it works for me.
Just moved from Houston to Aberdeen. So far, I am finding this entire city devoid of technophiles (only one other Linux user in the SLUG, and no SJUG--Java Users' Group--to speak of).
Drop me some e-mail if you live in Aberdeen. In fact, drop me some e-mail if you live anywhere near Aberdeen. The e-mail address above works, and is checked regularly.
Please e-mail me so we can take this offline. You don't publish your e-mail (I understand that; however, I have no problems pushing "delete" for the 30+ spams I get each day). I'd love to discuss this further.
Oh, to get an adequate feeling of performance of Java, please don't use Netscape's VM. Besides being absolutely buggy, it's also the slowest damn thing on earth. Microsoft's is much better, but there are better JVMs available now from Sun and IBM. Download the latest Java plug-in from Sun if you really want to get a good feeling of Java's performance with applets.
That said, I am not a big fan of applets. I don't really do too much with applets. I feel that either a stand-alone application makes more sense, or moving the entire application server-side makes sense. Applets can be useful for certain things (keeping an app server-side, but getting real-time updates of data, for instance).
I will argue that Java's server-side performance is now competative in speed. However, I agree wholeheartedly that client-side performance is still 1/4 to 1/10 the speed of native code. I simply value my programming time far more than my machine's performance (my 2+ year old PII-450 still serves me fine).
The reason JSPs do well in real terms is that they do object pooling for JSP resources. This means that each subsequent call to a page simply results in the servlet container grabbing a pre-allocated object from the pool and using it. ASP, Cold Fusion, and others don't do this. ASP+ does, and will likely match or exceed JSP & servlet performance (JSPs are servlets--they get compiled into a servlet the first time they are accessed).
Furthermore, object pooling for database resources, among others, is very easy in Java. This is where the benchmark posted on Slashdot a few weeks ago fell down. The benchmark allocated a new database connection each time the page was accessed. It is very difficult to avoid this with server-side technologies that allocate new space on the heap for each request (it can be done, but it is a pain in the butt), whereas it is the default mechanism when using the J2EE javax.sql package.
mod_php and mod_perl can also do object pooling. This is why they outperform JSPs in typical settings (i.e. unless mod_php and mod_perl are poorly set up).
Cold Fusion, ASP, and most other server-side technology make object pooling extremely difficult. For this reason, Microsoft changed the architecture for ASP+, and have borrowed many ideas from JSPs (just like JSPs borrowed many ideas from ASP in the first place).
Here are a few benchmarks. Realize that server-side performance depends not only on the JVM chosen (use HotSpot), but also on the servlet container (JRun and Orion outperform Tomcat, the *reference* implementation, by 3-5x)
http://www.orionserver.com/ (click on benchmarks)
http://www.soft.lv/docs/jsp/jspjgurufaq/jsp_jgur u.htm (there's a line that reads: "Not to anger anybody or wage a war, but we've found that our jsp pages used with these jdbc drivers with pooled connections are way faster than ASP pages.:)" -- the article on slashdot used the JDBC-ODBC bridge, which is an absolute no-no w.r.t. performance for anyone with a clue about Java)
http://www.javaworld.com/jw-02-1998/jw-02-jperf. html (a more general look at performance of Java vs. native code)
http://msdn.microsoft.com/msdn-online/shared/com ments/threadbody.asp?aID=864&collapse=0 (Microsoft's own site--discussion about MTS vs. J2EE discusses Excite.com switching from ASP to JSP and getting "big improvements in throughput")
Our own benchmarks compared mod_perl, mod_php, ASP, JSP, and Cold Fusion for a relatively simple app. We were dynamically pulling content from a database to build pages for a portal that we were building. We tried to be intelligent about the code we wrote. I'm afraid I don't have the exact results, but our observations were that mod_perl was the fastest, mod_php was about 10% slower, JSPs were about 20% slower than mod_perl, and ASP and Cold Fusion were about 1/4 the speed of mod_perl. The rich environment Java gives us in terms of OO development, JSP tag libraries (create your own HTML tags!), and Java's rich built-in libraries made the choice an easy one.
As for client code, most problems I've seen are:
a) running the JVM with too little memory (the heap size is static when starting the JVM, and defaults to 16MB)
b) running Java on a machine w/ too little memory (to avoid swapping, I recommend 64MB or more)
c) using an older JVM (the garbage collection on older JVMs tends to do nothing for long periods of time, then suspends the process for 5 seconds or longer with JVMs that have poor garbage collection implementations--HotSpot's garbage collection is pretty good, as is Microsoft's JVM.
d) writing code ignorant of the fact that garbage collection is automatic (use object pools to avoid garbage collection costs)
About two years ago, I was in charge of re-writing a raster graphics rendering package used to render seismic data. The old code consisted of a C++ library (shared between our C++ and Java libraries) wrapped by a thin Java layer using JNI. The pure-Java code outperformed the wrapped code by about 5-1 (calling native code from Java results in 2 memory copies of the data for each call--once to enter the native code, once to return). Our pure native code (all C++, no Java) was getting about 20 fps at 1280x1024 on a PII-450. Our Java wrappers were getting about 1-2 fps. Our pure Java code was getting about 6-8 fps (jdk1.2.x). The code was reading the data from disk, converting IBM floating point to IEEE floating point (yes, the oil industry still uses IBM FP), interpolating the data, and rasterizing the data. Once the data was cached (we cached data before the interpolation process), the speed doubled. All in all, that is very acceptable performance. This code actually exposed a floating point math bug in the HotSpot compiler that resulted in HotSpot being about 10x slower than jdk1.2.2 at the time--our code was later incorporated into Sun's internal test suite for HotSpot (we were alpha testers of HotSpot). At this company, a colleague of mine uncovered another bug in Sun's implementation of AWT (their windowing code) that resulted in bypassing hardware video acceleration for all graphic copies (like using the scrollbars). This bug fix resulted in Sun's announcement a while back that "client side performance will see performance improvements as much as 8x".
As you can see, Java's performance problems in the early days was greatly hindered by poor implementations. That should be expected with any reasonably young technology. But don't throw the baby out with the bathwater. Java is a good technology. Current implementations are actually quite decent. Server side performance often bests native code. Client side performance can be quite reasonable. And no more seg faults and memory i/o errors. Debugging cycles are reduced to about 1/5 to 1/10 that of native code debugging. And, in the end, my time is far more valuable than my computer's. Besides, Moore's Law helps make everything copasetic (just ask Microsoft--they've taken advantage of this with every subsequent release of their OS and software).
This depends heavily upon the state. Texas, for instance, is a Right to Work state. This means you can leave your job at any time and go work for a competitor. It also means your employer can fire you with little reason. However, employment contracts like this are not legally enforcible in Texas.
Now, if the company pays your moving expenses, which can be quite significant if you're coming from overseas, you can be required to repay your moving expenses. But you certainly won't go to "Immigrant Jail".
Java is a wonderful language. I was a 4-year veteran of C++ when I took up Java 4 years ago. Before that, I had another 4 years professional experience with C. And before that I had 9 years unprofessional experience with Basic, Pascal, Lisp, and Assembler. I have dabbled a bit with Cobol, Fortran, and Perl during my professional career, as well. I can tell you that I am probably on the order of four times more productive in Java than the next closest language (C++) when working on anything but the smallest of projects.
I have done client side and server side Java, and have not had *any* problems porting applications between Linux, BSD, Solaris, HP/UX, Windows, and AIX since JDK1.2.2 (yes, there were some problemsm before that, especially with JDK 1.1.6 and before). The speed for client-side programming is worse than native languages. But, as my degrees and experience have taught me, Moore's Law makes my programming efficiency far more important my computer's efficiency. And bug-free coding (the goal, not the reality) is many times more important than either (Java makes bug-free coding much easier). Server side programming, when taking advantage of the object pooling available to servlets and JSPs (i.e. not writing dumb code, from which the benchmark published in slashdot a few weeks ago suffered) is actually faster than other languages besides mod_php and mod_perl, and is neck-and-neck with those.
If you're judging Java based upon the performance and functionality of the JVM in your browser, or of the JVMs that were available 2 years ago, you're selling Java short. It's a very good language.
Oh, and you can make tons of money coding in it, too. I like money.
Don't forget that two Supreme Court justices will almost definitely step down this term. Both justices are liberal.
ANother two Supreme Court justices are nearing retirement age. One is liberal, one is conservative. I would bet that the liberal one will not step down this term, but the conservative one will.
So, we have a single man in one 4-year term of office selecting 1/3 of the Supreme Court justices, tipping the balance of the courts. In this case, if the election goes to Bush (with 100% of precincts reporting, we're looking at a 900 vote differential), Bush will not only gain the power of the US federal government, but will select 1/3 of another branch of government. It is likely that his choices will result in the reversal of a number of key precedents, including Roe v. Wade (different aspects of this have been upheld 5-4 and 6-3).
As a result, this four year term of the presidency is more important than other elections. And Bush will likely win the election while falling short of Gore in the popular vote by about 300,000 votes. Our political system, with its all-or-nothing approach, will end up giving the minority viewpoint "control" over 2 of the three branches of government. This, to me, reaks of a crisis at a very severe level. And all this was done within the confines of the Constitution.
Now, I do find it odd that Jeb, George's brother, is the governer of Florida. And George's dad used to be head of the CIA. The last time we had an election that was almost this close (1960), there were quiet accusations of voter fraud instigated by the (very powerful) Kennedy family. In the end, Nixon chose not to pursue it. Cronies close to Nixon say his choice came because he did not want to cause a constitutional crisis. I wonder if similar accusations will be made this election, and whether Gore, already the victim of one constitutional crisis (Clinton's impeachment process), will be reserved enough to make the same choice Nixon did.
No foreigner, British included, can own shares in an S corporation. One of my colleagues is British. So we have an LLP holding company, and he owns part of that.
Oops. Forgot to directly address your 3rd question.
I think foreigners can own part of an LLP. So, for that, you can set up an LLP and an S corp. The S corp could hire the foreigner. The foreigner could own part of the LLP. The LLP could then disburse the profits to the foreigner.
That said, this is one issue I'm not too sure on.
And, for matters of taxes and the like, it only matters where the employee physically works. I currently live in the UK, but all my work comes from the States. I have to pay UK taxes instead of US taxes. Likewise, when I was a resident of Texas but worked in Virginia, I had to pay Virginia income tax (Texas has no income tax). I believe this is set up to prevent people like George P Bush from choosing Texas as their resident state, even though he spent the majority of his time in Maine (oops...he got away with it...I guess it pays to be the ex-head of the CIA--you get all kinds of perks!).
First, let me make abundantly clear that IANAL and IANAA (accountant).
C corporations are only benefitial in special circumstances. Foreigners can't own shares in an S corp, but can in a C corp. If you have more than 75 investors, IIRC, then you can't use a C corp, either.
S corps can help you prevent paying FICA. Basically, you end up paying the owners a very small salary. Instead, you get your "pay" in the form of profit disbursements. In this way, it's not subject to FICA.
An LLP is often used as the parent company of an S corp. For the direct owner of a company, it would be a General partenership, not a Limited partnership. These can be used to disburse profits in an S corp when the profits exceed some reasonable amount (if each person expects to make more than, say, $150k per year). Basically, you let the S corp disburse profits up to the $150k per year per employee, then disburse the remainder of the profits to the LLC. Then, the LLC pays the individuals that own it, resulting in more profits w/o FICA withholding.
I don't know much about the benefits/downfalls of partnerships versus corporations. Both help protect the owners from liability. However, I usually see small companies opting for S corps instead of partnerships.
As for the management structure, you can set up a "partnership" (like a law firm or a doctor's practice) using S corps and C corps, too. Whether you're a partnership or a corporation makes no difference in terms of structuring the management of the company. For example, I wanted a partnership for my corporation. That is, people would make "partner" by putting in the years and the hard work, and existing partners could be "bought out" when the leave the corporation--making it easy to add talent to the team, and departing members could get properly reimbursed for their time without selling the entire company. Either a partnership or a corporation would work for this arrangement.
In the end, I created an S corp. If my corp makes more than $150k per year per employee, I'll set up a LLP as a parent company. And I'll pay myself a ridiculously small salary. The rest of my income comes from profit disbursements.
However, as a Java programmer, I take exception to your exhaltation of Netscape and condemning of Microsoft.
The Microsoft JVM included in IE is 10x the VM of the Netscape JVM. The Netscape JVM never worked well. It was slow, buggy, and crashed Netscape more often than it worked.
The IE JVM didn't support JNI (the Sun standard for accessing native code--that is, C, C++, and the like). Other than that, it was pretty decent.
Yes, Microsoft attempted to sabotage the Java platform. But the reason the Java platform sucks inside browsers is much more Netscape's fault than Microsoft's.
One way to stop pathetic arguments like this one is to unionize. The current bargaining system for negotiating salary and terms of employment are slanted too heavily in the corporations' favor. This has happened in a number of industries over a long period of time. One way to effectively deal with it is to unionize.
Comments? I'm an independant contractor, so I have less to gain from unionization. That said, I'd be glad to take a leadership role in the effort. Anyone else?
Slashdot Mirror
Please, get it right. Sun is the company that has been an ass over this issue, not Microsoft. Microsoft has given us XSL and XML Schemas, both of which are very nice. Sun has fought MS all the way. Sun has acted as bad as MS before the DoJ investigation....
Everything has pretty much been accepted except for XML Schemas. The time for comments for the "final recommendation" will be closed on Dec. 15. Thus, the standard should be out early next year. That said, XML Schemas have been pretty static since April.
XSL and XML Schemas, as implemented by IE, are not quite standard. Of course, both technologies were generously gifted to us from Microsoft, and their implementation was out >2 years before Sun stopped bickering enough to agree that MS' proposals were pretty damned good.
I live in Aberdeen, Scotland. I've had ADSL for a couple of months. Here's my experiences.
I asked about 6 (probably more) people at BT if ADSL were available here. They all said "no", but I had circumstantial evidence to the contray. Well, after basically giving up, I went to a local ISP, Internet For Business (www.ifb.co.uk) to sign up for ISDN instead. Lo and behold! They could offer me ADSL (through BT, of course). Well, I signed on the dotted line (yes, I got a "business" connection), and they regretted to tell me that it would take 5 days to install it! 5 days!!! It took me 32 days in Houston, TX, to get DSL set up! And these guys were apologizing.
I have since had several other positive experiences from IFB. They're a good company, I tell you. And, no, I am in no way affiliated with them.
Well, the moral of the story is don't buy your high-speed internet from regional monopolies. BT sucks. And, if you live in Scotland, I strongly recommend you investigate IFB.
Cheers!
Don't forget the Colecovision and the Intellivision. I know I wasted countless hours of my youth on these two...
Write to my e-mail address. It's valid. No changes necessary.
It would be nice to see an implementation of a client using a set of Java classes. If designed properly, these Java classes could then be wrapped in a Swing-based GUI (client-side application) or in a JSP-based tag library (server-side application). The end result would be the same core libraries providing both a client-side app and a server-side app.
If properly designed, this would allow multiple web-based clients--one for WAP, one for HTML + Javascript, one for plain HTML, etc. And client-side Java under JDK1.4 (not out yet--I've seen some alpha-tests) is really quite acceptable. The main advantage, though, is that you'd be using the same core for multiple clients. If you add a feature in the core, all the clients get the feature.
Of course, the client application should also be sufficiently disassociated from the server application, allowing native clients (C++ or C or whatever) as well. But there is a real advantage to having a sample implementation done in Java.
One reason not to use C++: server-side programming. Java outperforms C++ in this instance, due to the per-request startup time incurred in C++. JSPs and Servlets make heavy use of object pooling. For server-side programming, Java kicks the crap out of native languages. Only mod_perl & mod_php handle more requests per minute than JRun, the current servlet engine performance leader.
Compiling the Java source into native bytecode doesn't help. First, you lose all the benefits of server-side Java (the program ends up just like C++ in this instance--no object pooling).
Now, I have no idea what the original author is trying to do. But this response simply doesn't make sense for server-side programming. Generallly, server-side programming is one area that is well suited towards creating large amounts of threads.
One thing the author could try to do is to either run WinNT or Solaris. Both of these OSes have much more effective threading models than the 2.2.x kernels (shudder--WinNT is better at something than Linux!). I'd recommend Solaris, personally. It scales much better to large hardware. And you still get the Unix environment.
YMMV.
What about the Sagem WA 3050? This thing runs WinCE, and is a GSRM phone (3rd gen wireless).
This thing is sleeker, though. But, for raw tech, I think the Sagem at least gives it a run for its money.
Try "applet".
Sun also makes a plugin that works with Netscape (under Linux & Windows) and IE (of course, only on windows). This provides a consistant VM across all platforms (except Mac--it's supposed to be coming w/ MacOS X)
I use a laptop for most of my computing. A few years ago, I came across one of those hard, cork-lined placemats used for dinner placemats. This thing is wonderful. It fits inside my laptop bag. When I am at a client site, or in an airport, or whatever, I put the thing on my lap. This is much closer to the proper keyboard height (26" is about right for me) than most desks (29" plus the height of my laptop--about 30" or 31"). I get much less strain in my wrists. And, since the thing is cork-lined, my lap doesn't get too hot.
Of course, this does nothing for putting the monitor at the right height. After 6 years of using a laptop as my primary machine, my neck and back muscles have started to compensate. Not an optimal solution, but it works for me.
Isn't it obvious? The termites are aliens. They helped us build the pyramids.
Actually, I think "Exebyte" is a company that manufactures 8mm tapes and tape drives. Tee hee!
Just moved from Houston to Aberdeen. So far, I am finding this entire city devoid of technophiles (only one other Linux user in the SLUG, and no SJUG--Java Users' Group--to speak of).
Drop me some e-mail if you live in Aberdeen. In fact, drop me some e-mail if you live anywhere near Aberdeen. The e-mail address above works, and is checked regularly.
Please e-mail me so we can take this offline. You don't publish your e-mail (I understand that; however, I have no problems pushing "delete" for the 30+ spams I get each day). I'd love to discuss this further.
Oh, to get an adequate feeling of performance of Java, please don't use Netscape's VM. Besides being absolutely buggy, it's also the slowest damn thing on earth. Microsoft's is much better, but there are better JVMs available now from Sun and IBM. Download the latest Java plug-in from Sun if you really want to get a good feeling of Java's performance with applets.
That said, I am not a big fan of applets. I don't really do too much with applets. I feel that either a stand-alone application makes more sense, or moving the entire application server-side makes sense. Applets can be useful for certain things (keeping an app server-side, but getting real-time updates of data, for instance).
I will argue that Java's server-side performance is now competative in speed. However, I agree wholeheartedly that client-side performance is still 1/4 to 1/10 the speed of native code. I simply value my programming time far more than my machine's performance (my 2+ year old PII-450 still serves me fine).
The reason JSPs do well in real terms is that they do object pooling for JSP resources. This means that each subsequent call to a page simply results in the servlet container grabbing a pre-allocated object from the pool and using it. ASP, Cold Fusion, and others don't do this. ASP+ does, and will likely match or exceed JSP & servlet performance (JSPs are servlets--they get compiled into a servlet the first time they are accessed).
r u.htm (there's a line that reads: "Not to anger anybody or wage a war, but we've found that our jsp pages used with these jdbc drivers with pooled connections are way faster than ASP pages. :)" -- the article on slashdot used the JDBC-ODBC bridge, which is an absolute no-no w.r.t. performance for anyone with a clue about Java)
. html (a more general look at performance of Java vs. native code)
m ments/threadbody.asp?aID=864&collapse=0 (Microsoft's own site--discussion about MTS vs. J2EE discusses Excite.com switching from ASP to JSP and getting "big improvements in throughput")
Furthermore, object pooling for database resources, among others, is very easy in Java. This is where the benchmark posted on Slashdot a few weeks ago fell down. The benchmark allocated a new database connection each time the page was accessed. It is very difficult to avoid this with server-side technologies that allocate new space on the heap for each request (it can be done, but it is a pain in the butt), whereas it is the default mechanism when using the J2EE javax.sql package.
mod_php and mod_perl can also do object pooling. This is why they outperform JSPs in typical settings (i.e. unless mod_php and mod_perl are poorly set up).
Cold Fusion, ASP, and most other server-side technology make object pooling extremely difficult. For this reason, Microsoft changed the architecture for ASP+, and have borrowed many ideas from JSPs (just like JSPs borrowed many ideas from ASP in the first place).
Here are a few benchmarks. Realize that server-side performance depends not only on the JVM chosen (use HotSpot), but also on the servlet container (JRun and Orion outperform Tomcat, the *reference* implementation, by 3-5x)
http://www.orionserver.com/ (click on benchmarks)
http://www.soft.lv/docs/jsp/jspjgurufaq/jsp_jgu
http://www.javaworld.com/jw-02-1998/jw-02-jperf
http://msdn.microsoft.com/msdn-online/shared/co
Our own benchmarks compared mod_perl, mod_php, ASP, JSP, and Cold Fusion for a relatively simple app. We were dynamically pulling content from a database to build pages for a portal that we were building. We tried to be intelligent about the code we wrote. I'm afraid I don't have the exact results, but our observations were that mod_perl was the fastest, mod_php was about 10% slower, JSPs were about 20% slower than mod_perl, and ASP and Cold Fusion were about 1/4 the speed of mod_perl. The rich environment Java gives us in terms of OO development, JSP tag libraries (create your own HTML tags!), and Java's rich built-in libraries made the choice an easy one.
As for client code, most problems I've seen are:
a) running the JVM with too little memory (the heap size is static when starting the JVM, and defaults to 16MB)
b) running Java on a machine w/ too little memory (to avoid swapping, I recommend 64MB or more)
c) using an older JVM (the garbage collection on older JVMs tends to do nothing for long periods of time, then suspends the process for 5 seconds or longer with JVMs that have poor garbage collection implementations--HotSpot's garbage collection is pretty good, as is Microsoft's JVM.
d) writing code ignorant of the fact that garbage collection is automatic (use object pools to avoid garbage collection costs)
About two years ago, I was in charge of re-writing a raster graphics rendering package used to render seismic data. The old code consisted of a C++ library (shared between our C++ and Java libraries) wrapped by a thin Java layer using JNI. The pure-Java code outperformed the wrapped code by about 5-1 (calling native code from Java results in 2 memory copies of the data for each call--once to enter the native code, once to return). Our pure native code (all C++, no Java) was getting about 20 fps at 1280x1024 on a PII-450. Our Java wrappers were getting about 1-2 fps. Our pure Java code was getting about 6-8 fps (jdk1.2.x). The code was reading the data from disk, converting IBM floating point to IEEE floating point (yes, the oil industry still uses IBM FP), interpolating the data, and rasterizing the data. Once the data was cached (we cached data before the interpolation process), the speed doubled. All in all, that is very acceptable performance. This code actually exposed a floating point math bug in the HotSpot compiler that resulted in HotSpot being about 10x slower than jdk1.2.2 at the time--our code was later incorporated into Sun's internal test suite for HotSpot (we were alpha testers of HotSpot). At this company, a colleague of mine uncovered another bug in Sun's implementation of AWT (their windowing code) that resulted in bypassing hardware video acceleration for all graphic copies (like using the scrollbars). This bug fix resulted in Sun's announcement a while back that "client side performance will see performance improvements as much as 8x".
As you can see, Java's performance problems in the early days was greatly hindered by poor implementations. That should be expected with any reasonably young technology. But don't throw the baby out with the bathwater. Java is a good technology. Current implementations are actually quite decent. Server side performance often bests native code. Client side performance can be quite reasonable. And no more seg faults and memory i/o errors. Debugging cycles are reduced to about 1/5 to 1/10 that of native code debugging. And, in the end, my time is far more valuable than my computer's. Besides, Moore's Law helps make everything copasetic (just ask Microsoft--they've taken advantage of this with every subsequent release of their OS and software).
This depends heavily upon the state. Texas, for instance, is a Right to Work state. This means you can leave your job at any time and go work for a competitor. It also means your employer can fire you with little reason. However, employment contracts like this are not legally enforcible in Texas.
Now, if the company pays your moving expenses, which can be quite significant if you're coming from overseas, you can be required to repay your moving expenses. But you certainly won't go to "Immigrant Jail".
Why? Because you're not one?
Java is a wonderful language. I was a 4-year veteran of C++ when I took up Java 4 years ago. Before that, I had another 4 years professional experience with C. And before that I had 9 years unprofessional experience with Basic, Pascal, Lisp, and Assembler. I have dabbled a bit with Cobol, Fortran, and Perl during my professional career, as well. I can tell you that I am probably on the order of four times more productive in Java than the next closest language (C++) when working on anything but the smallest of projects.
I have done client side and server side Java, and have not had *any* problems porting applications between Linux, BSD, Solaris, HP/UX, Windows, and AIX since JDK1.2.2 (yes, there were some problemsm before that, especially with JDK 1.1.6 and before). The speed for client-side programming is worse than native languages. But, as my degrees and experience have taught me, Moore's Law makes my programming efficiency far more important my computer's efficiency. And bug-free coding (the goal, not the reality) is many times more important than either (Java makes bug-free coding much easier). Server side programming, when taking advantage of the object pooling available to servlets and JSPs (i.e. not writing dumb code, from which the benchmark published in slashdot a few weeks ago suffered) is actually faster than other languages besides mod_php and mod_perl, and is neck-and-neck with those.
If you're judging Java based upon the performance and functionality of the JVM in your browser, or of the JVMs that were available 2 years ago, you're selling Java short. It's a very good language.
Oh, and you can make tons of money coding in it, too. I like money.
Don't forget that two Supreme Court justices will almost definitely step down this term. Both justices are liberal.
ANother two Supreme Court justices are nearing retirement age. One is liberal, one is conservative. I would bet that the liberal one will not step down this term, but the conservative one will.
So, we have a single man in one 4-year term of office selecting 1/3 of the Supreme Court justices, tipping the balance of the courts. In this case, if the election goes to Bush (with 100% of precincts reporting, we're looking at a 900 vote differential), Bush will not only gain the power of the US federal government, but will select 1/3 of another branch of government. It is likely that his choices will result in the reversal of a number of key precedents, including Roe v. Wade (different aspects of this have been upheld 5-4 and 6-3).
As a result, this four year term of the presidency is more important than other elections. And Bush will likely win the election while falling short of Gore in the popular vote by about 300,000 votes. Our political system, with its all-or-nothing approach, will end up giving the minority viewpoint "control" over 2 of the three branches of government. This, to me, reaks of a crisis at a very severe level. And all this was done within the confines of the Constitution.
Now, I do find it odd that Jeb, George's brother, is the governer of Florida. And George's dad used to be head of the CIA. The last time we had an election that was almost this close (1960), there were quiet accusations of voter fraud instigated by the (very powerful) Kennedy family. In the end, Nixon chose not to pursue it. Cronies close to Nixon say his choice came because he did not want to cause a constitutional crisis. I wonder if similar accusations will be made this election, and whether Gore, already the victim of one constitutional crisis (Clinton's impeachment process), will be reserved enough to make the same choice Nixon did.
No foreigner, British included, can own shares in an S corporation. One of my colleagues is British. So we have an LLP holding company, and he owns part of that.
Oops. Forgot to directly address your 3rd question.
I think foreigners can own part of an LLP. So, for that, you can set up an LLP and an S corp. The S corp could hire the foreigner. The foreigner could own part of the LLP. The LLP could then disburse the profits to the foreigner.
That said, this is one issue I'm not too sure on.
And, for matters of taxes and the like, it only matters where the employee physically works. I currently live in the UK, but all my work comes from the States. I have to pay UK taxes instead of US taxes. Likewise, when I was a resident of Texas but worked in Virginia, I had to pay Virginia income tax (Texas has no income tax). I believe this is set up to prevent people like George P Bush from choosing Texas as their resident state, even though he spent the majority of his time in Maine (oops...he got away with it...I guess it pays to be the ex-head of the CIA--you get all kinds of perks!).
First, let me make abundantly clear that IANAL and IANAA (accountant).
C corporations are only benefitial in special circumstances. Foreigners can't own shares in an S corp, but can in a C corp. If you have more than 75 investors, IIRC, then you can't use a C corp, either.
S corps can help you prevent paying FICA. Basically, you end up paying the owners a very small salary. Instead, you get your "pay" in the form of profit disbursements. In this way, it's not subject to FICA.
An LLP is often used as the parent company of an S corp. For the direct owner of a company, it would be a General partenership, not a Limited partnership. These can be used to disburse profits in an S corp when the profits exceed some reasonable amount (if each person expects to make more than, say, $150k per year). Basically, you let the S corp disburse profits up to the $150k per year per employee, then disburse the remainder of the profits to the LLC. Then, the LLC pays the individuals that own it, resulting in more profits w/o FICA withholding.
I don't know much about the benefits/downfalls of partnerships versus corporations. Both help protect the owners from liability. However, I usually see small companies opting for S corps instead of partnerships.
As for the management structure, you can set up a "partnership" (like a law firm or a doctor's practice) using S corps and C corps, too. Whether you're a partnership or a corporation makes no difference in terms of structuring the management of the company. For example, I wanted a partnership for my corporation. That is, people would make "partner" by putting in the years and the hard work, and existing partners could be "bought out" when the leave the corporation--making it easy to add talent to the team, and departing members could get properly reimbursed for their time without selling the entire company. Either a partnership or a corporation would work for this arrangement.
In the end, I created an S corp. If my corp makes more than $150k per year per employee, I'll set up a LLP as a parent company. And I'll pay myself a ridiculously small salary. The rest of my income comes from profit disbursements.
I agree with your general message.
However, as a Java programmer, I take exception to your exhaltation of Netscape and condemning of Microsoft.
The Microsoft JVM included in IE is 10x the VM of the Netscape JVM. The Netscape JVM never worked well. It was slow, buggy, and crashed Netscape more often than it worked.
The IE JVM didn't support JNI (the Sun standard for accessing native code--that is, C, C++, and the like). Other than that, it was pretty decent.
Yes, Microsoft attempted to sabotage the Java platform. But the reason the Java platform sucks inside browsers is much more Netscape's fault than Microsoft's.
One way to stop pathetic arguments like this one is to unionize. The current bargaining system for negotiating salary and terms of employment are slanted too heavily in the corporations' favor. This has happened in a number of industries over a long period of time. One way to effectively deal with it is to unionize.
Comments? I'm an independant contractor, so I have less to gain from unionization. That said, I'd be glad to take a leadership role in the effort. Anyone else?
From their perspective, it doesn't cost any extra to have employees work longer than 40 hours. They're on salary, right?
And baseballs