Re: CharSequence support

"Nic Ferrier" <[EMAIL PROTECTED]> writes: > >>> Mark Wielaard <[EMAIL PROTECTED]> 10-Jul-01 1:00:59 AM >>> > >I did not add the new 1.4 split() methods to String. >They need java/util/regexp support. Maybe we can >ask Wes Biggs if we may import part of gnu.regexp to >implement

Chained Exceptions and StackTraceElement support

Hi, The 1.4 spec finally defines a generic Exception chaining mechanism so you don't have to implement this in an ad hoc way for every project. It also defines a general StackTraceElement that can be used to inspect the call stack of an exception. I have seen people do this by parsing the output

Re: CharSequence support

>>> Mark Wielaard <[EMAIL PROTECTED]> 10-Jul-01 1:00:59 AM >>> I did not add the new 1.4 split() methods to String. They need java/util/regexp support. Maybe we can ask Wes Biggs if we may import part of gnu.regexp to implement it. It is licensed under the LGPL, but since it see

CharSequence support

Hi, The following patch adds 1.4 CharSequence support to String and StringBuffer. It also adds one extra method to String and adds an implements Serializable. 2001-07-10 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/CharSequence.java: new 1.4 interface * java/lang/String.java: implement

Re: Primitive types 1.4 updates

Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > The following patch adds new 1.4 functionality to the Boolean, Double > and Float classes. It also makes Boolean a little bit more efficient > by always returning the predefined TRUE or FALSE instances when > possible. > > 2001-07-10 Mark Wie

Primitive types 1.4 updates

Hi, The following patch adds new 1.4 functionality to the Boolean, Double and Float classes. It also makes Boolean a little bit more efficient by always returning the predefined TRUE or FALSE instances when possible. 2001-07-10 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/Boolean.java (val

Re: Java tools

"Nic Ferrier" <[EMAIL PROTECTED]> writes: > >>> Stuart Ballard <[EMAIL PROTECTED]> 09-Jul-01 4:00:18 PM >>> > >Sun might - they don't like people using the name >"Java" for things. > > The FSF doesn't use the word either. It was a mistake for me to call > the project that. > > The pro

File compile fix

Hi, I comitted the following to get java/io/File.java to compile again. The single String constructor will throw the NullPointerException when needed. 2001-07-10 Mark Wielaard <[EMAIL PROTECTED]> * java/io/File.java (String,String constructor): compile fix Cheers, Mark -- Stuff to rea

Re: Java tools

>>> Stuart Ballard <[EMAIL PROTECTED]> 09-Jul-01 4:00:18 PM >>> Sun might - they don't like people using the name "Java" for things. The FSF doesn't use the word either. It was a mistake for me to call the project that. The project wouyld actually be called something like "class-tools" b

Re: Java tools

Nic Ferrier wrote: > > I have proposed to Julian that a new GNU project be setup called: > java-tools. We can put things like javadoc and jar-tool > implementations under that project. > > Does anyone have any objections to that? Sun might - they don't like people using the name "Java" for thin

Java tools

Julian Schied has had some conversations with various people about his Javadoc implementation. It seems that the code doesn't really fit into any of the current GNU projects: - not kaffe, japhar or GCJ because it's not a compiler or VM - not Classpath because it's not core libs - not Classpathx

Satisfying EncodingManager

Can someone tell me, what is the minimum I need to do to make EncodingManager behave? All I want to do is run Hello World, and EncodingManager seems to want to do reflection for Pete's sake. Can I just comment out a few lines of EncodingManager and just make it work properly for Hello World? I