RE: [jira] Assigned: (HARMONY-376) [classlib][luni] Generics uplift for java.lang.String and java.util.Comparator

[Loenko, Mikhail Y]

Hi Nathan

the patch breaks the build

compile:
[javac] Compiling 1639 source files to C:\harmony\build
[javac]
C:\harmony\modules\jndi\src\main\java\javax\naming\CompositeName.java:50
9: compareTo(java.lang.String) in java.lang.String cannot be applied to
(java.lang.Object)
[javac] r = ((String)
elems.get(i)).compareTo(he.elems.get(i));
[javac] ^

Thanks,
Mikhail 


>-Original Message-
>From: Mikhail Loenko (JIRA) [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, April 19, 2006 12:37 PM
>To: [EMAIL PROTECTED]
>Subject: [jira] Assigned: (HARMONY-376) [classlib][luni] Generics
uplift for java.lang.String and
>java.util.Comparator
>
> [ http://issues.apache.org/jira/browse/HARMONY-376?page=all ]
>
>Mikhail Loenko reassigned HARMONY-376:
>--
>
>Assign To: Mikhail Loenko
>
>> [classlib][luni] Generics uplift for java.lang.String and
java.util.Comparator
>>

--
>>
>>  Key: HARMONY-376
>>  URL: http://issues.apache.org/jira/browse/HARMONY-376
>>  Project: Harmony
>> Type: Improvement
>
>>   Components: Classlib
>> Reporter: Nathan Beyer
>> Assignee: Mikhail Loenko
>>  Attachments: String_Comparator_generics_uplift.txt
>>
>> This issue is for adding the generic signatures to
java.util.Comparator, java.lang.String and a
>bit of clean up and updated test cases.
>
>--
>This message is automatically generated by JIRA.
>-
>If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
>-
>For more information on JIRA, see:
>   http://www.atlassian.com/software/jira

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Stepan Mishura]

On 4/18/06, Mark Hindess wrote:
>
> Stepan,
>
> Sorry.  I didn't mean to blame you.  I did realise that you were just
> putting it back to the "initial" style.


Mark, I also expected that you didn't want to blame me :-) As far as English
is not my native language I used to read messages in a way like my good
friend points out to my mistakes (except if a message is not obviously
rude).


> Since you asked (well almost ;-) I'm in favour of 4 space indent since
> this is quite common in the java code.  Unlike Geir I don't mind if
> tabs are used but they should always be treated as being equivalent to
> 8 spaces.  Though I'd might change my mind if I understood the
> motivation behind Geir's aversion to tabs.


OK. If there will be no objections I'm going to replace tabs with 4 space
indent in build files.

Thanks,
Stepan.

Regards,
> Mark.
>
> On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > Mark,
> >
> > The update only adjusts build files to *initial* style (that is
> tabs-style).
> >
> > IMHO really doesn't matter how many spaces in one tab if you follow one
> > style in a file and don't mix tabs with spaces. Also I like
> > tab-style because I have opportunity to choose a number of spaces that
> more
> > suitable for my eyes. If everybody will agree to use only space-style
> then
> > OK - I'll fix tabs.
> >
> > Thanks,
> > Stepan.
> >
> >
> > On 4/18/06, Mark Hindess wrote:
> > >
> > > For many people however tabs are equivalent to 8 spaces so if what we
> > > really intend is 4 spaces then perhaps we should make them spaces not
> > > tabs?
> > >
> > > Otherwise we will be forever fixing identations because of editor
> > > differences.
> > >
> > > -Mark.
> > >
> > > On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > > > On 4/18/06, Mark Hindess wrote:
> > > > >
> > > > > Stepan,
> > > > >
> > > > > Just curious what you are fixing here?  Changing 8 spaces to tabs?
> > > > > Why does this matter?  Shouldn't tabs (at the beginning of a line)
> > > > > always be equivalent to 8 spaces?
> > > >
> > > >
> > > > Mark,
> > > >
> > > > I'd prefer to have all build files follow one style - I don't like
> > > mixing
> > > > tabs and spaces even they looks the same. For this particular case -
> > > build
> > > > files were initially created using tabs and I'd prefer to keep this
> > > style.
> > > > Also for me tab is not equivalent to 8 spaces - Eclipse sets tab
> > > equivalent
> > > > to 4 spaces and I'm not going to change it because I like it :-)
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > > Incidentally, I think 8 character indentations are excessive.  Quite
> a
> > > > > few of the ant files use 4 character indentations which I find
> much
> > > > > easier to read.  Ditto for java code.  Perhaps we could agree
> which to
> > > > > use?
> > > > >
> > > > > Regards,
> > > > > -Mark - wondering if he might regret asking this
> > > > >
> > > > > On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > > > Author: smishura
> > > > > > Date: Tue Apr 18 02:38:29 2006
> > > > > > New Revision: 394890
> > > > > >
> > > > > > URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> > > > > > Log:
> > > > > > Correcting indentation
> > > > > >
> > > > > > Modified:
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> > > > > >
> > > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> > > > > >
> > > > >
>

Re: matching reference implementation exception behaviour

[Alex Orlov]

> Alex, I've uploaded the scripts that I've been using to generate test case as:
>
>  http://issues.apache.org/jira/browse/HARMONY-325
>
> I'd be interested in any comments/suggestions.

Oops, sorry, apparently I missed that e-mail. Surely we'll try it and
compare with our one.

Many thanks,

Alex Orlov.
Intel Middleware Products Division

>
> Regards,
>  Mark.
>
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: classlib test suite status emails?

[Stepan Mishura]

On 4/18/06, Mark Hindess wrote:

> On 4/13/06, Stepan Mishura wrote:
> >
> > Hi Mark,
> >
> > HARMONY-331 was commited to the trunk so is there any chance to have
> > classlib test suite status emails sent to the commits list?
>
> Ok.  I've added notifiers to both our linux and windows jobs that are
> doing build and test.


Great!

Unfortunately, since Continuum truncates notification messages, it
> wont always be obvious what has broken.  That said, the logs are a
> little shorter since removed the "second stage" build with IBM VME,
> Harmony and eclipse compiler step from the builds.


May be it makes sense to broke intentionally the build (to force some tests
to fail) and see what notification will be sent? Then everybody will see how
it looks like.

Thanks,
Stepan.

Regards,
> Mark.
>
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
---
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thanks,
Stepan Mishura
Intel Middleware Products Division

Re: should strings in exceptions match the reference implementation?

[Dalibor Topic]

Geir Magnusson Jr  pobox.com> writes:

> Good question though - what does GNU Classpath do?

Throw better exception messages, of course ;)

I don't see a specific rule regarding this in the GNU Classpath 
hackers guide [1], but as long as a specific exception message 
(format) is not mandated by the spec, we (should here, and do in 
GNU Classpath in general) take the liberty to provide (more) 
useful error messages. 

>From my experience with the RI, the exception messages tend to 
be of less then desirable utility to fix the problems that 
cause the exceptions [2], so copying them verbatim does not 
apper to be desireable to me.

Moreover, the 'search engine optimization' effect of copying 
the same error messages would seem to be easily fixeable by 
providing better error messages in ant, if I understood 
Mark's example correctly ...

So, to cut my post short, I'm with Elena on this: provide a 
useful exception message that helps the user figure out what 
the problem is.

cheers,
dalibor topic

[1] http://www.gnu.org/software/classpath/docs/hacking.html
[2] http://forums.oracle.com/forums/thread.jspa?threadID=377599&tstart=0
 for a classic example:

java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver

Obviously, it would be a bit more helpful to know where the system went looking
for that class, for example. So Kaffe would give you:

java.lang.ClassNotFoundException: NoSuchClass not found in
java.lang.ClassLoader$1{urls=[file:/home/topic/projects/kaffe/./], parent=null}

which is a bit more helpful.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (HARMONY-373) beans: Harmony does not throw NullPointerException in several cases while RI does.

[Dmitry M. Kononov]

On 4/18/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> Dmitry,
>
> Out of curiosity, how are you discovering these?  I've just uploaded an
> updated version of my testing tool to HARMONY-325.  I think it should
> find most of the problems you are reporting - see the results file,
> harmony.exception.differences-0.02.txt.  It can also generate test
> cases.

Mark,

Alex Orlov has mentioned a similar tool in the thread "matching
reference implementation exception behaviour".
This issue (HARMONY-373) is the first one from a series that was
discovered by the tool. Actually, I have got lots of issues that have
already investigated with prepared unit tests. So, I just prepare
patches and file JIRA issues.

Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [rmi] package comparison (was Re: Contribution of RMI framework)

