Slashdot Mirror

What a load of crap...
PHP is an awesome and very useful language...but when it comes to scaling...no way.
Want facts? Go look at PHP Nuke vs JBoss' Nukes. Nukes was a Java rewrite of PHP Nuke. They did it because PHP didn't scale very well at all.
Read about it here: JBoss Nukes
and here
O'Rielly Article on Nukes

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

I put together a small team of people I knew who were also interested in the same general thing, and who were all fleeing like lemmings from the boo.com meltdown, and we thrashed out a rough design and worked out a budget and, issues of funding and business admin aside - sheesh startups - we built a bespoke sattelite reinsurance exchange based on cocoon, tomcat, apache server, outrigger and the jini1.0 stuff. we built it in three layers. the first, as the end result was to be a web app, was in retrospect not dissimilar to apache struts but tied cocoon to the javaspace (you can see more detail on this at O'Reilly's OnJava site) and used xsl to render the pages. The little bit of bespoke code we wrote to shuffle objects between cocoon and the space we dubbed Crudlet and declared it to be open source targeted, and registered crudlet.org. The package name was org.crudlet. The next layer provided the generic b2b exchange and negotiation layer. We called it tennis because it represented a series of exchanges across a net. It too provided very generic functions and so was also open source targeted as org.curdlet.tennis as it builds on crudlet. The final layer contains the actual business knowledge - What is an offer of capacity on M$300 worth of Ariane 5 launch. What's the launch schedule for the next few years etc etc. What's a reinsurer? These things all went into a com.risk2risk package that extended the classes in tennis and crudlet and was considered to be proprietary to the company.

We recruited developers from the various OSS projects we used when we could, and made ot very clear to new recurits how the code layers were structured. We also got complete approval from the Board of Directors to pursue this strategy. The fact that I was one of three like-minded technical directors also helped of course. But we were well outnumbered by the suits who were very sceptical at first. A further project grew out of the team - a kind of javasapce backed version of hibernate or castor - called javastore but it never really went anywhere.

Much of what we open sourced was rapidly superceeded by things like Struts and Hibernate and Karajan (which grew out of crudlet) and when the whole reinsurance industry melted down post Sept 11 2001 and the whole project was put on ice by the investors, the only code that was really iced was the proprietary layer. The developers showed incredible loyalty, committing bug fixes on their very last day of work that kind of thing, and I still keep in touch with many of them.

The business arguments were all around costs. OSS == cheaper. Developers will work for less if they get to keep their code after the project is done. Developers can be excited by things other than money. As long as the basic rate is comfortable for them, and that's always a subjective matter. Sure there are other good reasons for OSS, security, corporate tranparancy and accounability, due dilligence etc, but the bottom line with investors is always the bottom line. Anything else is just woolly for most of these people. Also the ethos of open source permeated the team - everyone worked on the inside of a huge oval shaped ring of desks. lots of power mac g4s running osx, a nice rack with some great hardware in it, a groovy office in soho, cvs servers, a network admin who loved his job. and everyone being paid to write code 90% of which they would get to keep afterwards.

On a point-by-point comparison, .Net frequently is superior to Java.

Didn't Microsoft just take time to clean up their core classes and run-time engine? They took steps to get rid of DLL Hell. I agree that such an undertaking is a big deal, and that MS Marketing confused everyone. But I wonder what would happen if there were an effort to clean up Java.

Bingo.

Don't think that O'Reilly doesn't know this either. Check out how many books, articles, and so forth they have published since OS X came out. I had the privilege a few months ago to have a sit down with the current editor of the Apple books, and from the way he talked it seems that O'Reilly is nothing short of ecstatic about the OS.

O'Reilly, IMHO, publishes by far the best books on the market. This is because they have excellent editors and scouts (for lack of a better word) to find very intelligent, very insightful people to write their books. I suggest people check out there dev sites more often; they are treasure troves of info

The O'Reilly Network

MacDevCenter.com

OnDotNet.com

OnJava.com

OnLamp.com

openp2p.com

osdir.com

Perl.com

XML.com

To put it simply, a servlet container runs java objects that extend the abstract HttpServlet class. At the heart of it, the servlet container will provide you with a HttpRequest, containing the session and any objects stored in it, cookies, request headers, etc., and HttpResponse, which contains a PrintWriter that you can use to output whatever you want. Servlet containers also do things like user authentication and application management. There's quite a lot of configurable options for this stuff.

With J2EE being all the rage these days, there's a lot of inertia behind writing MVC web apps. Writing apps in JSP has nearly the same maintenance hassles as writing them in PHP. Instead of writing a JSP/PHP page that checks that a user is logged in and creates connections to a database, the idea is for JSP to deal with presentation and servlets and java beans to manage the database connections and "business" of the web application.

Some of the cooler (newish) tools that people are using with servlets are XDoclets and object relation persistence

So... take a look around. I strongly suggest checking out the Struts Framework. And this IDE's not bad. And this tool is pretty fun. I mean, I use it...

