Re: What are we doing in regards to JDK 1.4?
[ -- cut -- ] | A couple of years ago, Rick Ross wrote an editorial about the problem of | Sun putting Java companies out of business by putting the functionality | of their products into the Java core (Tools Before Jewels, Java Developer's | Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/) [ -- cut -- ] | It's unfortunate that the JCP is leading to the unnecessary bloat of the | Java core by introducing functionality that is already provided by | numerous third-parties Isn't it actually quite cool that Sun is including lots of functionality with it's Java core? I kind of feel that this is among what makes Java so extremely cool, that a _lot_ of commonly used functionality is already in the core. And you're guaranteed that it will be there when you deploy your little program somewhere else. This, of course, especially goes for the native parts of the language, like GUI and Connections and other HW interfacing parts. If you look at it this way, then I feel that Sun is doing the right thing. If a company comes up with something really smart, why shouldn't Sun include it? Make a similar/better core-part of it? I feel that it's _really_ cool that this happens, it makes the Java language evolve and stay up-to-date. But, if they use it exclusively to close down competiotion, then they're not much better than MS. But I have this good trust and faith in Sun, Sun is Cool, Sun is Nice (brainwashed some time ago ;), and I believe that they do most of their stuff to be nice.. But yes, I do agree that it might seem like the JCP is way to closed, and that Sun and their heavy _money_ partners (but not necessarily with that much more _brains_ than the OS community) should listen to feedback a bit more. -- Mvh, Endre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What are we doing in regards to JDK 1.4?
-Original Message- From: Endre Stølsvik [mailto:[EMAIL PROTECTED]] Sent: Friday, June 22, 2001 3:59 AM To: [EMAIL PROTECTED] Subject: Re: What are we doing in regards to JDK 1.4? Isn't it actually quite cool that Sun is including lots of functionality with it's Java core? I kind of feel that this is among what makes Java so extremely cool, that a _lot_ of commonly used functionality is already in the core. And you're guaranteed that it will be there when you deploy your little program somewhere else. This, of course, especially goes for the native parts of the language, like GUI and Connections and other HW interfacing parts. But this adds to larger JVM installs and increases the size of installed applications. In today's JVM if I don't need reg-ex in my application then I don't have to take the storage space hit. A package or two might not seem like a lot, but when you add up all the separate packages they have added (Swing, Collections, java.text, etc) you start seeing the bloat. When you distribute an application with a JRE, your installer size keeps growing and it takes your users longer and longer to download and more and more disk space to install. What I really think should happen is that Sun should manage the language (things like syntax, language enhancements and things that abstract the hardware). If they want to, they could have a separate group that programs extensions, but these should be optional and not bundled with the JVM (after all, bundling with a package is what got Microsoft in trouble). Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What are we doing in regards to JDK 1.4?
What I really think should happen is that Sun should manage the language (things like syntax, language enhancements and things that abstract the hardware). If they want to, they could have a separate group that programs extensions, but these should be optional and not bundled with the JVM (after all, bundling with a package is what got Microsoft in trouble). +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
At 17:33 20-6-2001 -0400, Berin 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: java.util.regex --- This steps on the toes of both jakarta-regexp and jakarta-oro. In fact by its existence in the JDK, the Apache projects will either loose mindshare, or remain static in their mindshare. org.apache.regexp 1.2 is pretty much broken. It has some major flaws since 1.0 and they are still not addressed. See http://nagoya.betaversion.org/bugzilla/buglist.cgi?product=Regexp for a list of bugs (BTW none of them is assigned). Maybe it's better to just throw regexp out of the window and use Sun's official regex. Bye, Edwin. (Who really do like all the other Jakarta projects). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
Edwin, on 6/21/01 7:16 AM, Edwin Martin [EMAIL PROTECTED] wrote: org.apache.regexp 1.2 is pretty much broken. It has some major flaws since 1.0 and they are still not addressed. See http://nagoya.betaversion.org/bugzilla/buglist.cgi?product=Regexp for a list of bugs (BTW none of them is assigned). Sending in bug reports doesn't get the problems fixed. This is a community of VOLUNTEERS. You can't just magically put in a bug report and then someone is going to jump up and fix it...you have to submit patches or try to nicely motivate people to fix it for you. http://jakarta.apache.org/site/understandingopensource.html With the opensource system, if you find any deficiency in the project, the onus is on you to redress that deficiency. Maybe it's better to just throw regexp out of the window and use Sun's official regex. Sun's official regex isn't available on a wide scale and won't be for quite some time. People are talking about JDK 1.4 like they are going to upgrade immediately when it took at least 2-3 years for people to even start to stop supporting JDK 1.1 Some projects still haven't stopped! Not only that, but you also have to worry about platform support. It takes years for all of the platforms to support the latest and greatest JDK. It is also only going to get more difficult as the JDK's get more complicated to implement and port. You have also seemed to forget (or not understand) the following: #1. Before Jakarta Regexp there was NO solution that was under a BSD'ish license. I was the one who made the effort to go out and find *something* that we could use. It wasn't perfect, but it was a start. #2. That prompted Daniel to change his license on his software as well as donate his code base to us. You now have the distinct advantage of TWO regex packages available under a BSD'ish license to choose from. Each one has its faults and benefits...choice is a good thing. Lastly, Regexp is not an easy problem to solve perfectly. Daniel has been working on the ORO package for YEARS now and is still fixing bugs in it or adding new features. What makes you think that the Sun Regex package is going to come out in JDK 1.4 and be perfectly implemented? Even if the API is good (which Daniel has already stated that it sucks) there will still be show stopper bugs in it that YOU CANNOT FIX!!! because: 1) it is part of the standard JDK, 2) has a standard JDK release cycle and 3) YOU DO NOT HAVE THE ABILILTY TO EASILY AND DIRECTLY INFLUENCE THE SOURCE CODE DEVELOPMENT. Sigh. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
At 09:42 21-6-2001 -0700, Jon wrote:
Edwin,
on 6/21/01 7:16 AM, Edwin Martin [EMAIL PROTECTED] wrote:
org.apache.regexp 1.2 is pretty much broken. It has some
major flaws since 1.0 and they are still not addressed.
See http://nagoya.betaversion.org/bugzilla/buglist.cgi?product=Regexp
for a list of bugs (BTW none of them is assigned).
Sending in bug reports doesn't get the problems fixed. This is a community
of VOLUNTEERS. You can't just magically put in a bug report and then someone
is going to jump up and fix it...you have to submit patches or try to nicely
motivate people to fix it for you.
http://jakarta.apache.org/site/understandingopensource.html
With the opensource system, if you find any deficiency in the project, the
onus is on you to redress that deficiency.
I thought submitting bug reports is also an important
way to support Open Source.
Well, I looked at the regexp-code and saw one of the bugs:
RECompiler.java, line 664:
// Premature end of range. define up to Character.MAX_VALUE
if ((idx + 1) len pattern.charAt(++idx) == ']')
{
simpleChar = Character.MAX_VALUE;
break;
}
The code makes any minus a range.
The RE [a-] becomes the character a and anything after it.
A minus at the beginning or the end should be just a minus.
The code should be something like this:
// Premature end of range. define up to
Character.MAX_VALUE
if ((idx + 1) len pattern.charAt(++idx) == ']')
{
definingRange = false;
break;
}
Futhermore, RECompiler.java, line 697:
if ((idx + 1) = len || pattern.charAt(idx + 1) != '-')
Should become something like:
if ((idx + 1) = len || !(pattern.charAt(idx + 1) == '-'
!((idx + 2) = len pattern.charAt(idx + 2) == ']')))
Which means: Do not include a char when followed by a minus, but DO include the
char when the minus is followed by a ']'.
The code still does not address the possibility of a charclass which starts
with a
minus, like [-a] or [^-a], but that shouldn't be too difficult to
implement.
It isn't really that hard to fix these bugs, I just wonder if there's anybody
responsible for the regexp package.
And by the way, you don't have to shout.
Bye,
Edwin Martin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
on 6/21/01 2:24 PM, Edwin Martin [EMAIL PROTECTED] wrote: I thought submitting bug reports is also an important way to support Open Source. s/Open Source/Anything/ It isn't specific to OSS to submit a bug report... The code should be something like this: Submit a patch to the regexp-dev mailing list. This is the wrong forum for that discussion. It isn't really that hard to fix these bugs, I just wonder if there's anybody responsible for the regexp package. The people who are responsible for regexp (or any of the projects for that matter) are clearly defined in the CVSROOT/avail file. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
At 04:16 PM 6/21/2001 +0200, Edwin Martin wrote: At 17:33 20-6-2001 -0400, Berin 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: java.util.regex --- This steps on the toes of both jakarta-regexp and jakarta-oro. In fact by its existence in the JDK, the Apache projects will either loose mindshare, or remain static in their mindshare. org.apache.regexp 1.2 is pretty much broken. It has some major flaws since 1.0 and they are still not addressed. See http://nagoya.betaversion.org/bugzilla/buglist.cgi?product=Regexp for a list of bugs (BTW none of them is assigned). Maybe it's better to just throw regexp out of the window and use Sun's official regex. I'll only comment about the regex stuff in jdk 1.4 since I haven't messed with any of the other counterparts for this discussion. I've been playing with regex along with the nio classes and I must say that they integrate with each other extremely well. You must try out some of the new api's to fully appreciate the performance gains you will get from their new SocketChannel/ByteBuffer approach to networking. The regex code will parse through an existing buffer which could be a direct memory map from an io device. I don't think there would be any way to do that level of integration without rewriting lots of native code. Jon wrote, and I agree, that Sun may make mistakes with their interfaces in their attempt to maintain backward-compatibility, but now that they've introduced a new select/poll style of networking that is really geared toward performance, I'm happy to say that they've written it in new packages from scratch rather than try to retrofit the existing io methods to work with the new system. It looks like they've left Strings and byte[] buffers in the dust with the new ByteBuffer/xxxBuffer classes and all of the surrounding code works directly on these buffers rather than needing to convert to strings or char or byte arrays. There was mention of NBIO http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ recently which is a native-code nonblocking IO implementation which I've been using for a while. The author of that code, Matt Welsh, is on the expert group for the .nio classes of java and the Sun implementation has stayed quite true to the desires of those of us who want the best-performing networking possible. It's pretty early to start switching any of the current Jakart projects to 1.4, but I'll venture to say that there will be very few java-based servers in existence in a few years that are still using blocking InputStream/OutputStreams and the one-or-more-threads-per-connection model. Bernie Bernie Bernstein Liveworld Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
Wow! I'm glad I was browsing jakarta-general today - interesting and enlightening discussion. Re: influencing Sun: be sure to participate (or send feedback, or whatever they let you do) in JSR's of interest like Ceki was organizing. Many of them do listen, even if the end result isn't always what you suggest. Also, there are Apache implementations that will be shipping with JDK 1.4 - Xalan (originally from Lotus) is the XSLT transformer reference implementation in JAXP 1.1, and a newer version will be in the JDK 1.4 extensions directory. I was doing an informal survey of Apache project's use at JavaOne recently and *lots* of products and companies are using our stuff. Just wanted to note that it's not *all* bad news. IMO, there will still be plenty of room for Apache projects to compete even against built-in features in future JDK's. One thing that will really help this long-term is continuing to improve all our project's coordination and documentation - especially user-level documentation. I think both of the commons'es and the recent projects on getting a site-wide docset building from XML are excellent steps - we just need to keep working on this kind of issue. - Shane, xml-xalanite, xml-commons instigator (not on jakarta-general, please cc: with direct replies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
on 6/21/01 3:35 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Wow! I'm glad I was browsing jakarta-general today - interesting and enlightening discussion. Re: influencing Sun: be sure to participate (or send feedback, or whatever they let you do) in JSR's of interest like Ceki was organizing. Many of them do listen, even if the end result isn't always what you suggest. Lets work for Sun for free too show them how to do things. Why is there this constant pressure that we should be helping Sun increase their stock price? You never hear such a thing from the language communities. Also, there are Apache implementations that will be shipping with JDK 1.4 - Xalan (originally from Lotus) is the XSLT transformer reference implementation in JAXP 1.1, and a newer version will be in the JDK 1.4 extensions directory. Explain to me how is this legal under the current JCP licensing rules. I was doing an informal survey of Apache project's use at JavaOne recently and *lots* of products and companies are using our stuff. Just wanted to note that it's not *all* bad news. 50-100k downloads / month of Tomcat. I think that we know this stuff is being used. :-) If anything that should be more motivation for Sun and other companies to spend more time adopting the stuff we are generating here. Like I said before...500+ OSS developers is a lot more powerful than what Sun can muster up. IMO, there will still be plenty of room for Apache projects to compete even against built-in features in future JDK's. One thing that will really help this long-term is continuing to improve all our project's coordination and documentation - especially user-level documentation. I think both of the commons'es and the recent projects on getting a site-wide docset building from XML are excellent steps - we just need to keep working on this kind of issue. Do we really need to compete at the tools and API implementation level though? Wouldn't it make more sense to work towards one exceptional logging implementation, one exceptional XSLT transformation engine, etc? -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
I've been playing with regex along with the nio classes and I must say that they integrate with each other extremely well. You must try out some of the new api's to fully appreciate the performance gains you will get from their new SocketChannel/ByteBuffer approach to networking. The regex code will parse through an existing buffer which could be a direct memory map from an io device. I don't think there would be any way to do that level of integration without rewriting lots of native code. The java.util.regex package is completely orthogonal to the nio stuff and reading input from a CharSequence doesn't qualify as integration. Any third-party package could do the same. The nio stuff was sorely needed and we shouldn't have had to wait for over 5 years for Java to be able to do decent I/O. The regex stuff has serious problems from both a performance and API design perspective and had no business being thrown in as an afterthought with JSR-51. Regular expression and logging have no business being in the core anyway. The story of Java is one of getting the APIs wrong and having to fix them in a later release, throwing in unnecessary classes and packages, retrofitting the language to make up for obvious oversights, and flat out ignoring the lessons learned during the standardization process of languages that came before, such as C++. Guy Steele's OOPSLA 98 keynote is a model of how Java should have evolved but clearly hasn't: http://www.cs.bell-labs.com/who/wadler/pizza/gj/Documents/steele-oopsla98.pdf A couple of years ago, Rick Ross wrote an editorial about the problem of Sun putting Java companies out of business by putting the functionality of their products into the Java core (Tools Before Jewels, Java Developer's Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/) It mistakenly implied my old company went out of business because of Sun (it didn't), but visits the same issue brought up about JDK 1.4 and some of its new APIs. This is a problem that's been with us for a while and is not going away. Anyway, my comments have strayed off-topic. All we can do is keep writing code as usual and hammer Sun with constructive criticism when they go astray in the hopes they'll listen. Yes, some of our projects will lose a certain amount of following because their functionality is duplicated in JDK 1.4, but they won't die. For two years I didn't update the software that became jakarta-oro, yet its following grew even though there were actively maintained alternative products. If you provide something that programmers need and want that others don't, programmers will use your software and stick with you. log4j and jakarta-oro are distinguished by their performance, feature set, and flexibility of their designs. It's unfortunate that the JCP is leading to the unnecessary bloat of the Java core by introducing functionality that is already provided by numerous third-parties, but Jakarta will survive if we focus on quality and the advantages of an open source development model. As Jon pointed out, you can get bugs fixed quickly, have your changes introduced, and directly influence the development of the software. Jakarta evolves more rapidly and is much more responsive to developer needs. No worries here. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
22.06.2001 08:02:13, Daniel F. Savarese [EMAIL PROTECTED] wrote: I've been playing with regex along with the nio classes and I must say that they integrate with each other extremely well. You must try out some of the new api's to fully appreciate the performance gains you will get from their new SocketChannel/ByteBuffer approach to networking. The regex code will parse through an existing buffer which could be a direct memory map from an io device. I don't think there would be any way to do that level of integration without rewriting lots of native code. The java.util.regex package is completely orthogonal to the nio stuff and reading input from a CharSequence doesn't qualify as integration. Any third-party package could do the same. The nio stuff was sorely needed and we shouldn't have had to wait for over 5 years for Java to be able to do decent I/O. The regex stuff has serious problems from both a performance and API design perspective and had no business being thrown in as an afterthought with JSR-51. Regular expression and logging have no business being in the core anyway. The story of Java is one of getting the APIs wrong and having to fix them in a later release, throwing in unnecessary classes and packages, retrofitting the language to make up for obvious oversights, and flat out ignoring the lessons learned during the standardization process of languages that came before, such as C++. Guy Steele's OOPSLA 98 keynote is a model of how Java should have evolved but clearly hasn't: http://www.cs.bell-labs.com/who/wadler/pizza/gj/Documents/steele-oopsla98.pdf A couple of years ago, Rick Ross wrote an editorial about the problem of Sun putting Java companies out of business by putting the functionality of their products into the Java core (Tools Before Jewels, Java Developer's Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/) It mistakenly implied my old company went out of business because of Sun (it didn't), but visits the same issue brought up about JDK 1.4 and some of its new APIs. This is a problem that's been with us for a while and is not going away. Anyway, my comments have strayed off-topic. All we can do is keep writing code as usual and hammer Sun with constructive criticism when they go astray in the hopes they'll listen. Yes, some of our projects will lose a certain amount of following because their functionality is duplicated in JDK 1.4, but they won't die. For two years I didn't update the software that became jakarta-oro, yet its following grew even though there were actively maintained alternative products. If you provide something that programmers need and want that others don't, programmers will use your software and stick with you. log4j and jakarta-oro are distinguished by their performance, feature set, and flexibility of their designs. It's unfortunate that the JCP is leading to the unnecessary bloat of the Java core by introducing functionality that is already provided by numerous third-parties, but Jakarta will survive if we focus on quality and the advantages of an open source development model. As Jon pointed out, you can get bugs fixed quickly, have your changes introduced, and directly influence the development of the software. Jakarta evolves more rapidly and is much more responsive to developer needs. No worries here. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are we doing in regards to JDK 1.4?
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 TITLEJava Template Language/TITLE /HEAD BODY BGCOLOR=#FF TEXT=#00 P FONT SIZE=+2General 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. PAs stated in A HREF=jcp2.html#1Section 1/A of the Java Community Process, JSRs will only be accepted from Members. BRBR HR A NAME=1/A PFONT size=+2Title:br/b(Insert JSR name here)/FONT/P PJava Template Language/P Pfont size=+2Summary:/fontbr(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 PFONT size=+2Section 1. Identification/FONT PbSubmitting Member:/b Apache Software Foundation/P