[Zakharov, Vasily M]

Daniel,

I've been trying to do some comparisons, as I promised, and I believe
I'm missing something.

I was testing the interoperability, and when I tried to use an "Intel"
RMI client against an "ITC" server, it failed, although it worked
against a "Sun" server. Changing client and server produces the same
result. Here're the stack traces I get, the test code and the config.
Any idea, what I'm
doing wrong?

Vasily Zakharov
Intel Middleware Products Division


Stack trace 1 ("ITC" client, "Sun" or "Intel" server):

java.rmi.ConnectIOException: I/O exception Creating Connection; nested
exception is:
java.rmi.MarshalException: Exception marshaling JRMP Header;
nested exception is:
java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
java.io.EOFException
at
ar.org.fitc.rmi.transport.ConnectionPool.getClientConnection(Unknown
Source)
at ar.org.fitc.rmi.transport.TransportManager.invoke(Unknown
Source)
at ar.org.fitc.rmi.server.UnicastRemoteRefImpl.invoke(Unknown
Source)
at ar.org.fitc.rmi.registry.RegistryImpl_Stub.lookup(Unknown
Source)
at Client.main(Client.java:14)
Caused by: java.rmi.MarshalException: Exception marshaling JRMP Header;
nested exception is:
java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
java.io.EOFException
at
ar.org.fitc.rmi.transport.StreamClientConnection.handshake(Unknown
Source)
at
ar.org.fitc.rmi.transport.StreamClientConnection.establishConnection(Unk
nown Source)
... 5 more
Caused by: java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
java.io.EOFException
at
ar.org.fitc.rmi.transport.jrmp.ClientProtocolHandler.readHandshakeRespon
se(Unknown Source)
... 7 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(Unknown Source)
... 8 more


Stack trace 2 ("Intel" client, "ITC" server):

java.rmi.ConnectIOException: Unable to acknowledge protocol with server;
nested exception is:
java.io.EOFException
at
org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp
Connection.java:145)
at
org.apache.harmony.rmi.client.ClientConnection.(ClientConnection.j
ava:90)
at
org.apache.harmony.rmi.transport.tcp.TcpConnection.(TcpConnection.
java:73)
at
org.apache.harmony.rmi.client.ClientConnectionManager.getConnection(Clie
ntConnectionManager.java:107)
at
org.apache.harmony.rmi.remoteref.UnicastRef.newCall(UnicastRef.java:226)
at
org.apache.harmony.rmi.remoteref.UnicastRef.invoke(UnicastRef.java:127)
at
org.apache.harmony.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_St
ub.java:134)
at Client.main(Client.java:14)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(Unknown Source)
at
org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp
Connection.java:112)
... 7 more


Server.java:

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.UnicastRemoteObject;

interface TestRemoteInterface extends Remote {
public String test() throws RemoteException;
}

class TestRemoteObject implements TestRemoteInterface {
public String test() throws RemoteException {
System.out.println("TestRemoteObject.test() run");
return "SUCCESS";
}
}