We are very serious about exploring the open-source route," said Alan Baratz, president of Sun's Java software division, in an interview with Wired News in 1998 !!!!


Also, an Open Source Java Project:
Ant: The Open Source Java Project

Ant: work in progress

JBoss 4.0 DR1 (Developer Release 1) is based on Aspect Oriented Programming.

Check it out!:
Aspect-Oriented Programming and JBoss
JBoss 4.0 Developer Release JBoss
JBoss Aspect Oriented Programming
Download it now!

A good, recent comparison of EJB containers and Java 2 servers is here--

http://www.onjava.com/pub/a/onjava/2003/02/26/ejbi nherit5.html

A comparison of Tomcat, Orion, Resin and Weblogic is here:

http://radio.weblogs.com/0107789/stories/2002/05/2 8/isTomcatCrap.html

Dont' forget Resin EE.... Check out article on Resin: The Instant Application Server by Daniel Solin 09/18/2002 "Imagine a Java Web application server that runs on Unix, delivers incredible performance, is really easy to set up, and inexpensive to boot. Even crazier, imagine that this little app server offers all of the features you expect from a modern Java server, including JSP/servlets, XML/XSL, and EJB/CMP. "

whine whine whine

well SOAP isn't part of the J2EE spec yet, moron. As for compliance, even BEA admits that JBoss is one of the best servers out there if you're looking for standards compliance.

For good reason. There is zero demand for XML web services on the right now, no real support for security, and still-evolving standards.

Oracle ran a Java Pet Store benchmark to compare the performance of Oracle9iAS and the .NET Pet Shop. ... We found that without caching, Oracle9iAS was up to 18 times faster than Microsoft .NET, while using just half the resources. In addition, Oracle was able to scale to a much higher user load on the same hardware. If we compare the same application using Microsoft's output caching and Oracle's Web Cache, the results are even more dramatic. Using Web Cache, Oracle proved to be more than 22 times faster under load, while the middle tier resource utilization was only a small fraction of that consumed by .NET.

In addition to disclosing the results of this benchmark effort in this paper, Oracle is also providing the source code, a description of the environment in which the tests were run, and the test scripts that were used to simulate this environment. The code and test scripts can be downloaded from the Oracle Technology Network.

I read this comparison last November. The author, Dean Wampler, Ph.D., concludes the following:

"The experimental flaws of the Microsoft tests render the performance comparisons unusable. All tests must be run on the same test bed and a more suitable application must be chosen. J2EE and .NET are most appropriate for large-scale, high availability applications. The documented tests say little about how well these frameworks support those applications.

The .NET and Java Pet Stores support the same features, but they implement different "nonfunctional" requirements. The .NET version assumes a single hardware/OS/database combination and makes performance paramount. The Java version supports multiple hardware/OS/database combinations and ranks performance as less important. In fact, both frameworks can support either emphasis. Hence, comparing the two code bases is misleading.

For developers who are comfortable with limited choices, .NET is a well-designed framework with good tools. J2EE provides greater freedom, but the J2EE community can't ignore the need for tools that create powerful and efficient applications in a timely manner."

The Ultimate Linux Bookmark

Here is one response I was able to find outlining the problems with MS's comparison...

The biggest problem is that they didn't re-run the comparison on the same hardware - MS measured .NET performance on a set of intel boxes (not sure of the specs) where the Oracle numbers came from a set of Sun boxes (also don't know those specs).

The other major problem is one I was able to guess right away when a recent MS rep came to talk at our company and told us about the comparison. Basically, the PetStore demo is an educational tool to help teach you how to deploy J2EE code and use various technologies - in no way is it built for speed. Meanwhile MS decided to move all access to data into stored procedures and even skip implementing some of the PetStore features not built around reading data quickly, like administration features (see article).

On top of that, when I asked the rep if the LOC count including the JSP pages, he said yes -so they were including HTML in LOC, which I'm not sure is true of the .NET LOC count.

.NET (+ C# & CLR), dead on arrival with CIOs, my consulting customers and smart developers everywhere. Besides, Borland beat them out the gate with web services, which is a good implementation to boot (as always with Borland development tools). And Java's slant on web services is ramping fast with the help of IBM and other players.

I have heard a number of negative things about JBoss's performance under heavy loads. Anyone with experience using it care to comment? It seems like the clustering would really help such situations, and I am excited to see it advancing as well as it is. ..

i think you will be hard pressed to find a trade show that is meaningful for developers. MOST trade shows are meant to push product, not technology per se.

the best bet is to go to those trade shows for ideas and attend the seminars trying to see a) how the technology could be helpful to your work b) how you could leverage it at your environment.

especially in the java world, you can mostly use the same techniques across differing Java Application Servers (aka Tomcat, Resin) the only time it gets harder is on the differing EJB servers. and even then you can still leverage the similar technologies, the deployment bits are the things that change, not the code.

another HUGE place to get java ideas is online. i use ibm's Developerworks and that has different sections on xml, java, web services. (as well as linux and open source) other good java sites include ONJava and the java publications like Javaworld or the java portal Javaskyline