Slashdot Mirror

SVG is similar in scope to Flash, but it is a W3 recommendation (i.e. a standard) and uses an open format.

SVG is actually much broader in scope than Flash, PDF, or other proprietary formats, as aptly pointed out by Paul Presod at SVG Open 2003.

Furthermore, the XML project of the Apache Software Founcation is hard at work on Batik, a Java-based toolkit for applications or applets that want to use images in the SVG format.

Bonus: All the images in the above galleries are Open Source, unless otherwise stated! (Quite literally, because SVG files are like "source code" for a vector image.)

As for SVG creating and editing software, apart from the new dSVG software announced earlier today on Slashdot, we have:

• Apache Batik for all you Java people. This is a fairly mature library (I believe it's based off the CSIRO library), plus sample apps like a viewer, a rasteriser (i.e. convert to gif, jpeg, etc.), a font converter, and a pretty-printer. Quotage: "With Batik, you can manipulate SVG documents anywhere Java is available. You can also use the various Batik modules to generate, manipulate, transcode and search SVG images in your applications or applets." Batik, according to its test suite, supports all of the static SVG specification (i.e. static images) and some of the dynamic specification (i.e. animations and scripting).

  (Get your easy installable RPMs for Batik, and many other Java projects, at jpackage - but good luck finding a download link that works! Batik 1.5 hadn't propagated to all the Sourceforge mirrors when I tried it last night - so try all the US mirrors, it will be on at least one of them. Also, because of the numerous dependencies, it's recommended to use a smart package manager that can automatically resolve dependencies, like apt-get or urpmi.)

• Sodipodi, [screenshots] a GNOME SVG drawing app, currently at version 0.32. It hosts the open source SVG image gallery linked to above.

• For more, including KDE/Konq support for SVG, see this Wiki page

First off, let me say that I have toyed around with the Corel SmartGraphics Studio, and I think that it's a very good first pass at simplifying the process of creating SVG for a lot of users. As a big fan of SVG, I appreciate all the effort that Corel has put forth.

That being said, I think that the Open Source community should know that dSVG is only one of three UI-defining proposals that the SVG Working Group is considering for SVG 1.2. One of the other two, currently known as RCC, proposes the ability to create a kind of template with a separation of style and functionality, but defined in the document rather than being built in the plug-in. Ultimately, I think that this is a better way to go, since it is far more adaptable. It uses scripting and an XSLT-like syntax to transform semantic content into graphical elements (like form controls, scrollbars, etc.). The last proposal, Live Templates, seems like a generalized case of RCC, and I suspect they could be married together.

Adobe has released a tech preview of ASV6, the next version of their plugin (Windows only for now). It implements an early version of RCC (as well as some other cool features like text wrapping, audio, video, and external resources), and looks very promising. At SVG-Open, I saw an RCC forms widget toolkit for SVG, which worked well and weighed in at all of 6KB. I also saw ASV6pr working on a Linux box, and with the latest build of Mozilla. It's still buggy, but it's more conformant to the Spec than ever.

May the best spec proposal win!

In other news, the excellent Batik (an OSS SVG toolkit) also released a stable 1.5 last week.

Basically, SVG is getting really exciting.

did you read the article?

Let's take your example. You wish to link Xerces into a GPLd program. The Apache 1.1 license is incompatible with the GPL.

Firstly, let's take a look at why this is so. You can read it here. The FSF page says :

This is a permissive non-copyleft free software license with a few requirements that render it incompatible with the GNU GPL.

We urge you not to use the Apache licenses for software you write. However, there is no reason to avoid running programs that have been released under this license, such as Apache.

Exactly what these requirements are is not explicitly stated, but reading the license, it's probably the clause that says:

5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.

When you link your program with Xerces, you are creating a derived work. That's because, your app would not function if Xerces was not present. Exactly what happens in the case of plugins, I do not know.

But let's say you linked it and redistributed it. This would cause problems, primarily because the GPL basically says that you can do anything you like with the software, but you must do FOO if you modify and redistribute a derived work.

Being able to do anything you like, includes the ability to have the word "Apache" in the name. For instance, You may want to use it to load level data for an Apache helicopter simulation using Xerces, nonetheless, you would not be allowed to have the word "Apache" in the title anywhere without written permission from one organization - which may, or may not exist when you write this software.

Obviously in this case, the GPL says you can make any changes you like, including to the title, and the Apache license says you can't. So, by combining them together, you are basically telling people two contradictory things.

It's a slightly contrived example, and the Apache license does not cause great problems. But, as far as I understand it, this sort of thing is what makes licenses incompatible.

PHP is a bit easier for creating web pages. It automates some of the things Perl makes you do for yourself {like grabbing form variables and function parameters} and you don't have to remember to send a MIME type, but

Pick HTML::Mason for doing this and much more with mod_perl and apache

If you do end up blaming the parser, change it! (and i don't mean using a different parsing method as most use a sax parser to generate the tree anyway) there are parsers that are 50% faster than those used as standard (xerces isn't the fastest java parser around!).

I got enormous performance gains by switching from xerces-j to dom4j in one application. I also found its API much more straightforward.

On the other hand, I have run into a few bugs in dom4j -- but it was simple enough to fix them and submit patches.

Weave it with Tapestry:

http://jakarta.apache.org/tapestry

Actually, the general thrust of the blogs mentioned seems to be that Jakarta stuff is one of the few things that IS okay to use. The Apache license is different than the LGPL and GPL and was written with commercial use in mind. Jakarta's FAQ on the license explains this pretty well.

First of all, the people who say that you should simply switch to a structured binary protocol, and get at your messages through casting are right. That'll be a lot faster. But if you're stuck with implementing a WebService then you're stuck with XML.

As for using DOM, I'd argue that you should never use it in a performance critical application. I understand that you need to refer to different parts of the message at concurrently so an event-based parser alone won't work. But what you ought to consider is using a lighter weight representation of your messages than DOM. After all DOM gives you access to alot of information that you really don't need. You might look into XML->object mapping API's like Castor or maybe Betwixt. Or you could just roll your own. That way you could use a quick push parser like SAX to parse the XML, but still have the ability to access all of the message. You might also want to look into the parameters available in your parser, to try and strip it down...maybe turn off validation, DTD's etc...

Contributions to properly registered charities are tax deductible. For example, Apache is a 501c3 charity, so it would qualify for a deduction. Contributions to individuals would be gifts and not qualify. There is no tax deduction for gifts. Large gifts must be reported to the IRS by the giver.

Just to give one current, more or less viable Parrot application that I know of, the virtual machine been embedded as mod_parrot , which can in principle allow you to run Parrot bytecode in Apache. Why would anyone want to write web applications in what amounts to assembly code? Well of course, most people wouldn't, but as Perl6 matures this could become a viable competitor to mod_perl ...and mod_python , mod_tcl , mod_scheme , etc.

More to the point, the development of Parrot has forced a cleanup of the Perl API. The current situation where the reference implementation is the only implementation has never been theoretically clean -- other languages, like Python, C, and Java, have long had multiple implementations, and this has consistently been a healthy thing for the evolution of the language. Abstracting out the virtual machine layer will allow Perl6 to have a pluggable runtime layer (e.g. replace runtime compilation & execution of bytecode into, say, dynamic execution of precompiled bytecode (as Python does), or direct compilation from source to executable machine code (as C does). More recently & concretely, abstracting out the VM layer has been the motivation for Ponie -- an effort to re-implement Perl5 to run on Parrot, and in the process give Perl that abstracted alternate implementation that most other languages have. This will be a very healthy thing, both for Perl5 and for Perl6.

If there has been a dropoff in contributions, it isn't due to Parrot work. Dan Sugalski et al have done excellent work here, and I think most people in the community recognize this. If there has been a dropoff, the much more mundane explanation is probably just the taking economy: a whole lot of people just don't have the spare cash to give these days.

Just to give one current, more or less viable Parrot application that I know of, the virtual machine been embedded as mod_parrot , which can in principle allow you to run Parrot bytecode in Apache. Why would anyone want to write web applications in what amounts to assembly code? Well of course, most people wouldn't, but as Perl6 matures this could become a viable competitor to mod_perl ...and mod_python , mod_tcl , mod_scheme , etc.

More to the point, the development of Parrot has forced a cleanup of the Perl API. The current situation where the reference implementation is the only implementation has never been theoretically clean -- other languages, like Python, C, and Java, have long had multiple implementations, and this has consistently been a healthy thing for the evolution of the language. Abstracting out the virtual machine layer will allow Perl6 to have a pluggable runtime layer (e.g. replace runtime compilation & execution of bytecode into, say, dynamic execution of precompiled bytecode (as Python does), or direct compilation from source to executable machine code (as C does). More recently & concretely, abstracting out the VM layer has been the motivation for Ponie -- an effort to re-implement Perl5 to run on Parrot, and in the process give Perl that abstracted alternate implementation that most other languages have. This will be a very healthy thing, both for Perl5 and for Perl6.

If there has been a dropoff in contributions, it isn't due to Parrot work. Dan Sugalski et al have done excellent work here, and I think most people in the community recognize this. If there has been a dropoff, the much more mundane explanation is probably just the taking economy: a whole lot of people just don't have the spare cash to give these days.

The IDEs do also cater to the business community, probably why you don't see more Perl. The fact is "business software" is usually just glue, and Perl/Python/Java/VB/tcl will always be better glue then C++, because they were DESIGNED to be glue and C++ was designed to be the bricks and mortar.

What I would really like to see in C++ would be compile-time exception enforcement ALA Java. I mean Jesus, when you are trying to work with a class library they can't even document what functions may throw what, how the hell are you supposed to write robust code? In Java this documentation comes for free when you write the function, and is forced to be correct by the compiler.

Though i guess for now it only supports java - but there's nothing preventing you from writing custom tasks for it.

It's called Ant.

Daniel

For modern approaches, you'll have to look outside of the java box. From the language/devel environment that brings us MVC, there's Seaside. Similar continuation-based approach is used more in the Lisp/Scheme community. On java platform, Coccon Control Flow also uses continuation.

I don't believe there's any book on those yet.

This book sounds pretty lame.

First, even the Struts developers themselves consider all but the struts:html tags to be obsoleted by the JSTL (lots of struts newsgroup posts to support this...no time to provide a link). JSTL provides not only a fairly rich set of "nuts and bolts" tags, but more importantly a set of base classes that can be easily extended for custom tags (such as the choose/when/otherwise construct and iterator tags). For Struts, the JSTL expression language has been encorporated into the struts-el tags, included in the latest 1.1 release. ...the caveat is that this approach requires J2EE 1.3 (Tomcat 4.0+, WebSphere 5.0+, Weblogic since forever-ago).

JSTL also obsoletes most of the Jakarta Taglib project's libraries, which frankly were very ugly from the start (separate tags for interacting with session/request/page objects? come on...check out the Expression Language that applies elegance to this problem, and is used in JavaServer Faces, JSTL, Struts-el, and everything useful from here on out).

As for templating engines, the biggest driver towards them has been the lame scriptlet-laden way JSP has historically been used (see The Problem with JSP). JSTL, Struts-el and before long JS Faces nail this problem, and IDE integration in the next year will make clear the reason why Template engines like Velocity aren't compelling (my opinion...not trying to offend).

This book sounds pretty lame.

First, even the Struts developers themselves consider all but the struts:html tags to be obsoleted by the JSTL (lots of struts newsgroup posts to support this...no time to provide a link). JSTL provides not only a fairly rich set of "nuts and bolts" tags, but more importantly a set of base classes that can be easily extended for custom tags (such as the choose/when/otherwise construct and iterator tags). For Struts, the JSTL expression language has been encorporated into the struts-el tags, included in the latest 1.1 release. ...the caveat is that this approach requires J2EE 1.3 (Tomcat 4.0+, WebSphere 5.0+, Weblogic since forever-ago).

JSTL also obsoletes most of the Jakarta Taglib project's libraries, which frankly were very ugly from the start (separate tags for interacting with session/request/page objects? come on...check out the Expression Language that applies elegance to this problem, and is used in JavaServer Faces, JSTL, Struts-el, and everything useful from here on out).

As for templating engines, the biggest driver towards them has been the lame scriptlet-laden way JSP has historically been used (see The Problem with JSP). JSTL, Struts-el and before long JS Faces nail this problem, and IDE integration in the next year will make clear the reason why Template engines like Velocity aren't compelling (my opinion...not trying to offend).

Velocity makes a nice alternative to JSP for the View layer. You can plug it into Struts and use it in place of JSP, or you can embed Velocity into JSP with the Velocity JSP tag.

There's a pretty good user's guide on the Velocity web site if you want to take a look through it.

Forgot the link to Cocoon Cocoon

...so you can have 1 developer using Perl, another using C#. Try that in Java...

Seriously, even when it's just me writing in two languages, the result can be a hideously disorganized mess.

Where I'm working now, I use Java and JSP for most things, and we're trying to migrate shell scripts into Java and Ant tasks. We started out using Python and Zope, but Java seemed more natural for the task at hand.

The factors that drive my workplace decision making are:

• If I'm hit by a bus, how long would it take for someone to figure out what I was doing? Java is highly structured for this, from Javadoc to the hierarchical layout of the source code. Perl and Python are not. C#, from what I've heard, is similar to Java in this regard.
• Does the development environment support best practices? In particular: unit testing, version control, and object/relational mapping. Version control works for any language. Unit testing is arguably best supported by Java, given the breadth of tools and people working on it. I have yet to find an object/relational tool that works as well as NeXT's environment did, though Java is getting there.
• Is code succinct, legible, and well-structured? From the samples I've seen, C# has a better getter/setter grammar, while Java has more succinct documentation grammar.
• Does it run on whatever we have? We have some hardware that requires Sparc. However, most of our servers are x86/Linux-- they're cheap and our admin trusts them to be secureable. .NET obviously fails in this regard.
• How good are the support libraries? Java beats the pants off of everything else I've seen. My pattern is all too often (1) discover I need something (2) write a half-assed implementation (3) discover that the Apache Foundation already has a well-written, well-documented, open source implementation.

Analysis of the quantity of bugs in a software application is by no means a qualitative analysis of the performance of that application.

The predominant httpd servers available on the market today are Apache; iPlanet/SunOne; and IIS. Additionally, there are lesser-known httpd servers (zeus, cern), as well as 'niche' httpd servers (caucho) which typically perform additional functions to parsing HTML code (such as acting as a Java server, etc).

According to Netcraft, Apache is the #1 httpd server in use today, and has been for nearly 7 years.

Regardless of the purported 'quality' provided by commercial, closed-source alternatives, the Apache httpd server is the only solution in the marketplace that supports - in a stable, qualitative fashion - a startling variety of additional software to provide functionality to a website.

A primary example of this bundled flexibility would be the vast number of scripting languages supported by Apache. Java, Perl, PHP, and TCL are all free, stable, and work wonderfully with Apache. This kind of flexibility in application environments is simply unparalleled by the other httpd servers.

You might say that 'you can run java, perl, php, and tcl on iPlanet or IIS, though'. Sure you can. Have you tried that?

First, your commercial vendor won't support it - Microsoft will only support you if you're running ASP.NET et al on IIS; Sun will only support you if you're running Java on iPlanet.

Second, non-supported scripting languages often don't work on non-apache httpd servers. Why? Because the source code for the httpd server isn't available to the scripting language developers - making intelligent integration more difficult - additionally, the major vendors don't test competitive scripting language functionality on their products, meaning that while the writers of PHP, Perl, TCL, etc may offer a version of their product for other httpd servers - Microsoft and Sun aren't testing them on their httpd servers - plus, they aren't guaranteed to work, and often don't. (At my company, we've never been able to get PHP to work correctly under iPlanet - and guess what? Sun doesn't give a shit. Big surprise, huh?).

Commerical httpd servers may indeed have less bugs - but they certainly are not as stable in performance, nor do they support as wide a variety of available software extensions - as Apache.

I'll gladly take that extra .02 in software bugs over a commercial, proprietary httpd server any day.

Analysis of the quantity of bugs in a software application is by no means a qualitative analysis of the performance of that application.

The predominant httpd servers available on the market today are Apache; iPlanet/SunOne; and IIS. Additionally, there are lesser-known httpd servers (zeus, cern), as well as 'niche' httpd servers (caucho) which typically perform additional functions to parsing HTML code (such as acting as a Java server, etc).

According to Netcraft, Apache is the #1 httpd server in use today, and has been for nearly 7 years.

Regardless of the purported 'quality' provided by commercial, closed-source alternatives, the Apache httpd server is the only solution in the marketplace that supports - in a stable, qualitative fashion - a startling variety of additional software to provide functionality to a website.

A primary example of this bundled flexibility would be the vast number of scripting languages supported by Apache. Java, Perl, PHP, and TCL are all free, stable, and work wonderfully with Apache. This kind of flexibility in application environments is simply unparalleled by the other httpd servers.

You might say that 'you can run java, perl, php, and tcl on iPlanet or IIS, though'. Sure you can. Have you tried that?

First, your commercial vendor won't support it - Microsoft will only support you if you're running ASP.NET et al on IIS; Sun will only support you if you're running Java on iPlanet.

Second, non-supported scripting languages often don't work on non-apache httpd servers. Why? Because the source code for the httpd server isn't available to the scripting language developers - making intelligent integration more difficult - additionally, the major vendors don't test competitive scripting language functionality on their products, meaning that while the writers of PHP, Perl, TCL, etc may offer a version of their product for other httpd servers - Microsoft and Sun aren't testing them on their httpd servers - plus, they aren't guaranteed to work, and often don't. (At my company, we've never been able to get PHP to work correctly under iPlanet - and guess what? Sun doesn't give a shit. Big surprise, huh?).

Commerical httpd servers may indeed have less bugs - but they certainly are not as stable in performance, nor do they support as wide a variety of available software extensions - as Apache.

I'll gladly take that extra .02 in software bugs over a commercial, proprietary httpd server any day.

Analysis of the quantity of bugs in a software application is by no means a qualitative analysis of the performance of that application.

The predominant httpd servers available on the market today are Apache; iPlanet/SunOne; and IIS. Additionally, there are lesser-known httpd servers (zeus, cern), as well as 'niche' httpd servers (caucho) which typically perform additional functions to parsing HTML code (such as acting as a Java server, etc).

According to Netcraft, Apache is the #1 httpd server in use today, and has been for nearly 7 years.

Regardless of the purported 'quality' provided by commercial, closed-source alternatives, the Apache httpd server is the only solution in the marketplace that supports - in a stable, qualitative fashion - a startling variety of additional software to provide functionality to a website.

A primary example of this bundled flexibility would be the vast number of scripting languages supported by Apache. Java, Perl, PHP, and TCL are all free, stable, and work wonderfully with Apache. This kind of flexibility in application environments is simply unparalleled by the other httpd servers.

You might say that 'you can run java, perl, php, and tcl on iPlanet or IIS, though'. Sure you can. Have you tried that?

First, your commercial vendor won't support it - Microsoft will only support you if you're running ASP.NET et al on IIS; Sun will only support you if you're running Java on iPlanet.

Second, non-supported scripting languages often don't work on non-apache httpd servers. Why? Because the source code for the httpd server isn't available to the scripting language developers - making intelligent integration more difficult - additionally, the major vendors don't test competitive scripting language functionality on their products, meaning that while the writers of PHP, Perl, TCL, etc may offer a version of their product for other httpd servers - Microsoft and Sun aren't testing them on their httpd servers - plus, they aren't guaranteed to work, and often don't. (At my company, we've never been able to get PHP to work correctly under iPlanet - and guess what? Sun doesn't give a shit. Big surprise, huh?).

Commerical httpd servers may indeed have less bugs - but they certainly are not as stable in performance, nor do they support as wide a variety of available software extensions - as Apache.

I'll gladly take that extra .02 in software bugs over a commercial, proprietary httpd server any day.

Analysis of the quantity of bugs in a software application is by no means a qualitative analysis of the performance of that application.

The predominant httpd servers available on the market today are Apache; iPlanet/SunOne; and IIS. Additionally, there are lesser-known httpd servers (zeus, cern), as well as 'niche' httpd servers (caucho) which typically perform additional functions to parsing HTML code (such as acting as a Java server, etc).

According to Netcraft, Apache is the #1 httpd server in use today, and has been for nearly 7 years.

Regardless of the purported 'quality' provided by commercial, closed-source alternatives, the Apache httpd server is the only solution in the marketplace that supports - in a stable, qualitative fashion - a startling variety of additional software to provide functionality to a website.

A primary example of this bundled flexibility would be the vast number of scripting languages supported by Apache. Java, Perl, PHP, and TCL are all free, stable, and work wonderfully with Apache. This kind of flexibility in application environments is simply unparalleled by the other httpd servers.

You might say that 'you can run java, perl, php, and tcl on iPlanet or IIS, though'. Sure you can. Have you tried that?

First, your commercial vendor won't support it - Microsoft will only support you if you're running ASP.NET et al on IIS; Sun will only support you if you're running Java on iPlanet.

Second, non-supported scripting languages often don't work on non-apache httpd servers. Why? Because the source code for the httpd server isn't available to the scripting language developers - making intelligent integration more difficult - additionally, the major vendors don't test competitive scripting language functionality on their products, meaning that while the writers of PHP, Perl, TCL, etc may offer a version of their product for other httpd servers - Microsoft and Sun aren't testing them on their httpd servers - plus, they aren't guaranteed to work, and often don't. (At my company, we've never been able to get PHP to work correctly under iPlanet - and guess what? Sun doesn't give a shit. Big surprise, huh?).

Commerical httpd servers may indeed have less bugs - but they certainly are not as stable in performance, nor do they support as wide a variety of available software extensions - as Apache.

I'll gladly take that extra .02 in software bugs over a commercial, proprietary httpd server any day.

Analysis of the quantity of bugs in a software application is by no means a qualitative analysis of the performance of that application.

The predominant httpd servers available on the market today are Apache; iPlanet/SunOne; and IIS. Additionally, there are lesser-known httpd servers (zeus, cern), as well as 'niche' httpd servers (caucho) which typically perform additional functions to parsing HTML code (such as acting as a Java server, etc).

According to Netcraft, Apache is the #1 httpd server in use today, and has been for nearly 7 years.

Regardless of the purported 'quality' provided by commercial, closed-source alternatives, the Apache httpd server is the only solution in the marketplace that supports - in a stable, qualitative fashion - a startling variety of additional software to provide functionality to a website.

A primary example of this bundled flexibility would be the vast number of scripting languages supported by Apache. Java, Perl, PHP, and TCL are all free, stable, and work wonderfully with Apache. This kind of flexibility in application environments is simply unparalleled by the other httpd servers.

You might say that 'you can run java, perl, php, and tcl on iPlanet or IIS, though'. Sure you can. Have you tried that?

First, your commercial vendor won't support it - Microsoft will only support you if you're running ASP.NET et al on IIS; Sun will only support you if you're running Java on iPlanet.

Second, non-supported scripting languages often don't work on non-apache httpd servers. Why? Because the source code for the httpd server isn't available to the scripting language developers - making intelligent integration more difficult - additionally, the major vendors don't test competitive scripting language functionality on their products, meaning that while the writers of PHP, Perl, TCL, etc may offer a version of their product for other httpd servers - Microsoft and Sun aren't testing them on their httpd servers - plus, they aren't guaranteed to work, and often don't. (At my company, we've never been able to get PHP to work correctly under iPlanet - and guess what? Sun doesn't give a shit. Big surprise, huh?).

Commerical httpd servers may indeed have less bugs - but they certainly are not as stable in performance, nor do they support as wide a variety of available software extensions - as Apache.

I'll gladly take that extra .02 in software bugs over a commercial, proprietary httpd server any day.

Has Apache 2.1 been released as a stable, non-developmental release?

According to the official site.
The latest 2.* relase is "2.0.46 " and version 2.1 is nowhere to be seen ....

So the question is : Which version did they audit ??

Umm, Apache 2.1 hasn't been released yet. Current latest stable is 2.0.46.

I can only assume that they're looking through the current DEVELOPMENT codebase -- finding a higher ``defect density'' in such a development codebase compared with commercial offerings is not exactly unexpected.

They're also some automated code inspection product; the press release doesn't go into details as to the severity of the defects found or the testing methodology.

It'll be necessary to read through the full report before drawing any sound conclusions.

According to Apache.org, Apache's latest stable version is 2.0.46. Is that a typo on their part, or are they testing a development version? Also, since 1.3.27 is widely used, it would have been interesting to see how that stacked up as well, having been developed longer.

Either way, to have only 31 errors in close to 60,000 lines of code is impressive!

There is alot of confusion around proper code practices. A better discussion is taking place on theserverside.com. Some people are too entrenched to change away from the rdbms centric approach(stored procedures, triggers, etc.). But for the rest of us, I recommend looking into the JCS code which when matched with an OR tool, gives the programmer ideal mapping tools. Apache is working slowly on a fine tool called OJB that will hopefully someday include full JDO support. Let them know you're interested. CMP - Container Managed Persistence BMP - Bean Managed Persistence JDO - Java Database Objects EJB - Enterprise Java Beans Here's a summary of the future for those of you who just want to observe from the gallery. I prefer open source tools personally, so most of the links are for those tools:
EJB is problematic. Most(80% I'm guestimating) of programmers don't understand it but think they do. It is not 'THE' CMP solution, but one of them. Containers give you the ability to do clustering between app servers, which is a good thing. But EJB isn't the only one, compared set against ATG's superior repository API. Scope in EJB is also confusing and most programmers get this wrong, but the mapping is thus: request scope: stateless session bean session scope: statefull session bean global scope: entity bean If you don't understand scope, that is a different issue. But it is necessary for proper app server design to know the difference and use them correctly. JDO is most likely the future. It can or may not use a container. And gets around the flaws of every other mapping tool. Here is a synopsys of their flaws: A better architecture does not alter itself to fit the tools one is using but best fits the problem to be solved. For example, most tools like hibernate and castor suffer from the need to force the bean that is persisted to use public getters and setters. If you want to make your getter and/or setter private, default or protected scope, then you're out of luck. JDO doesn't have this limitation. In many designs, not every column in a table needs to be exposed to calling classes. EJB requires that a persisted bean implement an interface or subclass a parent. This also alters the design, and JDO makes no such requirements. Staying true to the best design to fit the problem, will give you the best return. Naturally, the world is moving away from stored procedures, joins and the like. Yes, really it is, you don't have to like it, just live with it. Although most of the foot dragging is by those who's past history doesn't include multi-threading and good OO design. Perl is a prime contributer here. Although Perl can do in memory object caching, most Perl mongers aren't familiar with it. It's much easier in Java though. But in-memory caching is a must have. That is the key concept behind best java database accessing practices. Using only request scoepd objects is less efficient.
So by next year, JDO will be production ready. Until then use EJB or Cocobase, Castor, Hibernate or the like($) if you must have cluster(multiple app server) support. Otherwise, good old SQL(use a config file to load the SQL statements to avoid embedding) with a BMP design will do quite fine for a single box. Also, design from the object level, and not from the table level. This is heresey to some, but it is a (better)best practice.
Note:
With the release of JDK1.5, the use of external XML configuration files will be reduced or eliminated since source code markup will be added.

There is alot of confusion around proper code practices. A better discussion is taking place on theserverside.com. Some people are too entrenched to change away from the rdbms centric approach(stored procedures, triggers, etc.). But for the rest of us, I recommend looking into the JCS code which when matched with an OR tool, gives the programmer ideal mapping tools. Apache is working slowly on a fine tool called OJB that will hopefully someday include full JDO support. Let them know you're interested. CMP - Container Managed Persistence BMP - Bean Managed Persistence JDO - Java Database Objects EJB - Enterprise Java Beans Here's a summary of the future for those of you who just want to observe from the gallery. I prefer open source tools personally, so most of the links are for those tools:
EJB is problematic. Most(80% I'm guestimating) of programmers don't understand it but think they do. It is not 'THE' CMP solution, but one of them. Containers give you the ability to do clustering between app servers, which is a good thing. But EJB isn't the only one, compared set against ATG's superior repository API. Scope in EJB is also confusing and most programmers get this wrong, but the mapping is thus: request scope: stateless session bean session scope: statefull session bean global scope: entity bean If you don't understand scope, that is a different issue. But it is necessary for proper app server design to know the difference and use them correctly. JDO is most likely the future. It can or may not use a container. And gets around the flaws of every other mapping tool. Here is a synopsys of their flaws: A better architecture does not alter itself to fit the tools one is using but best fits the problem to be solved. For example, most tools like hibernate and castor suffer from the need to force the bean that is persisted to use public getters and setters. If you want to make your getter and/or setter private, default or protected scope, then you're out of luck. JDO doesn't have this limitation. In many designs, not every column in a table needs to be exposed to calling classes. EJB requires that a persisted bean implement an interface or subclass a parent. This also alters the design, and JDO makes no such requirements. Staying true to the best design to fit the problem, will give you the best return. Naturally, the world is moving away from stored procedures, joins and the like. Yes, really it is, you don't have to like it, just live with it. Although most of the foot dragging is by those who's past history doesn't include multi-threading and good OO design. Perl is a prime contributer here. Although Perl can do in memory object caching, most Perl mongers aren't familiar with it. It's much easier in Java though. But in-memory caching is a must have. That is the key concept behind best java database accessing practices. Using only request scoepd objects is less efficient.
So by next year, JDO will be production ready. Until then use EJB or Cocobase, Castor, Hibernate or the like($) if you must have cluster(multiple app server) support. Otherwise, good old SQL(use a config file to load the SQL statements to avoid embedding) with a BMP design will do quite fine for a single box. Also, design from the object level, and not from the table level. This is heresey to some, but it is a (better)best practice.
Note:
With the release of JDK1.5, the use of external XML configuration files will be reduced or eliminated since source code markup will be added.

There is alot of confusion around proper code practices. A better discussion is taking place on theserverside.com. Some people are too entrenched to change away from the rdbms centric approach(stored procedures, triggers, etc.). But for the rest of us, I recommend looking into the JCS code which when matched with an OR tool, gives the programmer ideal mapping tools. Apache is working slowly on a fine tool called OJB that will hopefully someday include full JDO support. Let them know you're interested. CMP - Container Managed Persistence BMP - Bean Managed Persistence JDO - Java Database Objects EJB - Enterprise Java Beans Here's a summary of the future for those of you who just want to observe from the gallery. I prefer open source tools personally, so most of the links are for those tools:
EJB is problematic. Most(80% I'm guestimating) of programmers don't understand it but think they do. It is not 'THE' CMP solution, but one of them. Containers give you the ability to do clustering between app servers, which is a good thing. But EJB isn't the only one, compared set against ATG's superior repository API. Scope in EJB is also confusing and most programmers get this wrong, but the mapping is thus: request scope: stateless session bean session scope: statefull session bean global scope: entity bean If you don't understand scope, that is a different issue. But it is necessary for proper app server design to know the difference and use them correctly. JDO is most likely the future. It can or may not use a container. And gets around the flaws of every other mapping tool. Here is a synopsys of their flaws: A better architecture does not alter itself to fit the tools one is using but best fits the problem to be solved. For example, most tools like hibernate and castor suffer from the need to force the bean that is persisted to use public getters and setters. If you want to make your getter and/or setter private, default or protected scope, then you're out of luck. JDO doesn't have this limitation. In many designs, not every column in a table needs to be exposed to calling classes. EJB requires that a persisted bean implement an interface or subclass a parent. This also alters the design, and JDO makes no such requirements. Staying true to the best design to fit the problem, will give you the best return. Naturally, the world is moving away from stored procedures, joins and the like. Yes, really it is, you don't have to like it, just live with it. Although most of the foot dragging is by those who's past history doesn't include multi-threading and good OO design. Perl is a prime contributer here. Although Perl can do in memory object caching, most Perl mongers aren't familiar with it. It's much easier in Java though. But in-memory caching is a must have. That is the key concept behind best java database accessing practices. Using only request scoepd objects is less efficient.
So by next year, JDO will be production ready. Until then use EJB or Cocobase, Castor, Hibernate or the like($) if you must have cluster(multiple app server) support. Otherwise, good old SQL(use a config file to load the SQL statements to avoid embedding) with a BMP design will do quite fine for a single box. Also, design from the object level, and not from the table level. This is heresey to some, but it is a (better)best practice.
Note:
With the release of JDK1.5, the use of external XML configuration files will be reduced or eliminated since source code markup will be added.

Part of the problem is that people are looking at writing this from scratch, which is a lot of work.

However, in April 2003 the OOo Groupware team and a few Apache James developers discussed building groupware functionality into AJ.

Apache James is already a production ready POP, NNTP and SMTP server, and has partial IMAP support. It is highly componentised, being based upon the Avalon Framework.

Basically, it was determined by OOogw and a few Apache James developers that it was more than pheasible to complete the IMAP support and add iCal and iCAP, plus the necessary authentication modules (LDAP is partly there iirc, and others). This is not a difficult task because most of the foundation work is already done. It's just a matter of implementing the few protocols that are missing.

Sadly it has not been followed up by the OOogw or AJ developers because nobody really has the time - ever the problem with OSS and volunteers. If I were a Java programmer, I would make an attempt, but I'm not.

I guess this post is a feeble attempt to lure some actual Java developers to the cause.

In addition to Webwork, Maverick and Tapestry are often brought up as alternatives to Struts. Roughly, Maverick seems to be more flexible and to be especially well suited to xslt. Tapestry does what Struts does and a whole lot more; it provides a component-based framework similar to Webobjects. All of these frameworks are similar in that they try to implement MVC (Model-View-Controller) and to separate of html from code. They also all require some time to learn and understand which is why it's hard to come up with an answer as to which is best: few people have the time to look at all of them and make a considered judgement. But using any of them is much better than using nothing.

... After a whole 3 seconds of research... Struts homepage

"Welcome to Struts! The goal of this project is to provide an open source framework for building web applications."

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...

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...

I have always wanted PHP to have an XSLT based transformation pipeline, similar to what Apache Cocoon has. I would like to be able to write source documents in XML, arbitrarily transform XML into HTML and PHP, interpret the PHP, possibly transform again and finally output the results. I know I could build this top-down from within a single PHP document, but I'd like this pipeline to be a part of the mod_php distribution, with the .XML file extension mapped to the pipeline processor.

Anyone wanna help me build it?

I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace (as opposed to one URL -- how very un-spider-friendly.

mod_rewrite

JSP? Eeek. Check out Velocity and Turbine.

JSP? Eeek. Check out Velocity and Turbine.

Yeah, me too. But unlike the Mac, I could not run Office, Photoshop, function as a web server, surf the web, compile code
, run bioinformatics searches, do molecular modeling
and have wonderful text aliasing all at the same time.

Effect number two:
A complete j2ee free-speech webserver installation online in under two hours.

Effect number three:
???

Effect number four:
PROFIT! :D
(or at least a major headache in Redmond).

+ + + +
Please note that the Java Community Process controls the standard. Of course Sun is a major player in it, but its standards are published, stable, and you know that your code is still going to work in three years or more. Something that doesn't happen when you code in some strange languages. :)

If anyone is going to make a virtual machine platform which takes the general design of Java, adds 3 opcodes to the platform, removes parts of the core libraries and replaces them with optional APIs and ships the platforms as "Java", Sun is going to sue his ass off.
Sun is already strong on the lawsuit against Microsoft.
Microsoft back then tried to replace java access to native machine features - jni - with a Microsoft proprietary library accessing activex objects, and java remote invocation process - rmi, based on Corba's IOOP - with another library based on COM+...
Sun demonstrated that Microsoft was wrong, and then won the lawsuit... the outcome however (barring the monetary reimbursement part) was ludicrous.

At least now we Java Programmers are programming in REAL JAVA, which works REALLY on different platforms, and not something that remembers unportable C/C++ for the splintering and fragmentation between platforms, compilers and coding styles.

+ + + +
No, I don't want to start a Java vs C/C++ flamewar.
Java is a tool suited for some works.
C/C++ are two other tools suited for other works.

I work at a pretty large .com, one who actually survived the bust and maintains a profit, and has a pretty significant amount of traffic. We have used ATG Dynamo for our application server for several years, partially based upon the built-in ability it has to do an MVC architecture, personalization, pools, and so forth.

However, we just completed a web application that was built using many open source components, including Struts, Validator, JUnit, and others. By using open source components we have completely divorced ourselves from using the proprietary technologies used by Dynamo, and have opened ourselves up to the possibility of using a different, and of course cheaper, application server. This would not have been possible were it not for stable, performant open soruce initiatives.

Not only is management happy because we have (potentially) saved a bunch of money, but the developers are happy because they are much more friendly towards open source than closed technologies; it is far easier to get an answer to a question via Google than it is to pay for and go through the hassle of using a support contract of some kind.

I do not mean to denegrate Dynamo at all, because it is actually a fairly good application server. The licensing costs, however, just cannot be justified when so much of the functionality provided by it is already available elsewhere, for free.

I work at a pretty large .com, one who actually survived the bust and maintains a profit, and has a pretty significant amount of traffic. We have used ATG Dynamo for our application server for several years, partially based upon the built-in ability it has to do an MVC architecture, personalization, pools, and so forth.

However, we just completed a web application that was built using many open source components, including Struts, Validator, JUnit, and others. By using open source components we have completely divorced ourselves from using the proprietary technologies used by Dynamo, and have opened ourselves up to the possibility of using a different, and of course cheaper, application server. This would not have been possible were it not for stable, performant open soruce initiatives.

Not only is management happy because we have (potentially) saved a bunch of money, but the developers are happy because they are much more friendly towards open source than closed technologies; it is far easier to get an answer to a question via Google than it is to pay for and go through the hassle of using a support contract of some kind.

I do not mean to denegrate Dynamo at all, because it is actually a fairly good application server. The licensing costs, however, just cannot be justified when so much of the functionality provided by it is already available elsewhere, for free.

Ah yes, it's 19:29 Groundhog Standard Time and the "C Sharp is a standard platform" post makes its due appearance. And we in turn recite the standard rebuttal, viz:

1. C Sharp the language is a standard, but this counts for little since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.

2. Shared source is not open source, in fact, I doubt if many people here would be willing to accept the terms for looking at Rotor, let alone using it.

3. "Not stood in the way of" (yet) other implementations is a little different from actually supporting them. With the Java Platform, not only are there already multiple vendors and dozens of separate implementations, but the legal permission for their development has been set forth in the JSPA. No equivalent exists for Dotnet whatsoever.

(Yawn. Hope I'm not missing anything good on TV...)

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

To be fair, I'm young as well (I'm 20). Minus a year for college, I've been working as a programmer at my company since the summer of 2000 (with a lot of recreational programming before that).

For the last year, I've been working as a "Software Analyst". I get bug reports that our setup folks can't solve and I solve them. This often requires a lot of code hunting. We've got everything from extremely junky Fortran 77 (no whitespace, no variable names over 6 characters -- and Fortran at that) for our legacy app, and some CGI programs written in spaghetti-code C (with a good mix of HTML templating and javascript thrown in)! Even better, this all runs on HP-UX. Needless to say, I get plenty of practice fielding bad code and weird issues. =)

Our development team is comprised of 12 developers total, and only in the last 4 years has it grown past a four man team. The company is now around 50 heads total, and a QA department is in sight (the Software Analysts will eventually be QA).

Anyway, our newer products are all based on open source tools. PostgreSQL, Apache, Linux, Perl, Mason, ORBit, etc. The source code, mailing lists, IRC, etc. and the open attitude have made things a breeze, not to mention these tools have saved us a very large sum of money in licensing costs.

This is quite possibly the exception to the rule, I have no problem admitting that. Somehow, though, from what I hear of other companies, this isn't all too uncommon.

Cheers

The RIAA shouldn't target me, the person breaking the copyright law! They should target the software which allows me to pirate without even trying.

Okay, then they should target The Apache Foundation for Apache, Microsoft for it's IIS product, AOL/TW for it's AOL Instant Messenger software, basically anybody that makes anything that uses TCP/IP and/or UDP to do file transfers. Which would be pretty much the entire software industry.

Those crooks that make software! Software should be illegal! People shouldn't use computers! We should only have special purpose devices dedicated to viewing content. General purpose computers make pirating too easy.

C'mon...you don't REALLY think that do you?

Microsoft has taken over the Internet? Really? Don't tell these people.