public class Server {
public static void main(String[] args) {
TestRemoteObject obj = null;

try {
System.out.println("Setting security manager");
System.setSecurityManager(new RMISecurityManager());
System.err.println("Creating registry");
Registry registry = LocateRegistry.createRegistry(1099);
System.out.println("Creating remote object");
obj = new TestRemoteObject();
System.out.println("Exporting remote object");
UnicastRemoteObject.exportObject(obj, );
System.out.println("Binding object to registry");
registry.rebind("TestRemoteObject", obj);
System.out.println("Sleeping 10 seconds");
Thread.sleep(1);
} catch (Throwable e) {
e.printStackTrace();
System.err.println("ERROR");
} finally {
if (obj != null) {
System.out.println("Unexporting remote object");

try {
if (UnicastRemoteObject.unexportObject(obj, false))
{
System.out.println("Unexport FALSE");
} else {
if (UnicastRemoteObject.unexportObject(obj,
true)) {
System.out.println("Unexport TRUE");
} else {

Re: [jira] Created: (HARMONY-373) beans: Harmony does not throw NullPointerException in several cases while RI does.

[Mark Hindess]

On 4/18/06, Dmitry M. Kononov (JIRA) <[EMAIL PROTECTED]> wrote:
> beans: Harmony does not throw NullPointerException in several cases while RI 
> does.
> --
>
>  Key: HARMONY-373
>  URL: http://issues.apache.org/jira/browse/HARMONY-373
>  Project: Harmony
> Type: Bug
>
>   Components: Classlib
> Reporter: Dmitry M. Kononov
> Priority: Minor
>
>
> Harmony does not throw NPE as it is described below:
>
> 1) java.beans.beancontext.BeanContextSupport.getResourceAsStream(String name, 
> BeanContextChild bcc):
> Harmony does not throw NullPointerException when name="",bcc=null, while RI 
> throws it.
> Direct method specification says only "Throws: NullPointerException".
> [SNIP]

Dmitry,

Out of curiosity, how are you discovering these?  I've just uploaded an
updated version of my testing tool to HARMONY-325.  I think it should
find most of the problems you are reporting - see the results file,
harmony.exception.differences-0.02.txt.  It can also generate test
cases.

Sadly it doesn't fix the bugs. ;-)

Regards,
 Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ?Pascuas en el siglo XXI?

[Fernando Cassia]

On 4/18/06, Leo Simons <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 17, 2006 at 07:37:47PM -0400, Geir Magnusson Jr wrote:
> > Fernando Cassia wrote:
> > >What the
> > >
> > >Is there a way to moderate harmont-dev so messages like this can never
> make
> > >it to the list?.
> >
> > They only way that would get to the list is if the sender was
> > subscribed.  We don't let unsubscribed people post, and there is no
> > moderator decision point.




I´ve emailed the author, expecting a bounce due to a non-existing sender,
and guess what, the sender was a real live human being.

He said he sent the message to all his contact list, and harmony-dev was
included by mistake.

Regards
Fernando

Re: Summer Of Code 2006 - Lets get Harmony involved

[Geir Magnusson Jr]

Excellent!  Now we need a project.  Have anything you'd like to propose? 
  What interests you?


geir


Sanket Sharma wrote:

Hey...

I'm a final sem student doing my internship

Get me in.. I wann get involved with harmony!


Awaiting reply,
Sanket

-Original Message-
From: Archie Cobbs [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 7:50 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Summer Of Code 2006 - Lets get Harmony involved

Geir Magnusson Jr wrote:

Google again is running their "Summer Of Code"
http://code.google.com/summerofcode.html program, and I think it would
be great for the Harmony project to take advantage of it, assuming we
can find willing students.
...
Lets agree on projects here first.

Great idea.. certainly one project that seems suitable is completing
the gnuclasspathadapter stuff started by Weldon.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This email may contain confidential or privileged information for the 
intended recipient(s) and the views expressed in the same are not 
necessarily the views of Zensar Technologies Ltd. If you are not the intended 
recipient or have received this e-mail by error, its use is strictly 
prohibited, please delete the e-mail and notify the sender. Zensar 
Technologies Ltd. does not accept any liability for virus infected mails.



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Summer Of Code 2006 - Lets get Harmony involved

[Sanket Sharma]

Hey...

I'm a final sem student doing my internship

Get me in.. I wann get involved with harmony!


Awaiting reply,
Sanket
> -Original Message-
> From: Archie Cobbs [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 18, 2006 7:50 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Summer Of Code 2006 - Lets get Harmony involved
> 
> Geir Magnusson Jr wrote:
> > Google again is running their "Summer Of Code"
> > http://code.google.com/summerofcode.html program, and I think it would
> > be great for the Harmony project to take advantage of it, assuming we
> > can find willing students.
> > ...
> > Lets agree on projects here first.
> 
> Great idea.. certainly one project that seems suitable is completing
> the gnuclasspathadapter stuff started by Weldon.
> 
> -Archie
> 
> __
> Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


This email may contain confidential or privileged information for the 
intended recipient(s) and the views expressed in the same are not 
necessarily the views of Zensar Technologies Ltd. If you are not the intended 
recipient or have received this e-mail by error, its use is strictly 
prohibited, please delete the e-mail and notify the sender. Zensar 
Technologies Ltd. does not accept any liability for virus infected mails.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Summer Of Code 2006 - Lets get Harmony involved

[Dalibor Topic]

On Tue, Apr 18, 2006 at 09:19:30AM -0500, Archie Cobbs wrote:
> Geir Magnusson Jr wrote:
> >Google again is running their "Summer Of Code" 
> >http://code.google.com/summerofcode.html program, and I think it would 
> >be great for the Harmony project to take advantage of it, assuming we 
> >can find willing students.
> >...
> >Lets agree on projects here first.
> 
> Great idea.. certainly one project that seems suitable is completing
> the gnuclasspathadapter stuff started by Weldon.

A fun little project could be to turn JCHVM into a jit by using tcc[1]
to create linkable objects.

cheers,
dalibor topic

[1] http://fabrice.bellard.free.fr/tcc/

> 
> -Archie
> 
> __
> Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Summer Of Code 2006 - Lets get Harmony involved

[Archie Cobbs]

Geir Magnusson Jr wrote:
Google again is running their "Summer Of Code" 
http://code.google.com/summerofcode.html program, and I think it would 
be great for the Harmony project to take advantage of it, assuming we 
can find willing students.

...
Lets agree on projects here first.


Great idea.. certainly one project that seems suitable is completing
the gnuclasspathadapter stuff started by Weldon.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (HARMONY-350) HARMONY-39 Regular expressions does not match backreferences during find.

[Nikolay Kuznetsov]

Done.

> Nikolay,
>
> please provide a single patch that resolves the problem
>
> Thanks,
> Mikhail

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: classlib test suite status emails?

[Mark Hindess]

On 4/13/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>
> Hi Mark,
>
> HARMONY-331 was commited to the trunk so is there any chance to have
> classlib test suite status emails sent to the commits list?

Ok.  I've added notifiers to both our linux and windows jobs that are
doing build and test.

Unfortunately, since Continuum truncates notification messages, it
wont always be obvious what has broken.  That said, the logs are a
little shorter since removed the "second stage" build with IBM VME,
Harmony and eclipse compiler step from the builds.

Regards,
 Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Geir Magnusson Jr]

What does the RI do?  :)

I was thinking more about this - can you imagine the confusion if in a 
mixed environment of Sun JRE and Harmony JRE, something went wrong that 
affected both, and you started getting two different error messages for 
the same problem in your logs?  How confusing would that be?


geir


Semukhina, Elena V wrote:

Just one more example.
Should users feel comfortable when getting the RI's message

"java.lang.ArithmeticException: Division impossible"?

Isn't it better for a class library to provide 
"java.lang.ArithmeticException: integer part of the quotient needs more

than 11 digits"
to help our users find the cause of an exception?

Regards,
Elena Semukhina
Intel Middleware Products Division


-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 18, 2006 6:56 PM
To: harmony-dev@incubator.apache.org
Subject: Re: should strings in exceptions match the reference
implementation?

Yes - great example.  The point is for mechanical means, but

familiarity

for users - we don't want them to be "uncomfortable" when using the
Harmony class library - we want it to feel the same as when they use it
from Sun...
geir


Mark Hindess wrote:

I thought my first message in this thread made this clear but

obviously

not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.

Regards,
 Mark.

On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:

On Tuesday 18 April 2006 09:37, Mark Hindess wrote:

Are you saying that Classpath does match strings in exceptions?

No. Ah, I see: the "do" in Geir's question stood for "what is

Classpath's

policy wrt to exception messages matching those of the RI?". Then I

don't

speak authoritatively, but I've never noticed Classpath going out of

its

way

to be compatible at this level. But then I would never write code

which

depended on the precise contents of an exception message ...

Sorry for the confusion,

Chris

--
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369




-

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:

[EMAIL PROTECTED]




--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:

[EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Geir Magnusson Jr]

Richard Liang wrote:

Geir Magnusson Jr wrote:

Wait - no tabs!  no tabs!  PLEASE!



+1. But are there any way to release our pain from TABs? :-)


Yes - most editors will convert tabs to spaces.  I suppose if we agree 
on a "no tabs" rule, and find files w/ tabs, lets do a conversion, and 
check it in w/o any other mods, with the commit log entry of "changing 
tabs to spaces" or such


geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: should strings in exceptions match the reference implementation?

[Semukhina, Elena V]

Just one more example.
Should users feel comfortable when getting the RI's message

"java.lang.ArithmeticException: Division impossible"?

Isn't it better for a class library to provide 
"java.lang.ArithmeticException: integer part of the quotient needs more
than 11 digits"
to help our users find the cause of an exception?

Regards,
Elena Semukhina
Intel Middleware Products Division

>-Original Message-
>From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, April 18, 2006 6:56 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: should strings in exceptions match the reference
>implementation?
>
>Yes - great example.  The point is for mechanical means, but
familiarity
>for users - we don't want them to be "uncomfortable" when using the
>Harmony class library - we want it to feel the same as when they use it
>from Sun...
>
>geir
>
>
>Mark Hindess wrote:
>> I thought my first message in this thread made this clear but
obviously
>not.
>>
>> I'm not suggesting that code would care if the exception messages are
>> identical.  I was suggesting that it is probably now quite common for
>> users to type error messages straight in to google.  Therefore having
>> messages match those of existing implementations would help our users
>> find the cause of an exception.
>>
>> Regards,
>>  Mark.
>>
>> On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:
>>> On Tuesday 18 April 2006 09:37, Mark Hindess wrote:
 Are you saying that Classpath does match strings in exceptions?
>>> No. Ah, I see: the "do" in Geir's question stood for "what is
>Classpath's
>>> policy wrt to exception messages matching those of the RI?". Then I
>don't
>>> speak authoritatively, but I've never noticed Classpath going out of
its
>way
>>> to be compatible at this level. But then I would never write code
which
>>> depended on the precise contents of an exception message ...
>>>
>>> Sorry for the confusion,
>>>
>>> Chris
>>>
>>> --
>>> Chris Gray/k/ Embedded Java Solutions  BE0503765045
>>> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
>>> [EMAIL PROTECTED] +32 3 216 0369
>>>
>>>
>>>
-
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>>
>>>
>>
>>
>> --
>> Mark Hindess <[EMAIL PROTECTED]>
>> IBM Java Technology Centre, UK.
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>
>>
>
>-
>Terms of use : http://incubator.apache.org/harmony/mailing.html
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Richard Liang]

Geir Magnusson Jr wrote:

Wait - no tabs!  no tabs!  PLEASE!

You can have your 1,743 character test case names if you want, but NO 
TABS! :)


geir

Mark Hindess wrote:

Stepan,

Just curious what you are fixing here?  Changing 8 spaces to tabs?
Why does this matter?  Shouldn't tabs (at the beginning of a line)
always be equivalent to 8 spaces?

Incidentally, I think 8 character indentations are excessive.  Quite a
few of the ant files use 4 character indentations which I find much
easier to read.  Ditto for java code.  Perhaps we could agree which to
use?

Regards,
-Mark - wondering if he might regret asking this

On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: smishura
Date: Tue Apr 18 02:38:29 2006
New Revision: 394890

URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
Log:
Correcting indentation

Modified:

incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml 


incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml 



Modified: 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 

URL: 
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff 

== 

--- 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 
(original)
+++ 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 
Tue Apr 18 02:38:29 2006

@@ -68,12 +68,12 @@



-
-   
+
+   

value="${hy.target}/jre" />


-   

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



+1. But are there any way to release our pain from TABs? :-)

--
Richard Liang
China Software Development Lab, IBM 




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (HARMONY-88) Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security

[Richard Liang]

Mikhail Loenko wrote:

I've integrated beans tests. I removed odd-looking
package 'sun.beans'.

Some [excluded] tests fail. Patches are welcome

Is there anything remained from H-88?
  

Hello Mikhail,

I think all code is in SVN. :-)

Thanks,
Mikhail

2006/4/17, Richard Liang <[EMAIL PROTECTED]>:
  

Mikhail Loenko wrote:


Hi Richard

Do you know, why these beans tests contain package 'sun.beans'?
What kind of classes are there?

Thanks,
Mikhail

2006/4/17, Richard Liang <[EMAIL PROTECTED]>:

  

Mikhail Loenko (JIRA) wrote:



[ 
http://issues.apache.org/jira/browse/HARMONY-88?page=comments#action_12373811 ]

Mikhail Loenko commented on HARMONY-88:
---

auth, crypto, and security parts integrated in revision 392891




  

Hello,

Beans tests are not in SVN yet. :-)



Contribution of  code and unit tests for jndi, logging, prefs and sql plus unit 
tests only for beans, crypto, math, regex and security
--

