The $3000 price is for instructor-led training, I don't see Red Hat, IBM, etc. offering that for free.
As for the teach yourself route, their online documentation at docs.sun.com is actually pretty good. You could also subscribe to the ACM for a hundred bucks or so, which gets you free access to a bunch of Sun's online training for Solaris, Java, and many of the software packages they're now giving away (see http://pd.acm.org/full_listing2.cfm ).
Tomcat is the Reference Implementation for the Servlet/JSP spec. It is not as fast as many other containers but is in wide use because of this status and the support of the ASF. I would not be surprised if Geronimo reaches the same status within a few years.
If you want free development (and deployment, though w/o clustering), the "platform edition" of Sun's app server is free and has worked well for me so far.
I'll concede that you could generate both local and remote interfaces to a entity bean with a complex primary key, but how many of those have you written? In any case, your IDE will present a single view of the object, you are not going to tackle this with vi (although with XDoclet...).
Caching in this case is a way of avoiding EJB mechanisms
Let's see - if at effectively zero cost I can avoid repeating an operation, that's bad? Obviously! I'll turn off my DNS cache ASAP.
Once again, running the "shopping cart" demo on a 1GHz 512MB box requires approximately 20-30 seconds to generate each page, and doing so causes enormous amounts of disk thrashing.
I somehow manage to develop them on a workstation with half the speed, running an appserver, message queue, and open source rdbms... and I don't have a 20-30 second wait for my pages.
Re:The very worst fashion...
on
Software Fashion
·
· Score: 0, Troll
Where a single class would previously have worked just fine, EJB requires up to seven (!) classes...
Wow, you didn't work hard enough memorizing the anti-Java propaganda sheet. It's seven files, if you count XML descriptors and perhaps a DTO.
And where a simple constructor would previously have served, EJB requires a long JNDI call.
What, can't cache the Home interface? Have you ever written an EJB in your life?
Such a program could otherwise execute quickly on a 286 8MHz, a machine less than 1/1000th as powerful as the one running the EJB. I regularly encounter shops that have huge farms of commodity boxes to run very trivial EJBs that would otherwise execute on a single box just fine.
I've seen.NET code bring an 8-way box to it's knees. That code would execute faster on my digital watch! Uh-huh.
Re:LOL, Struts is right on target.
on
Software Fashion
·
· Score: 1
Struts can be used effectively with edits to one XML file - struts_config.xml
A properties file holds error messages and display text (and allows you to make changes without recompiling code or jsps).
Struts forms are just a simple JavaBean - getFoo / setFoo methods + a single validate() method if you require form validation.
For the price of a few lines of XML and a JavaBean, Struts will validate form data and repopulate the form if the user needs to return to it to fix their input. The minor cost in programming time is well worth it.
Java memory management seems to be a lot like Applesoft Floating Point BASIC. The program would run fine, allocating strings and variables until a garbage collection pass occurred. So, at unpredictable intervals your program would slow to a crawl, and then speed up again.
A concurrent GC option is available and can decrease pause times significantly. The option is -XX:+UseConcMarkSweepGC Parallel GC is also available as an option.
So, with no loss of portability or functionality, you could do the same in C/C++. Which, incidentally, will run on any platform for which GCC exists - About 30 *times* the number of platforms for which a JVM exists.
Of course, all of the libraries on which your code is dependent must also move with the app (database drivers, XML libraries, LDAP/naming services, etc., etc.) and be recompiled, assuming you have source for it all. With Java, you can unzip a Tomcat installation, drop in your app and you are ready to go.
Server-side apps also tend to have very short process lives, doing a small task and exiting. In such situations, JIT causes worse performance, as it wastes time optimizing something that will never execute again during this process' invocation.
Actually, the opposite is true - the server processes are long running and repeat the same code over and over within the same Java VM. You JIT should benefit in this scenario. [ You seem to be thinking of plain-vanilla CGI. ]
You claim to have worked on numerous Java projects, then complain only about GUI apps? The large majority of Java projects are server-side, which is where it really rocks. Write once and deploy on your choice of platform (Linux, Solaris, or Windows if need be).
Here is the example I usually give to people who claim that server-side Java is somehow not cross-platform: I run an IDE on my Windows box, the project files are mounted from a Samba share on a Solaris server. My Windows box compiles the code, the Solaris box runs the development server. We often take the resulting web app and deploy it straight to a Linux box without a recompile. It just works.
Go look at the enormous library of code available from the Apache Jakarta folks. Notice that you won't see "this file is for PC, this one is for Linux, this one is for Solaris" in their download section.
Servlet and JSP code is especially portable. Take the app server you mentioned (JRun): if you develop a J2EE app (JSPs, Servlets, EJBs) using Sun's J2EE reference implementation, you can deploy the file directly to JRun. The *same* application file, no recompile needed. This is true for cross-platform deployment as well.
If you take advantage of server-specific features, it is most likely done through XML config files.
As for Applets breaking on Macs, Apple stopped developing their Java VM after 1.1, so their browsers were hopelessly out of date. They have caught up to Java 1.4 in OSX.
The article is from the Guardian. I don't see it on the Reg site.
While "[t]he chances of a company changing platforms in any given year is very fucking slim", we don't rewrite our apps every year, or every five, and large apps can live forever (witness the COBOL programmers dragged out of retirement for Y2K, etc.). Cross-platform compatibility makes sense.
Also, larger organizations already maintain a mix of servers (Windows/UNIX/Linux) and cross-platform (i.e., non-MS-specific) code allows for flexiblity.
Solaris 8 was a free download for systems with 8 CPUs (IIRC) when it was current.
Solaris 9 is a free license and download for single CPU boxes. It has been free since it was released.
Service contracts for hardware include OS updates. Every sane business will have some sort of service contract for their servers. The prices you see quoted really only kick in if you buy a secondhand box or a clone.
I know that you are probably looking for an open-source solution, but Sun has promised to release a free version of their application server this fall.
Yes, they're free - for MS OSes. Sun has made a commitment to supplying implementations for Solaris, Windows, and Linux. I see a difference here. I believe that MS is making a version of.NET for another platform (BSD?) to make it through the standards body, but I don't imagine we'll see them actually supporting it.
One question I've been left with after reading all of this anti-Java FUD: is there really anything stopping you from implementing a Java compiler and the APIs under an Open Source license? Isn't this what Kaffee was doing?
I had the same thing happen - ordered a mobo and Duron from Micropro, came with the heatsink detached a sheet of paper saying more or less: "the heatsink is attached; if you mess with it, we won't take it back for any reason". I clipped it back on and didn't have any problems (except that I ordered a motherboard with a VIA chipset, which turned out to be a POS).
I've had good luck with ordering complete systems from micropro - my past two and a friend's all arrived intact, well-packed, and worked. But I'm not sure I'd order a mobo-cpu 'combo' from them again.
then ensures that the ssl stuff doesnt work with the non blocking i/o due to the bugs present in java 1.4 which was rushed to the door too early
java.net.ssl is distinct from java.nio.* libraries, and it was known months ago that Sun was not going to provide an SSL nio library. See this article.
Interview from ABC
http://abcnews.go.com/sections/nightline/DailyNe ws/nl_pilot_010405.html
Q: The Chinese are suggesting the U.S. is to blame because our plane turned in such a way to cause the accident. What is your take?
A: I can't imagine a pilot that knew there was a fighter anywhere near them would make a turn like that. We never did, we always made very sure if we could turn away from the fighter we did. If we had to turn into them we always made sure it was a nice gentle turn and often times we would start the turn and stop and then slowly enter it again as a signal to them that he needed to pull away.
Q: Isn't there a certain amount of gamesmanship going on at least in your experience with the Russian pilots?
A: There was. Most times it was a very straight-forward operation. They would come join on us, see that we were the same airplane that was out there the day before probably, and then leave. Every once in awhile they would get a little closer, stay a little longer and on two occasions they did what we call a thumping maneuver ? where they'd come up underneath us and then pop up in front of our nose and put us into their wing tip vertices and their jet wash and bounce the airplane. And one time they bounced so much that the auto pilot kicked off and we started to make a turn that we hadn't planned on and we had to quickly react to that.
Java not only handles unicode but also does code page translation.
For example, I had to port an ASP app that used an Access database with Big5 Chinese data. The web pages it output were also Big5. I used Java to convert the data to UTF8 and loaded it into Postgres. A servlet grabs the UTF8 data from the database, Java stores the data as UTF16 internally, and the servlet produces either Big5 or UTF8 web pages, depending on the user's preference. It only took a couple lines of code to make this happen, because Java can convert from its internal Unicode format to other codepages. I believe that the same applies for other languages (e.g., KOI8 Cyrillic).
Unicode is definitely the standard of the future, and it also allows for easier transfer of data between applications that can't handle CJKV multibyte character sets.
Of course, I don't know Chinese, which made this a fun project:)
It is a solid machine, but not nearly as fast as a comparably priced x86 box. I looked at going the x86 Solaris route, but (1) the hardware options were limited and (2) perfomance was reputed to be awful, despite the higher processor speeds. The unit comes with a standard IDE drive that can be replaced with your choice of brand/size - no special Sun microcode on this thing. Also, the media kit ships with a bunch of goodies - development/trial versions of the various iPlanet(==Netscape) servers and Oracle 8i.
Slashdot Mirror
The $3000 price is for instructor-led training, I don't see Red Hat, IBM, etc. offering that for free.
As for the teach yourself route, their online documentation at docs.sun.com is actually pretty good. You could also subscribe to the ACM for a hundred bucks or so, which gets you free access to a bunch of Sun's online training for Solaris, Java, and many of the software packages they're now giving away (see http://pd.acm.org/full_listing2.cfm ).
Pennsylvania has a state-wide system.
e le ssside.html
http://www.nwfusion.com/supp/government2002/wir
ASF also produces Tomcat!
Tomcat is the Reference Implementation for the Servlet/JSP spec. It is not as fast as many other containers but is in wide use because of this status and the support of the ASF. I would not be surprised if Geronimo reaches the same status within a few years.
If you want free development (and deployment, though w/o clustering), the "platform edition" of Sun's app server is free and has worked well for me so far.
[1] Some (most?) vendors provide migration tools to transition from other containers.
[2] Some (JRun at least) can work with an EAR packaged for the reference implementation.
[3] If you are using an IDE, you will most likely need to fill out an additional properties tab for each bean, but how much work is that?
I'll concede that you could generate both local and remote interfaces to a entity bean with a complex primary key, but how many of those have you written? In any case, your IDE will present a single view of the object, you are not going to tackle this with vi (although with XDoclet...).
... and I don't have a 20-30 second wait for my pages.
Caching in this case is a way of avoiding EJB mechanisms
Let's see - if at effectively zero cost I can avoid repeating an operation, that's bad? Obviously! I'll turn off my DNS cache ASAP.
Once again, running the "shopping cart" demo on a 1GHz 512MB box requires approximately 20-30 seconds to generate each page, and doing so causes enormous amounts of disk thrashing.
I somehow manage to develop them on a workstation with half the speed, running an appserver, message queue, and open source rdbms
Where a single class would previously have worked just fine, EJB requires up to seven (!) classes ...
.NET code bring an 8-way box to it's knees. That code would execute faster on my digital watch! Uh-huh.
Wow, you didn't work hard enough memorizing the anti-Java propaganda sheet. It's seven files, if you count XML descriptors and perhaps a DTO.
And where a simple constructor would previously have served, EJB requires a long JNDI call.
What, can't cache the Home interface? Have you ever written an EJB in your life?
Such a program could otherwise execute quickly on a 286 8MHz, a machine less than 1/1000th as powerful as the one running the EJB. I regularly encounter shops that have huge farms of commodity boxes to run very trivial EJBs that would otherwise execute on a single box just fine.
I've seen
Struts can be used effectively with edits to one XML file - struts_config.xml
A properties file holds error messages and display text (and allows you to make changes without recompiling code or jsps).
Struts forms are just a simple JavaBean - getFoo / setFoo methods + a single validate() method if you require form validation.
For the price of a few lines of XML and a JavaBean, Struts will validate form data and repopulate the form if the user needs to return to it to fix their input. The minor cost in programming time is well worth it.
A concurrent GC option is available and can decrease pause times significantly. The option is -XX:+UseConcMarkSweepGC Parallel GC is also available as an option.
See Tuning Garbage Collection with the 1.4.2 JavaTM Virtual MachineOf course, all of the libraries on which your code is dependent must also move with the app (database drivers, XML libraries, LDAP/naming services, etc., etc.) and be recompiled, assuming you have source for it all. With Java, you can unzip a Tomcat installation, drop in your app and you are ready to go.
Actually, the opposite is true - the server processes are long running and repeat the same code over and over within the same Java VM. You JIT should benefit in this scenario. [ You seem to be thinking of plain-vanilla CGI. ]
You claim to have worked on numerous Java projects, then complain only about GUI apps? The large majority of Java projects are server-side, which is where it really rocks. Write once and deploy on your choice of platform (Linux, Solaris, or Windows if need be).
Wow, the site design looks quite a bit like java.sun.com, down to the color of the sidebar border.
Here is the example I usually give to people who claim that server-side Java is somehow not cross-platform: I run an IDE on my Windows box, the project files are mounted from a Samba share on a Solaris server. My Windows box compiles the code, the Solaris box runs the development server. We often take the resulting web app and deploy it straight to a Linux box without a recompile. It just works.
Go look at the enormous library of code available from the Apache Jakarta folks. Notice that you won't see "this file is for PC, this one is for Linux, this one is for Solaris" in their download section.
Servlet and JSP code is especially portable. Take the app server you mentioned (JRun): if you develop a J2EE app (JSPs, Servlets, EJBs) using Sun's J2EE reference implementation, you can deploy the file directly to JRun. The *same* application file, no recompile needed. This is true for cross-platform deployment as well.
If you take advantage of server-specific features, it is most likely done through XML config files.
As for Applets breaking on Macs, Apple stopped developing their Java VM after 1.1, so their browsers were hopelessly out of date. They have caught up to Java 1.4 in OSX.
The article is from the Guardian. I don't see it on the Reg site.
While "[t]he chances of a company changing platforms in any given year is very fucking slim", we don't rewrite our apps every year, or every five, and large apps can live forever (witness the COBOL programmers dragged out of retirement for Y2K, etc.). Cross-platform compatibility makes sense.
Also, larger organizations already maintain a mix of servers (Windows/UNIX/Linux) and cross-platform (i.e., non-MS-specific) code allows for flexiblity.
Solaris 8 was a free download for systems with 8 CPUs (IIRC) when it was current.
Solaris 9 is a free license and download for single CPU boxes. It has been free since it was released.
Service contracts for hardware include OS updates. Every sane business will have some sort of service contract for their servers. The prices you see quoted really only kick in if you buy a secondhand box or a clone.
They just signed on with Sun for their back-end infrastructure, so UNIX on the desktop might make more sense. Sun press release
Er, interesting comment, since it hasn't been released yet.
From everything I've read, it is definitely targeted at production use.
I know that you are probably looking for an open-source solution, but Sun has promised to release a free version of their application server this fall.
Sun "basic" application server
It will run on Linux.
Yes, they're free - for MS OSes. Sun has made a commitment to supplying implementations for Solaris, Windows, and Linux. I see a difference here. I believe that MS is making a version of .NET for another platform (BSD?) to make it through the standards body, but I don't imagine we'll see them actually supporting it.
One question I've been left with after reading all of this anti-Java FUD: is there really anything stopping you from implementing a Java compiler and the APIs under an Open Source license? Isn't this what Kaffee was doing?
I had the same thing happen - ordered a mobo and Duron from Micropro, came with the heatsink detached a sheet of paper saying more or less: "the heatsink is attached; if you mess with it, we won't take it back for any reason". I clipped it back on and didn't have any problems (except that I ordered a motherboard with a VIA chipset, which turned out to be a POS).
I've had good luck with ordering complete systems from micropro - my past two and a friend's all arrived intact, well-packed, and worked. But I'm not sure I'd order a mobo-cpu 'combo' from them again.
then ensures that the ssl stuff doesnt work with the non blocking i/o due to the bugs present in java 1.4 which was rushed to the door too early
java.net.ssl is distinct from java.nio.* libraries, and it was known months ago that Sun was not going to provide an SSL nio library. See this article.
Hint: it's from last September.
Interview from ABC
e ws /nl_pilot_010405.html
http://abcnews.go.com/sections/nightline/DailyN
Q: The Chinese are suggesting the U.S. is to blame because our plane turned in such a way to cause the accident. What is your take?
A: I can't imagine a pilot that knew there was a fighter anywhere near them would make a turn like that. We never did, we always made very sure if we could turn away from the fighter we did. If we had to turn into them we always made sure it was a nice gentle turn and often times we would start the turn and stop and then slowly enter it again as a signal to them that he needed to pull away.
Q: Isn't there a certain amount of gamesmanship going on at least in your experience with the Russian pilots?
A: There was. Most times it was a very straight-forward operation. They would come join on us, see that we were the same airplane that was out there the day before probably, and then leave. Every once in awhile they would get a little closer, stay a little longer and on two occasions they did what we call a thumping maneuver ? where they'd come up underneath us and then pop up in front of our nose and put us into their wing tip vertices and their jet wash and bounce the airplane. And one time they bounced so much that the auto pilot kicked off and we started to make a turn that we hadn't planned on and we had to quickly react to that.
Java not only handles unicode but also does code page translation.
:)
For example, I had to port an ASP app that used an Access database with Big5 Chinese data. The web pages it output were also Big5. I used Java to convert the data to UTF8 and loaded it into Postgres. A servlet grabs the UTF8 data from the database, Java stores the data as UTF16 internally, and the servlet produces either Big5 or UTF8 web pages, depending on the user's preference. It only took a couple lines of code to make this happen, because Java can convert from its internal Unicode format to other codepages. I believe that the same applies for other languages (e.g., KOI8 Cyrillic).
Unicode is definitely the standard of the future, and it also allows for easier transfer of data between applications that can't handle CJKV multibyte character sets.
Of course, I don't know Chinese, which made this a fun project
Does this mean that the Swedes have nukes?!
Mike