on 6/20/01 2:33 PM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote: > I have been looking through JDK 1.4, and there are a few > instances where what is included in the JDK steps on some > of our projects. Most notably: This is a problem that I have been trying to wrap my head around for a number of years now. The issue is that what happens to code you write that is instantly obsolete by features added to the JDK distribution? Turbine has this problem in a great degree. For example, we wrote a JDBC Connection pool about 3 years ago. Now, JDBC has an interface and whole system for creating a Connection pool. Personally, I think that it's implementation is bad OO design because they overloaded the use conn.close() to release the connection back to the pool in order to maintain backwards compatibility easily without having to modify existing code. Sure, it makes a good business case for existing code, but 10 years down the line, people will wonder why close() also returns a connection to the pool. Long term considerations were simply not made. :-( This problem is only becoming more and more apparent and important as more and more people's excellent OSS code becomes obsolete or "questioned" (because it is not "standard") literally overnight. It is nice to see that others are now starting to get bitten by this as well. :-) For example, I also have to deal with people like Craig constantly bringing up the fact that Struts is more "J2EE Compatible" (and therefore better in his eyes) than Turbine even though Turbine has had the same exact features for years now and they have been well used, well liked, and well tested. Probably more so than existing J2EE code. Next year, you might hear him and others saying that Log4J or ORO or Regexp (which is included in Catalina) or Avalon isn't J2EE Compatible because they don't follow the specifications that Sun releases. One could bring up the OSS argument and say that the code in the JDK isn't OSS and therefore isn't worth using the API's, but that gets nullified as soon as Sun decides to OSS the code or someone realizes that IT managers don't listen very well. Also, where do you draw the line? I know that JDBC has been around forever and everyone agrees to use it, but what if we had some special way of abstracting out talking to the database and suddenly JDBC came along and usurped whatever we had used before? Same problem... One can also spend many hours working for Sun for free, to try to convince the super powers that their code is better than Sun's code or that Sun and the JCP are doing something wrong in the API, but you end up having to battle with the needs of not only yours but whatever commercial pressures that Sun is under (look at their stock price as an example). You also get to battle with the spec leads individual preferences. This is what Ceki is doing with his Log4J. I'm sure that Daniel Savarese would be doing the same for his ORO package if he had the time and energy to spend on it. I guess the whole thing comes down to a matter of choice. Do we believe in what we are doing here in Jakarta land? I certainly do. I don't always agree with the choices that are made or the code that is produced, but I certainly like our Apache open decision making processes a hell of a lot better than I like the Sun/JCP's political mess. Personally, I'm going to continue using and promoting Jakarta technologies in favor of Sun's. If you believe in what we are doing, I hope you will do the same. Will we conquer the world? I hope so...but it will only succeed if you participate in our efforts. One thing to realize is that this group (XML and Jakarta) is a collection of at least 500 very talented developers working together in an open process for several years now. I don't think that Sun can ever come close to matching that amount of momentum. Long live: import org.apache.*; -jon
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>Java Template Language</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> <P> <FONT SIZE="+2">General Instructions</FONT> <P> This template has been designed to be easily filled out using an HTML editor. Please complete all sections. Don't forget to give the proposed specification a name. <P> E-mail the completed JSR to: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>. Don't forget to include the name of the JSR in the subject line. <P>As stated in <A HREF="jcp2.html#1">Section 1</A> of the Java Community Process, JSRs will only be accepted from Members. <BR><BR> <HR> <A NAME="1"></A> <P><FONT size=+2>Title:<br></b>(Insert JSR name here)</FONT></P> <P>Java Template Language</P> <P><font size=+2>Summary:</font><br>(Please provide a description of the JSR in 30 words or less)</P> <P> This JSR defines a template language, the functionality of the template processing engine, and supporting APIs designed for formatting and processing textual and other information from Java. </P> <P><FONT size=+2>Section 1. Identification</FONT> <P><b>Submitting Member:</b> Apache Software Foundation</P> <P><b>Name of Contact Person:</b> Geir Magnusson Jr. and Jon S. Stevens</P> <P><b>E-Mail Address:</b> [EMAIL PROTECTED] and [EMAIL PROTECTED]</P> <P><b>Telephone Number:</b> 203-834-0898 and 510-843-3122</P> <P><b>Fax Number:</b> none</P> <BR> <P><b>Specification Lead:</b> Geir Magnusson Jr. and Jon S. Stevens</P> <P><b>E-Mail Address:</b> [EMAIL PROTECTED] and [EMAIL PROTECTED]</P> <P><b>Telephone Number:</b> 203-834-0898 and 510-843-3122</P> <P><b>Fax Number:</b> none</P> <BR> <P><B>Initial Expert Group Membership:</B> <br>(Please provide company or organization names. Note that expert group members must have <A HREF="./getstarted.html">signed the JSPA</A>.)</P> <P>Apache Software Foundation</P> <BR><BR> <A NAME="2"></A> <P> <FONT SIZE="+2">Section 2: Request</FONT><P> </P> <H4>2.1 Please describe the proposed Specification:</H4> <P> We intend to propose a standard Java Template Language which is based upon the Apache Jakarta Velocity project as the reference implementation. Here is a description of Velocity: </P> <P> Velocity is a Java-based template engine. It permits anyone to use the simple yet powerful template language to reference objects defined in Java code. It also defines a minimal set of directives that control basic logic, variables and basic looping constructs. </P> <P> When Velocity is used for web development, Web designers can work in parallel with Java programmers to develop web sites according to the Model-View-Controller (MVC) model, meaning that web page designers can focus solely on creating a site that looks good, and programmers can focus solely on writing top-notch code. </P> <P> Velocity has been successfully used to solve many problems in textual processing and data output in Java. These solutions include source code (Java, C, etc) and SQL code generation, XML document transformation in conjunction with and in place of XSLT, and web page generation in the Java servlet environment. Velocity is also included in GentleWare's Poseidon for UML Community Edition as the template tool for dynamic generation of Java code from UML. </P> <P> For more information on Velocity, please visit the <a href="http://jakarta.apache.org/velocity/";>website</a> which contains full documentation and download the release. </P> <H4>2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)</H4> <P>Desktop, Server, Personal</P> <H4>2.3 What need of the Java community will be addressed by the proposed specification?</H4> <P> There is currently no formal Java Template Language specification. </P> <H4>2.4 Why isn't this need met by existing specifications?</H4> <P> There is currently no formal Java Template Language specification. </P> <H4>2.5 Please give a short description of the underlying technology or technologies:</H4> <P> Velocity is implemented as 100% Pure Java2 technology. It supports the JavaBean methodology for component access, as well as utilizing Introspection for extending accessability to data beyond the JavaBean-specified patterns. </P> <H4>2.6 Is there a proposed package name for the API Specification? (i.e., <TT>javapi.something</TT>, <TT>org.something</TT>, etc.)</H4> <P>org.apache.velocity</P> <H4>2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?</H4> <P> The only dependency is on JRE/JDK 1.2 and higher. </P> <H4>2.8 Are there any security issues that cannot be addressed by the current security model?</H4> <P> There are no security issues. Velocity fully supports the current Java security model, limiting template access to data and methods that are declared public. </P> <H4>2.9 Are there any internationalization or localization issues?</H4> <P> There are no known issues. Velocity currently supports all valid JDK-supported input encodings, and does not contrain output encoding, which is generally left as a choice of the application. There is also a set of regression tests that validate this. </P> <H4>2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?</H4> <P> None. </P> <H4>2.11 Please describe the anticipated schedule for the development of this specification.</H4> <P> The code (and test suite) has already been developed, documented and released. The goal of the JSR will be to finalize the specification into a formal BNF and specification document and provide a JSR process to the development of the specification. </P> <H4>2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.</H4> <P> The working model will follow the Apache Jakarta development process as closely as possible. </P> <BR><BR> <BR><BR> <A NAME="3"></A> <P> <FONT SIZE="+2">Section 3: Contributions</FONT><P> </P> <H4>3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.</H4> <P> Everything relating to Velocity is available from: <a href="http://jakarta.apache.org/velocity/";>http://jakarta.apache.org/velocity/</a> </P> <H4>3.2 Explanation of how these items might be used as a starting point for the work.</H4> <P> The website and mailing lists is where the current implementation and development work is taking place. </P> <BR><BR> <A NAME="4"></A> <P> <FONT SIZE="+2">Section 4: Additional Information (Optional)</FONT><P> </P> <H4>4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.</H4> <P> None. </P> </BODY> </HTML>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