 Key: HARMONY-88
 URL: http://issues.apache.org/jira/browse/HARMONY-88
 Project: Harmony
Type: New Feature



  Components: Contributions

 Environment: Win32 and Linux
Reporter: George Harley
Assignee: Mikhail Loenko
 Attachments: 01.crypto.and.security.test.integration.sh, 
01.harmony.88.integration.sh, 01.harmony.88.integration.sh, 
02.crypto.and.security.test.integration.diff, 02.harmony.88.integration.diff, 
02.harmony.88.integration.diff, Harmony-Contribution.zip

Zip file containing implementation and unit test code for the following Harmony
components :
* jndi
* logging
* prefs
* sql
In addition there is unit test code only for the following Harmony components :
* beans
* crypto
* math
* regex
* security
The contents of this zip have been laid out with the current classlib directory
structure of the Apache Harmony SVN repository in mind. A version of
enhanced/classlib/trunk/make/build-java.xml is included containing new Ant
targets to compile the new implementation plus tests code, and then run the
tests.
Native code, plus makefiles are included to build a shared library that is
required to support the prefs implementation on the win.IA32 platform.
Not all of the unit test classes are capable of being compiled when the Ant
target "compile-tests" in /Harmony/make/build-java.xml is run. This
is because the current contents of the Harmony trunk do not satisfy all of the
dependencies of some classes. This issue affects the unit test code for the
following set of components ...
* beans (needs beans implementation in trunk)
* crypto (needs crypto implementation in trunk)
* logging (needs beans implementation in trunk)
* jndi (needs applet implementation in trunk)
* sql (needs rmi implementation in trunk)
As a temporary measure, the lines of Ant script in
/Harmony/make/build-java.xml that compile the above test code
have been commented out with explanations.




--
Richard Liang
China Software Development Lab, IBM






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  

Hello,

These test cases are used to test if the beans implementation can load
user-defined BeanInfos and PropertyEditors of which default location is
"sun.beans" in RI. IMHO,  these test cases are unnecessary. Because
it's said "The default value is implementation-dependent". Any comments?
Thanks a lot. :-)

You may wan to refer to the spec of
java.beans.PropertyEditorManager.getEditorSearchPath:

   /*Returns:*/
   /The array of package names that will be searched in order to
   find property editors. /

   / The default value for this array is implementation-dependent,
   e.g. Sun implementation initially sets to {"sun.beans.editors"}./




and java.beans.Introspector.getBeanInfoSearchPath

   /*Returns:*/
   /The array of package names that will be searched in order to
   find BeanInfo classes. The default value for this array is
   implementation-dependent; e.g. Sun implementation initially sets
   to {"sun.beans.infos"}./


--
Richard Liang
China Software Development Lab, IBM






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
Richard Liang
China Software Development Lab, IBM 

Summer Of Code 2006 - Lets get Harmony involved

[Geir Magnusson Jr]

Google again is running their "Summer Of Code" 
http://code.google.com/summerofcode.html program, and I think it would 
be great for the Harmony project to take advantage of it, assuming we 
can find willing students.


If you are unfamiliar with the program, the goal is to allow computer 
science students to work in their chosen field during the summer while 
at the same time assisting open source organizations and projcets.  The 
idea is that students and mentors propose and deliver completed projects 
 in open source.  For this, the student is paid a stipend. 
Additionally, the mentor receives a small stipend as well.


In our case, the official mentor will be the ASF.

There is an ASF wiki site for this :

http://wiki.apache.org/general/SummerOfCode2006

Lets agree on projects here first.

Ideas?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Geir Magnusson Jr]

Mark Hindess wrote:

Stepan,

Sorry.  I didn't mean to blame you.  I did realise that you were just
putting it back to the "initial" style.

Since you asked (well almost ;-) I'm in favour of 4 space indent since
this is quite common in the java code.  Unlike Geir I don't mind if
tabs are used but they should always be treated as being equivalent to
8 spaces.  Though I'd might change my mind if I understood the
motivation behind Geir's aversion to tabs.


They just lead to pain.

Spaces makes it format the same everywhere, and people don't mistakenly 
use tabs to format, resulting in distortion for other people.  You can 
train any reasonably modern IDE/editor to convert tabs to spaces, so you 
can use the tab key (set it at 4 spaces).  As a developer, you don't 
know the difference - hit the tab key to your hearts content - and we 
then all live in harmony :)


The assumption is we agree on a format style (4 spaces for indent)

geir



Regards,
 Mark.

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:

Mark,

The update only adjusts build files to *initial* style (that is tabs-style).

IMHO really doesn't matter how many spaces in one tab if you follow one
style in a file and don't mix tabs with spaces. Also I like
tab-style because I have opportunity to choose a number of spaces that more
suitable for my eyes. If everybody will agree to use only space-style then
OK - I'll fix tabs.

Thanks,
Stepan.


On 4/18/06, Mark Hindess wrote:

For many people however tabs are equivalent to 8 spaces so if what we
really intend is 4 spaces then perhaps we should make them spaces not
tabs?

Otherwise we will be forever fixing identations because of editor
differences.

-Mark.

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:

On 4/18/06, Mark Hindess wrote:

Stepan,

Just curious what you are fixing here?  Changing 8 spaces to tabs?
Why does this matter?  Shouldn't tabs (at the beginning of a line)
always be equivalent to 8 spaces?


Mark,

I'd prefer to have all build files follow one style - I don't like

mixing

tabs and spaces even they looks the same. For this particular case -

build

files were initially created using tabs and I'd prefer to keep this

style.

Also for me tab is not equivalent to 8 spaces - Eclipse sets tab

equivalent

to 4 spaces and I'm not going to change it because I like it :-)

Thanks,
Stepan.

Incidentally, I think 8 character indentations are excessive.  Quite a

few of the ant files use 4 character indentations which I find much
easier to read.  Ditto for java code.  Perhaps we could agree which to
use?

Regards,
-Mark - wondering if he might regret asking this

On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: smishura
Date: Tue Apr 18 02:38:29 2006
New Revision: 394890

URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
Log:
Correcting indentation

Modified:


incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml

Modified:

incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml

URL:

http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
==

---

incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml

(original)

+++

incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml

Tue Apr 18 02:38:29 2006

@@ -68,12 +68,12 @@



-
-   
+
+   


}/jre"

/>

- 

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Mark Hindess]

Stepan,

Sorry.  I didn't mean to blame you.  I did realise that you were just
putting it back to the "initial" style.

Since you asked (well almost ;-) I'm in favour of 4 space indent since
this is quite common in the java code.  Unlike Geir I don't mind if
tabs are used but they should always be treated as being equivalent to
8 spaces.  Though I'd might change my mind if I understood the
motivation behind Geir's aversion to tabs.

Regards,
 Mark.

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> Mark,
>
> The update only adjusts build files to *initial* style (that is tabs-style).
>
> IMHO really doesn't matter how many spaces in one tab if you follow one
> style in a file and don't mix tabs with spaces. Also I like
> tab-style because I have opportunity to choose a number of spaces that more
> suitable for my eyes. If everybody will agree to use only space-style then
> OK - I'll fix tabs.
>
> Thanks,
> Stepan.
>
>
> On 4/18/06, Mark Hindess wrote:
> >
> > For many people however tabs are equivalent to 8 spaces so if what we
> > really intend is 4 spaces then perhaps we should make them spaces not
> > tabs?
> >
> > Otherwise we will be forever fixing identations because of editor
> > differences.
> >
> > -Mark.
> >
> > On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > > On 4/18/06, Mark Hindess wrote:
> > > >
> > > > Stepan,
> > > >
> > > > Just curious what you are fixing here?  Changing 8 spaces to tabs?
> > > > Why does this matter?  Shouldn't tabs (at the beginning of a line)
> > > > always be equivalent to 8 spaces?
> > >
> > >
> > > Mark,
> > >
> > > I'd prefer to have all build files follow one style - I don't like
> > mixing
> > > tabs and spaces even they looks the same. For this particular case -
> > build
> > > files were initially created using tabs and I'd prefer to keep this
> > style.
> > > Also for me tab is not equivalent to 8 spaces - Eclipse sets tab
> > equivalent
> > > to 4 spaces and I'm not going to change it because I like it :-)
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > Incidentally, I think 8 character indentations are excessive.  Quite a
> > > > few of the ant files use 4 character indentations which I find much
> > > > easier to read.  Ditto for java code.  Perhaps we could agree which to
> > > > use?
> > > >
> > > > Regards,
> > > > -Mark - wondering if he might regret asking this
> > > >
> > > > On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > > Author: smishura
> > > > > Date: Tue Apr 18 02:38:29 2006
> > > > > New Revision: 394890
> > > > >
> > > > > URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> > > > > Log:
> > > > > Correcting indentation
> > > > >
> > > > > Modified:
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> > > > >
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
> > > > >
> > > > > Modified:
> > > >
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > > > URL:
> > > >
> > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> > > > >
> > > >
> > ==
> > 

Re: [jira] Commented: (HARMONY-88) Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security

[Mikhail Loenko]

I've integrated beans tests. I removed odd-looking
package 'sun.beans'.

Some [excluded] tests fail. Patches are welcome

Is there anything remained from H-88?

Thanks,
Mikhail

2006/4/17, Richard Liang <[EMAIL PROTECTED]>:
> Mikhail Loenko wrote:
> > Hi Richard
> >
> > Do you know, why these beans tests contain package 'sun.beans'?
> > What kind of classes are there?
> >
> > Thanks,
> > Mikhail
> >
> > 2006/4/17, Richard Liang <[EMAIL PROTECTED]>:
> >
> >> Mikhail Loenko (JIRA) wrote:
> >>
> >>> [ 
> >>> http://issues.apache.org/jira/browse/HARMONY-88?page=comments#action_12373811
> >>>  ]
> >>>
> >>> Mikhail Loenko commented on HARMONY-88:
> >>> ---
> >>>
> >>> auth, crypto, and security parts integrated in revision 392891
> >>>
> >>>
> >>>
> >>>
> >> Hello,
> >>
> >> Beans tests are not in SVN yet. :-)
> >>
>  Contribution of  code and unit tests for jndi, logging, prefs and sql 
>  plus unit tests only for beans, crypto, math, regex and security
>  --
> 
>   Key: HARMONY-88
>   URL: http://issues.apache.org/jira/browse/HARMONY-88
>   Project: Harmony
>  Type: New Feature
> 
> 
> >>>
>    Components: Contributions
>   Environment: Win32 and Linux
>  Reporter: George Harley
>  Assignee: Mikhail Loenko
>   Attachments: 01.crypto.and.security.test.integration.sh, 
>  01.harmony.88.integration.sh, 01.harmony.88.integration.sh, 
>  02.crypto.and.security.test.integration.diff, 
>  02.harmony.88.integration.diff, 02.harmony.88.integration.diff, 
>  Harmony-Contribution.zip
> 
>  Zip file containing implementation and unit test code for the following 
>  Harmony
>  components :
>  * jndi
>  * logging
>  * prefs
>  * sql
>  In addition there is unit test code only for the following Harmony 
>  components :
>  * beans
>  * crypto
>  * math
>  * regex
>  * security
>  The contents of this zip have been laid out with the current classlib 
>  directory
>  structure of the Apache Harmony SVN repository in mind. A version of
>  enhanced/classlib/trunk/make/build-java.xml is included containing new 
>  Ant
>  targets to compile the new implementation plus tests code, and then run 
>  the
>  tests.
>  Native code, plus makefiles are included to build a shared library that 
>  is
>  required to support the prefs implementation on the win.IA32 platform.
>  Not all of the unit test classes are capable of being compiled when the 
>  Ant
>  target "compile-tests" in /Harmony/make/build-java.xml is 
>  run. This
>  is because the current contents of the Harmony trunk do not satisfy all 
>  of the
>  dependencies of some classes. This issue affects the unit test code for 
>  the
>  following set of components ...
>  * beans (needs beans implementation in trunk)
>  * crypto (needs crypto implementation in trunk)
>  * logging (needs beans implementation in trunk)
>  * jndi (needs applet implementation in trunk)
>  * sql (needs rmi implementation in trunk)
>  As a temporary measure, the lines of Ant script in
>  /Harmony/make/build-java.xml that compile the above test 
>  code
>  have been commented out with explanations.
> 
> 
> >>>
> >> --
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >>
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> Hello,
>
> These test cases are used to test if the beans implementation can load
> user-defined BeanInfos and PropertyEditors of which default location is
> "sun.beans" in RI. IMHO,  these test cases are unnecessary. Because
> it's said "The default value is implementation-dependent". Any comments?
> Thanks a lot. :-)
>
> You may wan to refer to the spec of
> java.beans.PropertyEditorManager.getEditorSearchPath:
>
>/*Returns:*/
>/The array of package names that will be searched in order to
>find property editors. /
>
>/ The default value for this array is implementation-dependent,
>e.g. Sun implementation initially sets to {"sun.beans.editors"}./
>
>
>
>
> and java.beans.Introspector.getBeanInfoSearchPath
>
>/*Returns:*/
>/The array of package names that will be searched in order to
>find BeanInfo classes. The default value for this array is
>implementation-dependent; e.g. Sun implementation initially sets
>to {"sun.beans.infos"}./
>
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>

--

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Etienne Gagnon]

+1 too.

Mikhail Loenko wrote:
> +1
> 
> 2006/4/18, Geir Magnusson Jr <[EMAIL PROTECTED]>:
> 
>>Wait - no tabs!  no tabs!  PLEASE!
>>
>>You can have your 1,743 character test case names if you want, but NO
>>TABS! :)

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [jira] Commented: (HARMONY-290) Incorrect SerialVersionUID in java.lang.*

[Etienne Gagnon]

Ah!  OK.  I should have looked more carefully.

Thanks,

Etienne

Mikhail Loenko wrote:
> I did not close the issue, as you asked.
> 

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [jira] Commented: (HARMONY-290) Incorrect SerialVersionUID in java.lang.*

[Etienne Gagnon]

Of course.

Etienne

Geir Magnusson Jr wrote:
> to contribute them?
> 

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Mikhail Loenko]

+1

2006/4/18, Geir Magnusson Jr <[EMAIL PROTECTED]>:
> Wait - no tabs!  no tabs!  PLEASE!
>
> You can have your 1,743 character test case names if you want, but NO
> TABS! :)
>
> geir
>
> Mark Hindess wrote:
> > Stepan,
> >
> > Just curious what you are fixing here?  Changing 8 spaces to tabs?
> > Why does this matter?  Shouldn't tabs (at the beginning of a line)
> > always be equivalent to 8 spaces?
> >
> > Incidentally, I think 8 character indentations are excessive.  Quite a
> > few of the ant files use 4 character indentations which I find much
> > easier to read.  Ditto for java code.  Perhaps we could agree which to
> > use?
> >
> > Regards,
> > -Mark - wondering if he might regret asking this
> >
> > On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> Author: smishura
> >> Date: Tue Apr 18 02:38:29 2006
> >> New Revision: 394890
> >>
> >> URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> >> Log:
> >> Correcting indentation
> >>
> >> Modified:
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> >> 
> >> incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
> >>
> >> Modified: 
> >> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> >> URL: 
> >> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> >> ==
> >> --- 
> >> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> >>  (original)
> >> +++ 
> >> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> >>  Tue Apr 18 02:38:29 2006
> >> @@ -68,12 +68,12 @@
> >>
> >>
> >> 
> >> -
> >> -   
> >> +
> >> +   
> >>
> >> 
> >>
> >> ->> +>> forkmode="once"
> >> printsummary="withOutAndErr"
> >> errorproperty="test.errors"
> >>
> >> [ SNIP ]
> >
> > --
> > Mark Hindess <[EMAIL PROTECTED]>
> > IBM Java Technology Centre, UK.
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (HARMONY-290) Incorrect SerialVersionUID in java.lang.*

[Mikhail Loenko]

I did not close the issue, as you asked.

Thanks,
Mikhail

2006/4/18, Etienne Gagnon <[EMAIL PROTECTED]>:
> Hi Mikhail,
>
> I guess I'll have to open a new report for the unit tests, right?
>
> Etienne
>
> Mikhail Loenko (JIRA) wrote:
> > [ 
> > http://issues.apache.org/jira/browse/HARMONY-290?page=comments#action_12374906
> >  ]
> >
> > Mikhail Loenko commented on HARMONY-290:
> > 
> >
> > fixed in revision 394917
>
> --
> Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
> SableVM:   http://www.sablevm.org/
> SableCC:   http://www.sablecc.org/
>
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (HARMONY-290) Incorrect SerialVersionUID in java.lang.*

[Geir Magnusson Jr]

to contribute them?

Etienne Gagnon wrote:

Hi Mikhail,

I guess I'll have to open a new report for the unit tests, right?

Etienne

Mikhail Loenko (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-290?page=comments#action_12374906 ] 


Mikhail Loenko commented on HARMONY-290:


fixed in revision 394917




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Geir Magnusson Jr]

Wait - no tabs!  no tabs!  PLEASE!

You can have your 1,743 character test case names if you want, but NO 
TABS! :)


geir

Mark Hindess wrote:

Stepan,

Just curious what you are fixing here?  Changing 8 spaces to tabs?
Why does this matter?  Shouldn't tabs (at the beginning of a line)
always be equivalent to 8 spaces?

Incidentally, I think 8 character indentations are excessive.  Quite a
few of the ant files use 4 character indentations which I find much
easier to read.  Ditto for java code.  Perhaps we could agree which to
use?

Regards,
-Mark - wondering if he might regret asking this

On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: smishura
Date: Tue Apr 18 02:38:29 2006
New Revision: 394890

URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
Log:
Correcting indentation

Modified:

incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml

Modified: 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
URL: 
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
==
--- 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 
(original)
+++ 
incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml 
Tue Apr 18 02:38:29 2006
@@ -68,12 +68,12 @@



-
-   
+
+   



-   

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Geir Magnusson Jr]

This aspect is easy.  I'll just ask Sun.

geir


Anton Avtamonov wrote:

On 4/18/06, Mark Hindess <[EMAIL PROTECTED]> wrote:

I thought my first message in this thread made this clear but obviously not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.


Yes, right. I saw several times like people did that and even did by
myself for javac.

If I remember we decided not to copy the mesages because it is
*possibly* a legal isssue and maybe copyrightable. Is it possible to
ask apache legal? Probably the answer will solve our problems :-).

Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Geir Magnusson Jr]

Yes - great example.  The point is for mechanical means, but familiarity 
for users - we don't want them to be "uncomfortable" when using the 
Harmony class library - we want it to feel the same as when they use it 
from Sun...


geir


Mark Hindess wrote:

I thought my first message in this thread made this clear but obviously not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.

Regards,
 Mark.

On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:

On Tuesday 18 April 2006 09:37, Mark Hindess wrote:

Are you saying that Classpath does match strings in exceptions?

No. Ah, I see: the "do" in Geir's question stood for "what is Classpath's
policy wrt to exception messages matching those of the RI?". Then I don't
speak authoritatively, but I've never noticed Classpath going out of its way
to be compatible at this level. But then I would never write code which
depended on the precise contents of an exception message ...

Sorry for the confusion,

Chris

--
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Geir Magnusson Jr]

Chris Gray wrote:

On Tuesday 18 April 2006 04:20, Geir Magnusson Jr wrote:


Good question though - what does GNU Classpath do?


What GNU Classpath "does" is the same as what the Sun class libraries do, so 
the former no more needs the latter than Apache needs IIS ...


(Sorry to be playing the pedant but I do sometimes get the idea that Harmony 
is tearing ahead without ever stopping to ask about context, history, prior 
art ...)


That's ridiculous.  We're very concerned about all three, and I'd argue 
this is a question of context and prior art - the question was "What 
does GNU CLasspath do wrt message strings in exceptions in terms of 
similarity to the RI?"


geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Geir Magnusson Jr]

Chris Gray wrote:

On Tuesday 18 April 2006 01:34, Geir Magnusson Jr wrote:


Really?  Every other JRE uses the classlibrary from sun.


Of the many open-source runtimes, none uses Sun's class library; 


I'm aware of that - that's why we're here.  But as I understand it, 
there are no complete open source runtimes (SE anyway...)


almost all 
use Classpath. Among non-open source products, J9 has its own libraries,  and
I believe this is also true of many other embedded runtimes, e.g. Aonix's 
PERC (other companies which used to have their own class libraries are now 
Sun licencees, but are probably still using a lot of their own code for 
luni). Aicas sell a closed-source runtime which uses Classpath for its Java 
libraries.


That's interesting...

geir





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (HARMONY-290) Incorrect SerialVersionUID in java.lang.*

[Etienne Gagnon]

Hi Mikhail,

I guess I'll have to open a new report for the unit tests, right?

Etienne

Mikhail Loenko (JIRA) wrote:
> [ 
> http://issues.apache.org/jira/browse/HARMONY-290?page=comments#action_12374906
>  ] 
> 
> Mikhail Loenko commented on HARMONY-290:
> 
> 
> fixed in revision 394917

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Anton Avtamonov]

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> Mark,
>
> The update only adjusts build files to *initial* style (that is tabs-style).
>
> IMHO really doesn't matter how many spaces in one tab if you follow one
> style in a file and don't mix tabs with spaces. Also I like
> tab-style because I have opportunity to choose a number of spaces that more
> suitable for my eyes. If everybody will agree to use only space-style then
> OK - I'll fix tabs.

Stepan,
If it was a question I also vote for space-style. It guarantees same
look in all editors. I used to 4-spaces indentation.

--
Anton Avtamonov,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Stepan Mishura]

Mark,

The update only adjusts build files to *initial* style (that is tabs-style).

IMHO really doesn't matter how many spaces in one tab if you follow one
style in a file and don't mix tabs with spaces. Also I like
tab-style because I have opportunity to choose a number of spaces that more
suitable for my eyes. If everybody will agree to use only space-style then
OK - I'll fix tabs.

Thanks,
Stepan.


On 4/18/06, Mark Hindess wrote:
>
> For many people however tabs are equivalent to 8 spaces so if what we
> really intend is 4 spaces then perhaps we should make them spaces not
> tabs?
>
> Otherwise we will be forever fixing identations because of editor
> differences.
>
> -Mark.
>
> On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > On 4/18/06, Mark Hindess wrote:
> > >
> > > Stepan,
> > >
> > > Just curious what you are fixing here?  Changing 8 spaces to tabs?
> > > Why does this matter?  Shouldn't tabs (at the beginning of a line)
> > > always be equivalent to 8 spaces?
> >
> >
> > Mark,
> >
> > I'd prefer to have all build files follow one style - I don't like
> mixing
> > tabs and spaces even they looks the same. For this particular case -
> build
> > files were initially created using tabs and I'd prefer to keep this
> style.
> > Also for me tab is not equivalent to 8 spaces - Eclipse sets tab
> equivalent
> > to 4 spaces and I'm not going to change it because I like it :-)
> >
> > Thanks,
> > Stepan.
> >
> > Incidentally, I think 8 character indentations are excessive.  Quite a
> > > few of the ant files use 4 character indentations which I find much
> > > easier to read.  Ditto for java code.  Perhaps we could agree which to
> > > use?
> > >
> > > Regards,
> > > -Mark - wondering if he might regret asking this
> > >
> > > On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Author: smishura
> > > > Date: Tue Apr 18 02:38:29 2006
> > > > New Revision: 394890
> > > >
> > > > URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> > > > Log:
> > > > Correcting indentation
> > > >
> > > > Modified:
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> > > >
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
> > > >
> > > > Modified:
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > > URL:
> > >
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> > > >
> > >
> ==
> > > > ---
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > (original)
> > > > +++
> > >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > Tue Apr 18 02:38:29 2006
> > > > @@ -68,12 +68,12 @@
> > > >
> > > >
> > > > 
> > > > -
> > > > -   
> > > > +
> > > > +   
> > > >
> > > >  > > />
> > > >
> > > > -> > > +> > > forkmode="once"
> > > > printsummary="withOutAndErr"
> > > > errorproperty="test.errors"
> > > >
> > > > [ SNIP ]
> > >
> > > --
> > > Mark Hindess <[EMAIL PROTECTED]>
> > > IBM Java Technology Centre, UK.
> > >
> > > 

Re: should strings in exceptions match the reference implementation?

[Paulex Yang]

Mark Hindess wrote:

I thought my first message in this thread made this clear but obviously not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.
  

Well, I did miss this information I think, sorry for that.

Please correct me if my experience is wrong, in C/C++ world, error 
message is very important, it is often the only information to judge 
what's going on about the mistake, because the habits of c/c++ program 
is to define list of error codes and error messages, print the message 
and exit when some error codes returned. But Java application is another 
story, error message is still important but not so significant, because 
Java has exception hierarchy, and exception type itself is 
self-descriptive in many cases(I know, I know, naughty boys like 
SQLException are not unusual, but that's mostly because it wraps error 
message from DB server). Further we have JavaDoc to describe the 
exceptional case and relative exception, even for runtime exception if 
they are not so typical and self-descriptive. So I myself have lots of 
experience to search error messages for system call/compiler/db2 even 
JVM, but IMHO I have little experience to search error message for Java 
class library.


However, I have no objection that there are exceptional case, where the 
message is very important and should at least has similar keywords with 
RI's, SQLException is a good example, but it is enough to be clear and 
concise for the majority of exception messages.


Comments?

Regards,
 Mark.

On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:
  

On Tuesday 18 April 2006 09:37, Mark Hindess wrote:


Are you saying that Classpath does match strings in exceptions?
  

No. Ah, I see: the "do" in Geir's question stood for "what is Classpath's
policy wrt to exception messages matching those of the RI?". Then I don't
speak authoritatively, but I've never noticed Classpath going out of its way
to be compatible at this level. But then I would never write code which
depended on the precise contents of an exception message ...

Sorry for the confusion,

Chris

--
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (HARMONY-350) HARMONY-39 Regular expressions does not match backreferences during find.

[Loenko, Mikhail Y]

Nikolay,

please provide a single patch that resolves the problem

Thanks,
Mikhail 


>-Original Message-
>From: Nikolay Kuznetsov (JIRA) [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, April 18, 2006 5:04 PM
>To: [EMAIL PROTECTED]
>Subject: [jira] Commented: (HARMONY-350) HARMONY-39 Regular expressions
does not match
>backreferences during find.
>
>[
http://issues.apache.org/jira/browse/HARMONY-350?page=comments#action_12
374890 ]
>
>Nikolay Kuznetsov commented on HARMONY-350:
>---
>
>This fix and issue overall does not deal with indices in exceptions.
The problem here is that patch
>from HARMONY-352 interfere with this patch and result of the conflict
resolution lacks HARMONY-352
>fix for pattern(wich I'm concerned about, see H-352 for details).
>
>I can attach single patch for both problems H-350 and Pattern.java part
of the H-352 or, if it
>possible to commit this one as is, I can provide separate patch for
H-352 part of the problem.
>
>> HARMONY-39 Regular expressions does not match backreferences during
find.
>>

-
>>
>>  Key: HARMONY-350
>>  URL: http://issues.apache.org/jira/browse/HARMONY-350
>>  Project: Harmony
>> Type: Bug
>
>>   Components: Classlib
>>  Environment: All
>> Reporter: Nikolay Kuznetsov
>> Assignee: Mikhail Loenko
>> Priority: Minor
>>  Attachments: groups.diff
>>
>> For the optimization purposes match and find methods of HARMONY-39
regex works differently. One
>of the differences that cause some problems is that group boundaries
are being set in different
>time (onward, in case of match and on the way back in the case of
find). Thus back references "\1-
>9" won't work as expected in case of find method (because in case of
find boundaries are not yet
>set when back reference appears). The same problem appears if pattern
contains ".*", where we try
>to simulate find and face the same problem.
>> While fixing this problem the following simple issues was also found
and fixed:
>> - Empty constructs are not being processed correctly. The examples of
this construct are empty
>group(i.e. "()"), or empty alternation(i.e. "|") and combinations with
embedded flags, which do not
>match actual characters. In all cases HARMONY-39 engine throws
PatternSyntaxException instead of
>returning token representing empty construct.
>> - Boundaries where embedded flags are in effect are not correctly
processed:
>>   - Whitespaces being ignored after group which nested comment
flag;
>>   - Global embedded flags do not mix with local once;
>>   - Minus sign in embedded flags automatically removes case
insensitive flag;
>> The attached patch will address all mentioned above broblems.
>
>--
>This message is automatically generated by JIRA.
>-
>If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
>-
>For more information on JIRA, see:
>   http://www.atlassian.com/software/jira

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Paulex Yang]

Mark Hindess wrote:

For many people however tabs are equivalent to 8 spaces so if what we
really intend is 4 spaces then perhaps we should make them spaces not
tabs?
  
I agree that it is good practice to always use spaces instead of tabs. 
And AFAIK many editors(say, Eclipse, VI) can set this preference so that 
this requirement should not introduce too much effort to developers.

Otherwise we will be forever fixing identations because of editor differences.

-Mark.

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
  

On 4/18/06, Mark Hindess wrote:


Stepan,

Just curious what you are fixing here?  Changing 8 spaces to tabs?
Why does this matter?  Shouldn't tabs (at the beginning of a line)
always be equivalent to 8 spaces?
  

Mark,

I'd prefer to have all build files follow one style - I don't like mixing
tabs and spaces even they looks the same. For this particular case - build
files were initially created using tabs and I'd prefer to keep this style.
Also for me tab is not equivalent to 8 spaces - Eclipse sets tab equivalent
to 4 spaces and I'm not going to change it because I like it :-)

Thanks,
Stepan.

Incidentally, I think 8 character indentations are excessive.  Quite a


few of the ant files use 4 character indentations which I find much
easier to read.  Ditto for java code.  Perhaps we could agree which to
use?

Regards,
-Mark - wondering if he might regret asking this

On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
  

Author: smishura
Date: Tue Apr 18 02:38:29 2006
New Revision: 394890

URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
Log:
Correcting indentation

Modified:



incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
  
incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
  

Modified:


incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
  

URL:


http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
  
==
  

---


incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
(original)
  

+++


incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
Tue Apr 18 02:38:29 2006
  

@@ -68,12 +68,12 @@



-
-   
+
+   



/>
  

-   

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

--
---
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thanks,
Stepan Mishura
Intel Middleware Products Division






--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
Paulex Yang
China Software Development Lab
IBM

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Mark Hindess]

For many people however tabs are equivalent to 8 spaces so if what we
really intend is 4 spaces then perhaps we should make them spaces not
tabs?

Otherwise we will be forever fixing identations because of editor differences.

-Mark.

On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/18/06, Mark Hindess wrote:
> >
> > Stepan,
> >
> > Just curious what you are fixing here?  Changing 8 spaces to tabs?
> > Why does this matter?  Shouldn't tabs (at the beginning of a line)
> > always be equivalent to 8 spaces?
>
>
> Mark,
>
> I'd prefer to have all build files follow one style - I don't like mixing
> tabs and spaces even they looks the same. For this particular case - build
> files were initially created using tabs and I'd prefer to keep this style.
> Also for me tab is not equivalent to 8 spaces - Eclipse sets tab equivalent
> to 4 spaces and I'm not going to change it because I like it :-)
>
> Thanks,
> Stepan.
>
> Incidentally, I think 8 character indentations are excessive.  Quite a
> > few of the ant files use 4 character indentations which I find much
> > easier to read.  Ditto for java code.  Perhaps we could agree which to
> > use?
> >
> > Regards,
> > -Mark - wondering if he might regret asking this
> >
> > On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Author: smishura
> > > Date: Tue Apr 18 02:38:29 2006
> > > New Revision: 394890
> > >
> > > URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> > > Log:
> > > Correcting indentation
> > >
> > > Modified:
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> > >
> > incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
> > >
> > > Modified:
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > > URL:
> > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> > >
> > ==
> > > ---
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > (original)
> > > +++
> > incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > Tue Apr 18 02:38:29 2006
> > > @@ -68,12 +68,12 @@
> > >
> > >
> > > 
> > > -
> > > -   
> > > +
> > > +   
> > >
> > >  > />
> > >
> > > -> > +> > forkmode="once"
> > > printsummary="withOutAndErr"
> > > errorproperty="test.errors"
> > >
> > > [ SNIP ]
> >
> > --
> > Mark Hindess <[EMAIL PROTECTED]>
> > IBM Java Technology Centre, UK.
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> ---
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>


--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Stepan Mishura]

On 4/18/06, Mark Hindess wrote:
>
> Stepan,
>
> Just curious what you are fixing here?  Changing 8 spaces to tabs?
> Why does this matter?  Shouldn't tabs (at the beginning of a line)
> always be equivalent to 8 spaces?


Mark,

I'd prefer to have all build files follow one style - I don't like mixing
tabs and spaces even they looks the same. For this particular case - build
files were initially created using tabs and I'd prefer to keep this style.
Also for me tab is not equivalent to 8 spaces - Eclipse sets tab equivalent
to 4 spaces and I'm not going to change it because I like it :-)

Thanks,
Stepan.

Incidentally, I think 8 character indentations are excessive.  Quite a
> few of the ant files use 4 character indentations which I find much
> easier to read.  Ditto for java code.  Perhaps we could agree which to
> use?
>
> Regards,
> -Mark - wondering if he might regret asking this
>
> On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: smishura
> > Date: Tue Apr 18 02:38:29 2006
> > New Revision: 394890
> >
> > URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> > Log:
> > Correcting indentation
> >
> > Modified:
> >
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
> >
> > Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> > URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> >
> ==
> > ---
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> (original)
> > +++
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> Tue Apr 18 02:38:29 2006
> > @@ -68,12 +68,12 @@
> >
> >
> > 
> > -
> > -   
> > +
> > +   
> >
> >  />
> >
> > -> +> forkmode="once"
> > printsummary="withOutAndErr"
> > errorproperty="test.errors"
> >
> > [ SNIP ]
>
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
---
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thanks,
Stepan Mishura
Intel Middleware Products Division

Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi

[Mark Hindess]

Stepan,

Just curious what you are fixing here?  Changing 8 spaces to tabs?
Why does this matter?  Shouldn't tabs (at the beginning of a line)
always be equivalent to 8 spaces?

Incidentally, I think 8 character indentations are excessive.  Quite a
few of the ant files use 4 character indentations which I find much
easier to read.  Ditto for java code.  Perhaps we could agree which to
use?

Regards,
-Mark - wondering if he might regret asking this

On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: smishura
> Date: Tue Apr 18 02:38:29 2006
> New Revision: 394890
>
> URL: http://svn.apache.org/viewcvs?rev=394890&view=rev
> Log:
> Correcting indentation
>
> Modified:
> 
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/archive/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/awt/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/beans/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/jndi/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/logging/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/math/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/nio_char/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/prefs/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/regex/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/rmi/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/security/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/sql/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/text/make/common/build.xml
> 
> incubator/harmony/enhanced/classlib/trunk/modules/x-net/make/common/build.xml
>
> Modified: 
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
> URL: 
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml?rev=394890&r1=394889&r2=394890&view=diff
> ==
> --- 
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
>  (original)
> +++ 
> incubator/harmony/enhanced/classlib/trunk/modules/applet/make/common/build.xml
>  Tue Apr 18 02:38:29 2006
> @@ -68,12 +68,12 @@
>
>
> 
> -
> -   
> +
> +   
>
> 
>
> -+forkmode="once"
> printsummary="withOutAndErr"
> errorproperty="test.errors"
>
> [ SNIP ]

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Jimmy, Jing Lv]

>Anton Avtamonov wrote:

On 4/18/06, Mark Hindess <[EMAIL PROTECTED]> wrote:

I thought my first message in this thread made this clear but obviously not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.




Er... that really matters. So shall we start write a list of such 
messages and give a little more information, and then put it on webpages 
or wiki, and then as a result, every user of Harmony get a result if he 
google? There can be more solutions.


However it can not be the reason that we should match the string with 
RI, as many user also copy exception track trace to google, so there'll 
be com.ibm... or com.sun... or something else if they use RI, Harmony 
shall never match them, right? :)



Yes, right. I saw several times like people did that and even did by
myself for javac.

If I remember we decided not to copy the mesages because it is
*possibly* a legal isssue and maybe copyrightable. Is it possible to
ask apache legal? Probably the answer will solve our problems :-).


That's the point. Agree.



Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Anton Avtamonov]

On 4/18/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> I thought my first message in this thread made this clear but obviously not.
>
> I'm not suggesting that code would care if the exception messages are
> identical.  I was suggesting that it is probably now quite common for
> users to type error messages straight in to google.  Therefore having
> messages match those of existing implementations would help our users
> find the cause of an exception.

Yes, right. I saw several times like people did that and even did by
myself for javac.

If I remember we decided not to copy the mesages because it is
*possibly* a legal isssue and maybe copyrightable. Is it possible to
ask apache legal? Probably the answer will solve our problems :-).

Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ?Pascua s en el siglo XXI?

[Leo Simons]

On Mon, Apr 17, 2006 at 07:37:47PM -0400, Geir Magnusson Jr wrote:
> Fernando Cassia wrote:
> >What the
> >
> >Is there a way to moderate harmont-dev so messages like this can never make
> >it to the list?.
> 
> They only way that would get to the list is if the sender was 
> subscribed.  We don't let unsubscribed people post, and there is no 
> moderator decision point.

Here's a guess: a subscriber to this mailing list has had his machine turned
into a spambot.

> Are you sure your mail client didn't fool you?  it was spammed to a lot 
> of places, and there could be another list/address in the TO: list, and 
> your mail client chose to route to your harmony-dev folder/mailbox/etc?

This one definitely came through all our filters - or they're getting
*really* good at spoofing.

LSD

--
Received: (qmail 48737 invoked by uid 500); 16 Apr 2006 11:18:40 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Help: 
List-Unsubscribe: 
List-Post: 
List-Id: 
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 48724 invoked by uid 99); 16 Apr 2006 11:18:40 -
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Apr 2006 04:18:40 -0700
X-ASF-Spam-Status: No, hits=0.5 required=10.0
tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [64.76.126.84] (HELO smtp2.tparg.com) (64.76.126.84)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Apr 2006 04:18:38 -0700
Received: from pepe.grillo ([172.18.0.91]) by smtp2.tparg.com with Microsoft 
SMTPSVC(5.0.2195.6713);
 Sun, 16 Apr 2006 08:18:09 -0300
Received: (qmail 14281 invoked by uid 107); 16 Apr 2006 11:48:59 -
Received: from unknown (HELO arg05b667) (172.18.4.142)
  by mail.teleperformance.com.ar with SMTP; 16 Apr 2006 11:48:59 -
Message-ID: <[EMAIL PROTECTED]>


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Mark Hindess]

I thought my first message in this thread made this clear but obviously not.

I'm not suggesting that code would care if the exception messages are
identical.  I was suggesting that it is probably now quite common for
users to type error messages straight in to google.  Therefore having
messages match those of existing implementations would help our users
find the cause of an exception.

Regards,
 Mark.

On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:
> On Tuesday 18 April 2006 09:37, Mark Hindess wrote:
> > Are you saying that Classpath does match strings in exceptions?
>
> No. Ah, I see: the "do" in Geir's question stood for "what is Classpath's
> policy wrt to exception messages matching those of the RI?". Then I don't
> speak authoritatively, but I've never noticed Classpath going out of its way
> to be compatible at this level. But then I would never write code which
> depended on the precise contents of an exception message ...
>
> Sorry for the confusion,
>
> Chris
>
> --
> Chris Gray/k/ Embedded Java Solutions  BE0503765045
> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
> [EMAIL PROTECTED] +32 3 216 0369
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Chris Gray]

On Tuesday 18 April 2006 09:37, Mark Hindess wrote:
> Are you saying that Classpath does match strings in exceptions?

No. Ah, I see: the "do" in Geir's question stood for "what is Classpath's 
policy wrt to exception messages matching those of the RI?". Then I don't 
speak authoritatively, but I've never noticed Classpath going out of its way 
to be compatible at this level. But then I would never write code which 
depended on the precise contents of an exception message ...

Sorry for the confusion,

Chris

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Mark Hindess]

Are you saying that Classpath does match strings in exceptions?

-Mark.


On 4/18/06, Chris Gray <[EMAIL PROTECTED]> wrote:
> On Tuesday 18 April 2006 04:20, Geir Magnusson Jr wrote:
>
> > Good question though - what does GNU Classpath do?
>
> What GNU Classpath "does" is the same as what the Sun class libraries do, so
> the former no more needs the latter than Apache needs IIS ...
>
> (Sorry to be playing the pedant but I do sometimes get the idea that Harmony
> is tearing ahead without ever stopping to ask about context, history, prior
> art ...)
>
> Chris
>
> --
> Chris Gray/k/ Embedded Java Solutions  BE0503765045
> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
> [EMAIL PROTECTED] +32 3 216 0369
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: should strings in exceptions match the reference implementation?

[Chris Gray]

On Tuesday 18 April 2006 04:20, Geir Magnusson Jr wrote:

> Good question though - what does GNU Classpath do?

What GNU Classpath "does" is the same as what the Sun class libraries do, so 
the former no more needs the latter than Apache needs IIS ...

(Sorry to be playing the pedant but I do sometimes get the idea that Harmony 
is tearing ahead without ever stopping to ask about context, history, prior 
art ...)

Chris

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]