Re: Re: [general] TLP transition - site has been moved, redirect in place
Yay! We finally made it :-) Alex. On 16/11/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Jimmy, Jing Lv wrote: > Geir Magnusson Jr. wrote: >> We now have a site >> >> http://harmony.apache.org/ >> >> and there's a redirect from >> >> http://incubator.apache.org/harmony/ >> >> to there. >> >> Tomorrow sometime we'll do the mail switch - that should be totally >> transparent - new lists will be created, sub lists will be copied, >> and mail going to old will be forwarded to new. I'll have the >> website setup before hand, do the switch, and then update the site. >> >> Also, Friday night eastern we'll do the SVN switch to avoid catching >> people in the middle of work (ok, some will still be caught...). A >> simple svn switch will fix your local copy, so you shouldn't have to >> re-check anything out. >> >> JIRA has been re-categorized, and I'll be asking for a solaris zone >> to play in. >> >> >> > And hope it will be soon that Harmony appears in the list of "Apache > Projects" in the homepage "http://www.apache.org/"; :) > I see it there now - woohoo! Good work everyone :) Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited
Re: Re: Re: Re: [classlib][pack200] Status update
On 14/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Aha, I see. But in JDBC you can at least call Class.forName(MyJDBCDriverClass, true, *MyClassLoader*). Well, you'll also be able to instantiate the Pack200 Harmony code using direct instantiation like that too. In fact, it will be necessary to do this if you want to use it to run against a (non-Harmony) JRE prior to 1.5, because there weren't the factory classes in those VMs :-) I'd imagine that most people who end up using the code will be directly instantiating it to avoid a dependency on Java 1.5, or of course using it inside Harmony :-) Alex.
Re: Re: Re: [classlib][pack200] Status update
No, it's a bug (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723). Also note that the list of packages that are listed at the URL you gave specify the full set of packages that can be overridden, and the pack200 classes aren't on there :-) The Pack200 stuff is supposed to be like the JDBC stuff, in that you should be able to substitute different implementations at a later stage. The problem with the current implementation is that the factory is loaded via the system classloader rather than the context classloader (mainly because it's a static method, I think) and thus the bootclasspath is the only one that has been changed. In any case, ideally you'd want to be able to substitute a different implementation without having to do special things on the classpath, either via the bootclasspath or endorsed directories, in order to deploy it with your own VM or applications. Alex. On 13/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > Oh, and I've discovered that the default Sun implementation doesn't > actually allow you to replace it with another implementation unless > it's on the boot classpath. Have you tried endorsed dirs "-Djava.endorsed.dirs=..." [1]? Seems it was specially designed for this purpose. [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html Regards, 2006/11/11, Alex Blewitt <[EMAIL PROTECTED]>: > A call of frustration at times perhaps :-) > > It's going along. I'm hoping to get to a stage where I can get a > better patch together and get it into the harmony subversion codebase > in the near future. But sometimes it's just slow progress. > > One thing I'd like to get sorted is moving the pack200 code into its > own module in the near future, perhaps after the next patch bomb. > > Oh, and I've discovered that the default Sun implementation doesn't > actually allow you to replace it with another implementation unless > it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug > with Sun: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 > > We should ensure that it doesn't happen with Harmony too :-) > > Alex. > > On 10/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Thanks for the update Alex. I assume from this description (and please > > don't take this the wrong way) that you are happy to be left alone to > > work on this for the moment, rather than it be read as a call for help? > > > > Keep up the good work. > > Tim > > > > Alex Blewitt wrote: > > > I'm still lurking around in the background, but I'm busier than ever > > > what with having to keep posting at EclipseZone where I'm editor now > > > ... but I'm still managing to plod along with the Pack200 code. The > > > last patch (1994, IIRC) went down pretty badly; the subclipse plugin > > > didn't seem to capture all the newly created classes that I had put > > > together for a bit of refactoring that I did. It's also a nightmare > > > submitting newly created files; once they've been uploaded to JIRA > > > into the patch queue, I effectively have to stop work until they're > > > applied, because there's no way of getting SVN to figure out that the > > > file called ClassFile.java is the same as the ClassFile.java that's > > > been added by someone else on my behalf, and I have to overwrite my > > > local copy to update. Kinda prevents doing any sensible work on newly > > > created files between submission and application to be honest. > > > > > > Instead, I plan to sprint (well, jog, at least) to the next stable > > > point, and then upload a whole wodge of code and leave it for a week > > > or two to be applied before picking up again. I'm fairly close to > > > being at that stage, but not quite. Where I am at is being able to > > > generate (abstract) methods with exceptions and fields with constant > > > (integer) values, so a bit further forward than last time. On the one > > > hand, it means that I understand what needs to be done (no mean feat!) > > > but on the other hand, there's still a fair bit to go. For a start, > > > I'm going to need to process the actual bytecode for non-abstract > > > methods (or indeed, any classes) before there's any point in it trying > > > to be used for real, and there's still a few missing bits (Longs, > > > Doubles, Floats) from the constant pools. I'm pretty sure Strings > > > would work, but I've not tried them yet. > > > > > > Unfortunately, the code
Re: Re: [classlib][pack200] Status update
A call of frustration at times perhaps :-) It's going along. I'm hoping to get to a stage where I can get a better patch together and get it into the harmony subversion codebase in the near future. But sometimes it's just slow progress. One thing I'd like to get sorted is moving the pack200 code into its own module in the near future, perhaps after the next patch bomb. Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug with Sun: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 We should ensure that it doesn't happen with Harmony too :-) Alex. On 10/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Thanks for the update Alex. I assume from this description (and please don't take this the wrong way) that you are happy to be left alone to work on this for the moment, rather than it be read as a call for help? Keep up the good work. Tim Alex Blewitt wrote: > I'm still lurking around in the background, but I'm busier than ever > what with having to keep posting at EclipseZone where I'm editor now > ... but I'm still managing to plod along with the Pack200 code. The > last patch (1994, IIRC) went down pretty badly; the subclipse plugin > didn't seem to capture all the newly created classes that I had put > together for a bit of refactoring that I did. It's also a nightmare > submitting newly created files; once they've been uploaded to JIRA > into the patch queue, I effectively have to stop work until they're > applied, because there's no way of getting SVN to figure out that the > file called ClassFile.java is the same as the ClassFile.java that's > been added by someone else on my behalf, and I have to overwrite my > local copy to update. Kinda prevents doing any sensible work on newly > created files between submission and application to be honest. > > Instead, I plan to sprint (well, jog, at least) to the next stable > point, and then upload a whole wodge of code and leave it for a week > or two to be applied before picking up again. I'm fairly close to > being at that stage, but not quite. Where I am at is being able to > generate (abstract) methods with exceptions and fields with constant > (integer) values, so a bit further forward than last time. On the one > hand, it means that I understand what needs to be done (no mean feat!) > but on the other hand, there's still a fair bit to go. For a start, > I'm going to need to process the actual bytecode for non-abstract > methods (or indeed, any classes) before there's any point in it trying > to be used for real, and there's still a few missing bits (Longs, > Doubles, Floats) from the constant pools. I'm pretty sure Strings > would work, but I've not tried them yet. > > Unfortunately, the code is really awful. The Segment.java is getting > on for 1500 lines of code in a single class; and the attribute parsing > contains both duplicated code and isn't as generic as it needs to be > to handle other attributes; and the (in)visible annotations like > @Overrides and similar are going to be a bit of a nightmare ... > > My plan is to get the code to a stage where it can start to be useful > for extracting simple classes from a pack file, and then start > generating test data which can be used for regressions. (There's a bit > there at the moment, but it's not exactly a large coverage.) Once I've > done that, I'll start tackling some of the refactoring which will > result in less duplicated code and hopefully something that will be > easier to look after in the future. > > Anyway, excuse the long rambling but I've been a bit quiet for a while > and wanted to let people know I was still alive and kicking the code > :-) > > Alex. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Harmony passes all tests of Maven 2.0.4
Cool! These kind of things really help to show what Harmony is capable of. Alex. On 10/11/06, Leo Li <[EMAIL PROTECTED]> wrote: Hi, all: Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10. As for drlvm, it passes on windows xp but fails on redhat linux enterprise 4. If somebody can reproduce it, I will report it as a application-oriented bug to jira. For detailed information, pls refer to http://wiki.apache.org/harmony/Apache_Maven. -- Leo Li China Software Development Lab, IBM
[classlib][pack200] Status update
I'm still lurking around in the background, but I'm busier than ever what with having to keep posting at EclipseZone where I'm editor now ... but I'm still managing to plod along with the Pack200 code. The last patch (1994, IIRC) went down pretty badly; the subclipse plugin didn't seem to capture all the newly created classes that I had put together for a bit of refactoring that I did. It's also a nightmare submitting newly created files; once they've been uploaded to JIRA into the patch queue, I effectively have to stop work until they're applied, because there's no way of getting SVN to figure out that the file called ClassFile.java is the same as the ClassFile.java that's been added by someone else on my behalf, and I have to overwrite my local copy to update. Kinda prevents doing any sensible work on newly created files between submission and application to be honest. Instead, I plan to sprint (well, jog, at least) to the next stable point, and then upload a whole wodge of code and leave it for a week or two to be applied before picking up again. I'm fairly close to being at that stage, but not quite. Where I am at is being able to generate (abstract) methods with exceptions and fields with constant (integer) values, so a bit further forward than last time. On the one hand, it means that I understand what needs to be done (no mean feat!) but on the other hand, there's still a fair bit to go. For a start, I'm going to need to process the actual bytecode for non-abstract methods (or indeed, any classes) before there's any point in it trying to be used for real, and there's still a few missing bits (Longs, Doubles, Floats) from the constant pools. I'm pretty sure Strings would work, but I've not tried them yet. Unfortunately, the code is really awful. The Segment.java is getting on for 1500 lines of code in a single class; and the attribute parsing contains both duplicated code and isn't as generic as it needs to be to handle other attributes; and the (in)visible annotations like @Overrides and similar are going to be a bit of a nightmare ... My plan is to get the code to a stage where it can start to be useful for extracting simple classes from a pack file, and then start generating test data which can be used for regressions. (There's a bit there at the moment, but it's not exactly a large coverage.) Once I've done that, I'll start tackling some of the refactoring which will result in less duplicated code and hopefully something that will be easier to look after in the future. Anyway, excuse the long rambling but I've been a bit quiet for a while and wanted to let people know I was still alive and kicking the code :-) Alex.
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Excellent! Well done everyone! Alex. On 01/11/06, Leo Li <[EMAIL PROTECTED]> wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM
Re: Re: [general] sun ceo annouced open source java time frame at Oracle OpenWorld conference
On 28/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote: It's a hoot -- it now seems to have mutated into all of SE being available by Christmas :-) Ho ho ho. Alex.
Re: Re: [drlvm] Class unloading support
On 28/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: On 10/29/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > From JLS:- > > ... > > And ... > > .. > > Anyway, I don't want to belabor this point forever, and my opinion is only > one among many :-) > > Good point! Thanks. I have never thought (as Java developer) about class unloading like an optimization. But if it is, as you pointed, the RI behaviour makes developers believe that it is always on :) True, but then JIT is an optimisation that isn't mandated in the JLS either :-) There are also JVMs that don't depend on a JIT, but just because it isn't mandated as a standard doesn't make it any less important to implement it. For that matter, there's nothing in the JLS that mandates how GC works. It's quite possible to have a JVM that never does any GC, and just sucks memory until it can't suck any more, and throw an OutOfMemoryException. What the JLS does say is the order in which finalise methods should be called prior to the storage being reclaimed; they don't mandate that the storage must be reclaimed. So, just because it's not mandated doesn't mean it's not important to do :-) Alex.
Re: Re: [drlvm] Class unloading support
As a fairly obvious comment, all JSPs that are translated into classes and then executed (or indeed, web apps that are deployed and then shut down again) are exactly the kind of place that new classloaders are created and then classes used. I'm not sure what you meant by 'class unloading', and whether that was unrelated classes in the same classloader, or when a classloader becomes eligible for GC() (and thus all of its contents do too). Alex.
Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF
Whoo-hoo :-> Well done everyone! Alex.
Re: RE: [classlib][test] Configuration dependent test of InetAddress.getHostName
Not sure if this is covered in a test elsewhere, but we could check
that the getLocalName() returns a non-null, non-empty string? After
all, both localhost and 127.0.0.1 should return valid lookups.
The other possibiltiy is to fork an 'nslookup' or 'host' command
(depending on platform) to find out what the platform thinks is the
local host name, and then comparing it to Java's result.
Alex.
On 25/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
Denis wrote,
>It's possible but it will be another test
Agreed
>+1 exclude this test (not whole test but localhost check)
+1
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-Original Message-
>From: Denis Kishenko [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 24, 2006 3:31 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][test] Configuration dependent test of
>InetAddress.getHostName
>
>2006/10/24, Fedotov, Alexei A <[EMAIL PROTECTED]>:
>> I wonder about the first option. Is there any way to check that
symbolic
>> name corresponds to the local computer? I can imagine the following
>> condition to check this.
>>
>>
InetAddress.getByName(InetAddress.getByName("127.0.0.1").getHostName()).
>> isLoopbackAddress()
>This test failed because isLoopbackAddress() expected 127.X.X.X
>
>2006/10/24, Fedotov, Alexei A <[EMAIL PROTECTED]>:
>> Andrew,
>>
>> I agree that test should be fixed. I suggested using one of the
>> following checks to validate that the host is localhost.
>>
>> InetAddress.getByName(host).isLoopbackAddress()
>> InetAddress.getByName(host).isSiteLocalAddress()
>It's possible but it will be another test
>
>IMHO
>+1 exclude this test (not whole test but localhost check)
Re: [general] Announcing newest members of the Harmony PPMC
Good stuff :-) Now, back to work! Alex. On 24/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC
Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
On 21/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: Alex, I see and accept your point. I believe that partial commits are a must - we should be a community. My point is simple - the code under active development shouldn't be a subject of beautification - it just should be safe for other Harmony modules. The first goal is to make it work. Completely agree. Code which is fluctuating under development shouldn't cause a concern that it's generating warnings for this kind of thing. Once the code matures, and is fully implemented and tested, *then* that's the time to start the beautification process :-) Alex.
Re: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
On 20/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: I agree that if a part of the code is kept for purpose, automatic tools can destroy it. From the other side, if we check your example, the following commenting solves the problem. >// int i; >// i=someMethod() TODO Fix the bug in someMethod() This was a contrived example; the point is, I might be submitting a checkpoint for the work that I'm doing, and have put the var in there for a good purpose. For example, it might be a field of a class that has been put together by design/necessity, even if it's not being used as of the checkpoint that you're looking at. As an obvious case, there are some fields that are defined in the pack200 class that aren't used yet, mostly because I haven't got around to the parts in which those aspects are being parsed out. However, I put them in there as part of the analysis of what was needed, and I know that they will be used in the near future. There's no point having them commented out; in fact, whilst coding, I want to be able to use them via code assist. I shouldn't have to sanity check and defend against what others might do to the code. There's also a similar danger that someone would remove those comments :-) I have even a stronger suggestion - we should remove the commented code leaving only a message for human beings. Indeed, that's the big problem. I'm working on that set of code -- it shouldn't be deleted. It's a work-in-progress. Deleting it and leaving a message "Your Code Was Here" is counterproductive. I suggest that we better save the time for many readers instead of the time of one lazy writer. I'm ok with leaving a human readable message in a place of a bug or exceptional behavior. For example, in our case I would write: >// TODO someMethod() behaves weirdly in case of OutOfMyResourceError. >// Fix the behavior. So, you'd prefer it if I didn't submit code which wasn't 100% complete? I'm fine with that ... but it'll be a long time before I complete the spec -- and if someone in the meantime removes some of the fields that I haven't yet parsed, it will still break when I update (or any of my further changes are committed). A warning does *not* indicate laziness. Nor does wanting to submit smaller regular patches of incomplete work for others to look at or improve. However, improvement doesn't include deleting code that people are still working on. Alex.
[classlib][pack200] Moving pack200 to a separate module
Moving from a different thread ... I'd like to move the pack200 to a separate buildable module, primarily so that it can be built as its own OSGi bundle and/or Jar, but also to separate it out from the archive so that e.g. internationalisation messages etc. don't need to get mixed in. There's a few dependencies which we need to resolve to make it happen: java.util.jar.Pack200 (static singleton factory that's used to instantiate the packager via the system property java.util.jar.Pack200.Packer http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/Pack200.html) -- NB this exists at the moment, but I've not implemented a class that implements the interface. Class(es) that implements the Pack200.Unpacker/Packer interface. Obviously will depend on java.util.jar package. Classes that implement the pack200 functionality (contents of the current org.apache.harmony.archive.pack200 package). Also depends on java.util.jar package for e.g. JarEntry etc. I think it can be set up such that the Pack200.Unpacker/Packer bindings and the current archive.pack200 can be moved into a module that has a compile-time dependency on the java.util.jar classes only. At run-time, the java.util.jar.Pack200 class will need to have access to the org.apache.harmony.archive.pack200 code, but because it's an interface, it's not a compile-time dependency. Also, this separation will allow non-OSGi aware programs to embed the pack200 jar and resolve the functionality by switching the system property to use the org.apache...pack200 implementation. I don't know the best place to put this -- whether it's another module in the classlib, or whether it should go in a tools directory -- but the pack200 module will have to have a compile-time dependency on the archive module, and the archive module will have to have a run-time dependency on the pack200 module. What's the best way of moving forward with this? Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Automated fixes considered harmful
There have been a few messages recently regarding build warnings that
complain about e.g. local variables not being used or missing
annotations, and work going on to 'fix' them.
However, in most cases, the only thing that is being 'fixed' is that
the compiler warnings no longer appear. Realistically, it's not a
problem in the code; in fact, the code works fine with those warnings
in place. Arguably, therefore, the code is being fixed to suit the
compiler, rather than the compiler being configured to be more useful
(i.e. less verbose).
Of particular beef are the kind of automated clean-ups that IDEs such
as Eclipse will offer. These are mostly incredibly dangerous, and
offer no significant benefit to Harmony as a whole. Some of them are
benign (for example, updating the list of imports) and some of them
aren't (deleting private methods, unused variables etc.). The problem
is that unless you've got a good idea of the code at any one point,
performing automatic transformation of the codebase is not a sensible
plan.
Whilst the fact of the matter is true that it doesn't affect code
execution (because private methods *aren't* being called, or a local
variable *isn't* being read), it doesn't make sense to do it
necessarily. For example, one could argue that removing all the
JavaDoc from the source files has no effect on the code, and has the
added advantage that the size of the source code is smaller -- but
that doesn't make it a sensible thing to do.
In particular, there's a lot of areas in the code that are pretty
dynamic, and are still evolving. For example, I could be writing
something like:
int i;
i=someMethod();
and then want to commit it to the repository. Let's say I discover a
bug in someMethod(), so I instead do:
int i;
//i=someMethod() //TODO Fix the bug in someMethod()
Now, automated tools will complain that i is being unreferenced
(possibly even uninitalised too :-) and volunteer to take it out. The
problem is then, after I've committed and worked on my code, I have:
int i;
i=someMethod() // Fixed bug
and someone else has committed Auto-Delete, so that when I update it becomes:
i=someMethod() // Compiler error, i doesn't exist
The problem is that the person who ran Auto-Delete only saw a snapshot
of the source code. Yes, *at that point in time* the variable wasn't
being defined, but by removing it, you've effectively removed it from
versions in the future, too. It's even worse with a private method,
because then you've lost a lot more than a simple variable
declaration.
The same thing is true of the Auto-Generics that some people have
become fond of. Really, get over it: generics don't save anything that
you wouldn't have in code anyway (they're pretty much all compile-time
restrictions anyway; there's still no type safety at run-time like
there is in C#). Worse, Generics can only be used with Java 5 onwards,
so by introducing generics into a library you're preventing that same
library being used on anything older than Java 5. Granted, most of
Harmony is working towards the Java 5 goal, but I'm sure there will be
reusable parts of the codebase that other users would otherwise be
able to use on older VMs, such as some of the tools (keytool,
jarsigner) or of course, the pack200 libraries that I'm involved with
at present.
I've also no idea what IDE suggested this one, but in the following:
if(condition) {
// some code
return value;
} else {
// some other code
return otherValue;
}
is absolutely *not* the same as
if (condition) {
// some code
return value;
}
// some other code
return otherValue;
These two may execute the same, but they have very different
semantics. In the first example, it's impossible to go from the if
block to the else block in the future. However, in the second example,
it may be that you can wrap some extra conditions around the return
statement. In this case, they have different semantics:
if (condition) {
// some code
if (anotherCondition)
return value;
} else {
// some other code
return otherValue;
}
and
if (condition) {
// some code
if (anotherCondition)
return value;
}
// some other code
return otherValue
The point is that code has been written in one way (or other) for a
reason. The code may well evolve in the future (or be evolving as you
are currently applying automated fixes). If you know that the variable
is not only unused now, but always will be unused in the future, then
fine, remove it. However, if all you know is the variable is unused
now, then automated fixing can be detrimental to the health of the
codebase.
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Recent build problem
I can't see any good point in keeping old class files in the build path for the next run. It's like not running a clean after each build. I say keep it out :-) Alex. On 20/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote: In the last day or so it seems we have had to do a 'clean' to get a successful build. Looking into it I see that we were picking up the build.output dir in our 'global' build javac (see below), which likely means that the new source files are compiled against the old .class files in some order. I see no reason why we should use the previous build.output binaries if we are rebuilding all, so I've taken that line out. Tell me if I'm smokin' something here (but the build still works for me). I think it is the cause of the problems. Regards, Tim [EMAIL PROTECTED] wrote: > Author: tellison > Date: Fri Oct 20 09:53:49 2006 > New Revision: 466199 > > URL: http://svn.apache.org/viewvc?view=rev&rev=466199 > Log: > Global compile should not pick up older class files from the classpath, but rely on the latest versions from source. > > Modified: > incubator/harmony/enhanced/classlib/trunk/make/build-java.xml > > Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml > URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?view=diff&rev=466199&r1=466198&r2=466199 > == > --- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original) > +++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Fri Oct 20 09:53:49 2006 > @@ -179,7 +179,7 @@ > > > > - > + > > > > > > -- Tim Ellison ([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: [vote] Graduate Apache Harmony podling from the Incubator
On 20/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status +1 from me too. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
Isn't this just because in your /etc/hosts file (or
c:/windows/system32/drivers/etc/hosts) you have a mapping
127.0.0.1 ntsdrlew31/10.125.122.60 localhost
? It's pretty much always localhost that's returned by default.
Alex.
On 20/10/06, Denis Kishenko <[EMAIL PROTECTED]> wrote:
Alexei,
Unfortunatelly this patch didn't help. Because system have already
returned host name as "nstdrlew21.ins.intel.com".
Certainly we can hardcode 127.0.0.1 as localhost
if (address == 0x7f01) {
hostName = "localhost";
} else {
hostName = getHostByAddrImpl(ipaddress).hostName;
// ask system
}
and we will get on Harmony
by name (127.0.0.1) -> localhost
by name (localhost) -> localhost
by address -> localhost
localhost -> nstdrlew21/10.125.122.60
But I am not sure this is correct.
2006/10/19, Fedotov, Alexei A <[EMAIL PROTECTED]>:
> Denis,
>
> Can we consider a patch from
> http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?
>
> Simply speaking, the patch adds a conditional operator which forces API
> to returning "localhost" in this case.
>
> Paulex,
> This is your patch. What do you think?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-Original Message-
> >From: Denis Kishenko [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, October 19, 2006 3:44 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: [classlib][test] Configuration dependent test of
> >InetAddress.getHostName
> >
> >I have researched issue H-1664 and found one more difference with RI.
> >I run simple test on Windows Server 2003 SP1
> >
> >=== Test =
> >import java.net.InetAddress;
> >import java.net.UnknownHostException;
> >
> >public class Test {
> >public static void main(String[] args) throws UnknownHostException
> {
> >System.out.println("by name (127.0.0.1) -> " +
> >InetAddress.getByName("127.0.0.1").getHostName());
> >System.out.println("by name (localhost) -> " +
> >InetAddress.getByName("localhost").getHostName());
> >System.out.println("by address -> " +
> >InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
> >System.out.println("localhost -> " +
> InetAddress.getLocalHost());
> >}
> >
> >}
> >
> >Windows Server 2003 SP1
> >=== RI ==
> >by name (127.0.0.1) -> 127.0.0.1
> >by name (localhost) -> localhost
> >by address -> 127.0.0.1
> >localhost -> nstdrlew21/10.125.122.60
> >
> >= Harmony ==
> >by name (127.0.0.1) -> nstdrlew21.ins.intel.com
> >by name (localhost) -> localhost
> >by address -> nstdrlew21.ins.intel.com
> >localhost -> nstdrlew21/10.125.122.60
> >
> >WinXP
> >= Both ===
> >by name (127.0.0.1) -> localhost
> >by name (localhost) -> localhost
> >by address -> localhost
> >localhost -> pbwdmkishen/10.125.132.226
> >
> >
> >Actually Harmony use native call of getnameinfo() to get host name
> >(which is reasonable IMHO). MSDN says "The getnameinfo function
> >provides name resolution from an address to the host name".
> >
> >InetAddressTest.test_getHostName (see H-1664) failed on WinServer
> >because InetAddress.getByName("127.0.0.1").getHostName() returned
> >"nstdrlew21.ins.intel.com" while "localhost" expected. So this test
> >looks like configuration dependent.
> >
> >I see three possible options
> >1. Stay test as is. Just keep in mind that on specific configurations
> >this one fails.
> >2. Rewrite test to be configuration dependent. Test has to do the same
> >native call.
> >3. Exclude localhost checking from test_getHostName.
> >
> >What do you think about this situation?
> >
> >--
> >Denis M. Kishenko
> >Enterprise Solutions Software Division
> >
> >-
> >Terms of use : http://incubator.apache.org/harmony/mailing.html
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Denis M. Kishenko
Enterprise Solutions Software 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: [general] Incubator graduation update
However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) :-) So, you're saying I've got less than a month to finish it ... I'll probably be able to get *something* ready for a release, but I doubt it will be fully compliant by then. The problem is that decompressed Jars are supposed to be exactly the same for any decompressor, so that MD5 signatures remain valid afterwards. What I can probably get is an unpacked Jar that will execute, but might be in a different ordering or have different MD5 signatures for components. The problem is that there's a lot of possible combinations of input files ... I've also tended to do fairly large code drops in patches, because it normally means a few days between submission and when it can be applied (thanks for the last one Paulex :-) I'd prefer to submit smaller patches as and when new functionality is added, but it would take longer that way. PS When's the code going to be moved to a jdktools subproject? Alex. - 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] Resolved: (HARMONY-1871) [classlib][pack200] Ongoing improvements to pack200; work-in-progress
Thanks for applying it. I'll check it makes sense ... as long as the tests pass, so far so good :-) I think Geir was talking about moving it into a new module in the tools directory though. Not sure if that's going to happen soon; if so, I may wait on when it's moved before starting the next block of work. Alex. On 19/10/06, Paulex Yang (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/HARMONY-1871?page=all ] Paulex Yang resolved HARMONY-1871. -- Resolution: Fixed Alex, the patches have been applied at revision r465556, thanks a lot for this enhancement, please verify the problem is fully resolved as you expected. And I'm looking forward to your further work on pack200. > [classlib][pack200] Ongoing improvements to pack200; work-in-progress > - > > Key: HARMONY-1871 > URL: http://issues.apache.org/jira/browse/HARMONY-1871 > Project: Harmony > Issue Type: Improvement > Components: Classlib >Reporter: Alex Blewitt > Assigned To: Paulex Yang >Priority: Trivial > Attachments: pack200.main.patch, pack200.test.patch > > > This is a work-in-progress of the pack200 implementation that allows a Jar to be written and class files generated. It's not complete (by a long shot) but it shows end-to-end ability. > The code is pretty ugly at the moment; I expect (for example) the code to write out classes will get factored into its own package and there's a lot more tidying up on Segment to do as well. However, it's pretty volatile (in the sense that I'm still working on the internals and moving it around) so it would be easier to leave code cleanups and message extraction until it's more complete. To that end, I've rolled back the changes from HARMONY-1327. > It would probably make my life easier if this patch was applied before the code was moved into a different module :-) I'm not sure how well an svn up will work in this instance since I don't have the entire trunk checked out. -- 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: Re: [general] POLL : supported platforms
Even better: Yes No Maybe :-) On 18/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Better : Supported Not-Supported In-Progress Mikhail Fursov wrote: > Mikhail, > I support your classification: it covers all types I can imagine. > > Here is my proposal of naming: > 1) "not supported" > 2) "product" or "supported" > 3) "incubation" > > > On 10/18/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> >> Well, I think there are at least three categories of platforms: >> >> 1) Platforms that we don't care about >> 2) Platforms that we think work and we want them working >> 3) Platforms that we want working but they still don't >> >> We definitely have to roll back the commits that break #2. >> >> We need some 'protection' policy to make it possible for platforms >> to graduate from #3 to #2 >> >> And we need some criteria to define how #1 could become #3 >> >> And we need names for the categories that are not misleading >> >> Comments? >> >> Thanks, >> Mikhail >> >> 2006/10/18, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> > >> > Mikhail Fursov wrote: >> > > Mikhail, >> > > The situation is possible with some Linux clones. >> > > And if we have such a situation I propose to take into account if we >> have a >> > > commiter/volunteer to check this platform. >> > > If we have a volunteer - we support it. >> > > >> > > Another question is: what if volunteer is gone and no one supports >> the >> > > platform? Will we claim that Harmony no longer supports the platform? >> > >> > No - to be supported, we have to agree as a community. I'm wary about >> > there being one-person-supported platforms. >> > >> > We can easily have two categories - >> > >> > a) platforms that we certify as being compatible, and support >> > >> > b) platforms that we certify as being compatible, but don't make any >> > support promises >> > >> > geir >> > >> > > >> > > On 10/18/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > >> >> > >> 2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> > >> > >> > >> > >> > Mikhail Loenko wrote: >> > >> > > 2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> > >> >> > >> > >> >> > >> > >> Mikhail Fursov wrote: >> > >> > > I think if we decide to support a platform then we define a set >> of >> > >> tests >> > >> > > that >> > >> > > must pass on that platform after each commit and we do roll back >> if >> > >> they >> > >> > > fail. That is how I understand "support" >> > >> > >> > >> > Lets define support as passing >90% of classlib unit and >> > >> > smoke/c-unit/kernel in DRLVM >> > >> >> > >> It might be a criteria for addition to the set of supported, but >> can't >> > >> be a definition. >> > >> Logically there could be a platform that we don't know, but that >> platform >> > >> could >> > >> pass 99% of the tests, do you think we can support a platform we >> don't >> > >> have any >> > >> idea about? >> > >> >> > >> Thanks, >> > >> Mikhail >> > >> >> > >> >> > >> >> > >> > >> > >> > geir >> > >> > >> > >> > >> - >> > >> > 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] >> >> > > - 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: [general] graduate from incubator to be a Top Level Project of the ASF
On 17/10/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: The Harmony PPMC has been discussing and has approved asking to graduate from the Apache Incubator and become a Top Level Project. This means that we would become an official project of the Apache Software Foundation. Any comments, for or against? I'm sure such a transition would cause the odd slashdot story etc. upon graduation; I think it would be good advertising to have a list of a few known-good apps that run mostly with Harmony (e.g. ant, eclipse etc.) Although it's still a work-in-progress, it would be a good milestone to state the current achievements (and also to ask for further help :-) Other than that observation, great :-) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
On 17/10/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov Congratulations guys :-) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][pack200] Moving pack200 to a separate module?
Cool. I've attached patches for the stuff I've done up until now as well as rolling back the localisation stuff as a patch in HARMONY-1871. And, for some reason, I've accidentally created an empty HARMONY-1870 too ... Alex. On 15/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I agree with your motivations. Lets move it to the javatools/ part of the project when I get that done this weekend. As to the ties to o.a.h.k.VM, I'm sure we can work something out... geir Alex Blewitt wrote: > I was in the process of trying to put together a patch for the new > stuff that I've added recently, and it turns out that someone's gone > through and pulled out all of the hard-coded strings in the code and > added a dependency on > org.apache.harmony.archive.internal.nls.Messages, which in turn has a > dependency on org.apache.harmony.kernel.VM. This causes a few > problems: > > 1) There's now a tighter dependency from the pack200 code to the > Harmony VM. As I've noted previously, I was wanting to develop this as > a portable implementation of pack200 so that others could use it > outside of Harmony; for example, on JVMs prior to 1.5 that don't have > it built in. > > 2) The messages for Pack200 are now mixed up with the messages for the > remainder of the archive code, when they don't need to be. That means > exporting/building a separate Pack200 is going to have extra detritus > in it that doesn't n eed to be there. > > 3) There were a bunch of messages that I was leaving in the code (in > Error messages) reminding me to implement certain facets of the code, > that were never meant to be extracted. These have now been extracted > into a messages file with less than helpful 'archive.1C' messages left > behind. > > I'd really like to undo this set of changes and leave message > externalisation until later, once the implementation is complete. I > also want to avoid getting the pack200 stuff tied up any more than is > necessary with the Harmony VM, because it should be possible to use > this on other VMs (or even the standard Java Sun VM ... the pack200 > code is switchable based on a property in any case). > > I'd also like to move the pack200 into its own module, so that when > messages do get externalised, they can be processed just for that > particular set of code and not lumped in with the remainder of the > archive code. I did suggest this in the past, although there was a > conclusion at the time that it wasn't worth doing at that time. I feel > that this is now the justification to separate the pack200 and archive > modules before it gets any more joined together. > > I'll hold off updating and submitting a patch until we can figure out > what's best to do with the code. > > Alex. > > - > 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: Re: [classlib][pack200] Moving pack200 to a separate module?
Yeah, it would be easy enough to do :-) I've added some comments in the header of each file to that effect. As for the (indirect) ties with o.a.h.k.VM, that's just an implementation issue with the Messages class; it should be fairly easy to roll out a less specific one for the pack200 messages. Alex. On 15/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I'm assuming that the person just didn't know... Please put a readme into the root of the codebase so that these special circumstances are known by others (assuming someone doesn't have a big problem with it...) geir Alex Blewitt wrote: > On a related note, it seems that some changes have been committed that > are using generics in the pack200 code. These will prevent it from > being run on pre Java 1.5 systems, which again was one of my goals in > writing this. I'll have to revert those changes, too ... > > Alex. > > On 15/10/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: >> I was in the process of trying to put together a patch for the new >> stuff that I've added recently, and it turns out that someone's gone >> through and pulled out all of the hard-coded strings in the code and >> added a dependency on >> org.apache.harmony.archive.internal.nls.Messages, which in turn has a >> dependency on org.apache.harmony.kernel.VM. This causes a few >> problems: >> >> 1) There's now a tighter dependency from the pack200 code to the >> Harmony VM. As I've noted previously, I was wanting to develop this as >> a portable implementation of pack200 so that others could use it >> outside of Harmony; for example, on JVMs prior to 1.5 that don't have >> it built in. >> >> 2) The messages for Pack200 are now mixed up with the messages for the >> remainder of the archive code, when they don't need to be. That means >> exporting/building a separate Pack200 is going to have extra detritus >> in it that doesn't n eed to be there. >> >> 3) There were a bunch of messages that I was leaving in the code (in >> Error messages) reminding me to implement certain facets of the code, >> that were never meant to be extracted. These have now been extracted >> into a messages file with less than helpful 'archive.1C' messages left >> behind. >> >> I'd really like to undo this set of changes and leave message >> externalisation until later, once the implementation is complete. I >> also want to avoid getting the pack200 stuff tied up any more than is >> necessary with the Harmony VM, because it should be possible to use >> this on other VMs (or even the standard Java Sun VM ... the pack200 >> code is switchable based on a property in any case). >> >> I'd also like to move the pack200 into its own module, so that when >> messages do get externalised, they can be processed just for that >> particular set of code and not lumped in with the remainder of the >> archive code. I did suggest this in the past, although there was a >> conclusion at the time that it wasn't worth doing at that time. I feel >> that this is now the justification to separate the pack200 and archive >> modules before it gets any more joined together. >> >> I'll hold off updating and submitting a patch until we can figure out >> what's best to do with the code. >> >> Alex. >> > > - > 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: [classlib][pack200] Moving pack200 to a separate module?
On a related note, it seems that some changes have been committed that are using generics in the pack200 code. These will prevent it from being run on pre Java 1.5 systems, which again was one of my goals in writing this. I'll have to revert those changes, too ... Alex. On 15/10/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: I was in the process of trying to put together a patch for the new stuff that I've added recently, and it turns out that someone's gone through and pulled out all of the hard-coded strings in the code and added a dependency on org.apache.harmony.archive.internal.nls.Messages, which in turn has a dependency on org.apache.harmony.kernel.VM. This causes a few problems: 1) There's now a tighter dependency from the pack200 code to the Harmony VM. As I've noted previously, I was wanting to develop this as a portable implementation of pack200 so that others could use it outside of Harmony; for example, on JVMs prior to 1.5 that don't have it built in. 2) The messages for Pack200 are now mixed up with the messages for the remainder of the archive code, when they don't need to be. That means exporting/building a separate Pack200 is going to have extra detritus in it that doesn't n eed to be there. 3) There were a bunch of messages that I was leaving in the code (in Error messages) reminding me to implement certain facets of the code, that were never meant to be extracted. These have now been extracted into a messages file with less than helpful 'archive.1C' messages left behind. I'd really like to undo this set of changes and leave message externalisation until later, once the implementation is complete. I also want to avoid getting the pack200 stuff tied up any more than is necessary with the Harmony VM, because it should be possible to use this on other VMs (or even the standard Java Sun VM ... the pack200 code is switchable based on a property in any case). I'd also like to move the pack200 into its own module, so that when messages do get externalised, they can be processed just for that particular set of code and not lumped in with the remainder of the archive code. I did suggest this in the past, although there was a conclusion at the time that it wasn't worth doing at that time. I feel that this is now the justification to separate the pack200 and archive modules before it gets any more joined together. I'll hold off updating and submitting a patch until we can figure out what's best to do with the code. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][pack200] Moving pack200 to a separate module?
I was in the process of trying to put together a patch for the new stuff that I've added recently, and it turns out that someone's gone through and pulled out all of the hard-coded strings in the code and added a dependency on org.apache.harmony.archive.internal.nls.Messages, which in turn has a dependency on org.apache.harmony.kernel.VM. This causes a few problems: 1) There's now a tighter dependency from the pack200 code to the Harmony VM. As I've noted previously, I was wanting to develop this as a portable implementation of pack200 so that others could use it outside of Harmony; for example, on JVMs prior to 1.5 that don't have it built in. 2) The messages for Pack200 are now mixed up with the messages for the remainder of the archive code, when they don't need to be. That means exporting/building a separate Pack200 is going to have extra detritus in it that doesn't n eed to be there. 3) There were a bunch of messages that I was leaving in the code (in Error messages) reminding me to implement certain facets of the code, that were never meant to be extracted. These have now been extracted into a messages file with less than helpful 'archive.1C' messages left behind. I'd really like to undo this set of changes and leave message externalisation until later, once the implementation is complete. I also want to avoid getting the pack200 stuff tied up any more than is necessary with the Harmony VM, because it should be possible to use this on other VMs (or even the standard Java Sun VM ... the pack200 code is switchable based on a property in any case). I'd also like to move the pack200 into its own module, so that when messages do get externalised, they can be processed just for that particular set of code and not lumped in with the remainder of the archive code. I did suggest this in the past, although there was a conclusion at the time that it wasn't worth doing at that time. I feel that this is now the justification to separate the pack200 and archive modules before it gets any more joined together. I'll hold off updating and submitting a patch until we can figure out what's best to do with the code. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][pack200] Unpacked archive; now reconstituted Jar file too :-)
Following from my last success ... I've now got a minimal version of a Pack200 archive decoded and then reassembled into a Jar file, including spitting out the .class code so that javap correctly decodes it. I'm using the standard JarEntry/JarOutputStream to dump data out (and at the moment, I'm testing it against the JarEntry/JarOutputStream on Mac rather than the harmony version). Still, it assembles the right files in the right order and for any non-class file, dumps the file as is. Whilst this may sound like I'm making a lot of progress, there's still a lot more to be done, so don't get your hopes up too high yet. I've just demangled a test interface with no methods, so there's still work to be done in decoding bytecodes and inserting them into the resulting file. Still, I think I've got a handle on how the attributes work now in a pack200 archive (and for that matter, a class file) so the next part of the work is pretty clear. I also have to make sure that the output class file is exactly the same as the standard pack200 will generate. As an example, a class file can contain m1() and m2(), or it can contain m2() and m1() -- they'll both work the same in a JVM. However, since pack200 archives can be signed, it's essential that for any two pack200 decompressors that they produce exactly the same binary output. (There's well-defined orderings along the lines of 'sort all methods alphabetically' but a bit more detailed; currently, I don't respect those.) I'm putting together my own mini version of BCEL to generate the class files and deal with the constant pool entries primarily because of the strict ordering and processing that the class file has to be in. I'm not sure if harmony uses BCEL elsewhere (or similar) but I'd prefer to write something that's entirely self-contained for pack200, since the pack200 stuff can be exported as an independent Jar and used in other systems (e.g. Eclipse) regardless of underlying VM. Mind you, in doing so, I think I see some good refactorings that I can make for the main Segment class, which is probably just as well since it's growing to be a bit of a monolith. There's also a bunch of optional-ish stuff which I've not tackled yet. For example, parameter and method annotations (e.g. @Override etc.) are handled specifically within the archive; in other words, if you pass in a packed Jar file that has no annotations, it will go well, but if you pass in a packed Jar file where one (or more) of the classes has annotations, it will fall over. (It's not an insurmountable problem, it's just one that will take time; but I'm going to focus on the main stuff of methods, bytecodes etc. first) Lastly, there's known places in the decompression which I don't handle. For example, an archive can pretty much ignore the default compression for a piece of data and instruct the decompressor to use a different one instead. I can detect when that happens, but I just throw an Error (for now) rather than do the necessary switch. Anyway, I'll get the code that I have at the moment tidied up a bit (and update the copyright notices) and then make a patch with the current state of play. I can then start focussing in on decompressing an interface with a constant or some empty methods :-) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Eclipse bug - move MANIFEST.MF to a different location
Cool. I've asked them to mark it as a dupe of 153023, so you should get Cc'd onto that one automatically ... but if you can use the 'vote for this bug' then it would be one more person on the list. It's at 5 at the moment, so the more people who vote for it the more PDE will realise that it's a requested feature ... Re: the default: I'm guessing that if it were to go ahead, they would make it backwardly compatible to be in the project root. My hope is that they search for it in the bin/ directory (or whatever other output directories there are) so that you could have a src/main/resources/META-INF/MANIFEST.MF, and then it would just be resolved similar to any other resource at build time. Plus, it would make exporting easy; you'd just zip up the bin/ directory ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse bug - move MANIFEST.MF to a different location
Hi all, There's a discussion going on the Eclipse bugs list about being able to move the META-INF/MANIFEST.MF to a different location (e.g. src/main/resources/META-INF/MANIFEST.MF). For some reason, the Eclispe PDE/Equinox team can't seem to understand why anyone would want to put resources anywhere other than the top-level of the project. If you'd like to add your opinions, please add your comments to (and vote for!) https://bugs.eclipse.org/bugs/show_bug.cgi?id=153023 as well as perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=154079 Thanks, Alex. PS There was also some spirited discussion on the equinox-dev mailing list some time ago, but I think it's migrated from there into the bug discussion http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01272.html Basically seems to be Eclipse-users saying Yes! We want this! and the Equinox team going Why? It works fine ... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][pack200] Unpacked my first archive today!
I managed to unpack a Pack200 file completely today for the first time, so that by the end of it there were no bytes left in the queue. Unfortunately, it wasn't a spectacularly exciting archive -- just one interface with no methods (about as exciting as java.lang.Serializable, in fact) but I think that I've unlocked the next stage in the process for decompressing the attributes that are left (including things like bytecodes, etc.). At the moment, the data is just in an unpacked state; I've not yet looked at re-assembling the data into their constituent .class files (need to get hold of the class bytecode format for that) or even reconstituting the Jar file. I'm thinking of using ZipEntry and ZipOutputStream (or corresponding Jar variants) for building the resulting Jar file. I'm not sure whether they are implemented or not in the current trunk or not, but I might start working against the ZipOutputStream/ZipEntry APIs. Onward and upward ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
I use TODOs a lot in my code to remind me to come back to that
particular piece and do the job properly. If someone else were to
remove them then they may not do the right thing as far as the code
needs ... so I'd expect at least some kind of heads-up before this
would happen :-)
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
Alex.
On 04/10/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
-Nathan
On 10/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> Nathan,
>
> I've seen you dropped many TODOs in "- Code cleanup -" series of commits;
> I'd like to know what reasoning was behind this? I think it's a bit
> early to erase TODOs without appropriate consideration...
>
> In particular, could you please undo the following change, it produces
> garbage messages during AUTH testing:
>
>
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
> ===
> @@ -216,12 +206,12 @@ public class DefaultConfigurationParser
> try {
> val = PolicyUtils.expand(st.sval, system);
> } catch (Exception e) {
> - //TODO: warning log
> - }
> + e.printStackTrace();
> + }
> }
>
> --
> WBR,
> Alexey
>
> -
> 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: Re: [build]Anyone else got these test errors of Pack200 like this?
Phew :-) You had me worried there for a moment ... Alex. On 18/09/06, Paulex Yang <[EMAIL PROTECTED]> wrote: Pls. ignore it, cannot reproduce at r447234, probably I forgot "ant build" before running "ant -Dbuild.module=archive test". Sorry for the confusion caused. Paulex Yang wrote: > My build machine is WinXP SP2, Harmony classlib+IBM VME, at revision r > 447234, and I got 5 similar errors of > org.apache.harmony.archive.tests.internal.pack200.CodecTest like this: > > java.lang.NoSuchFieldError: > org/apache/harmony/archive/internal/pack200/Codec.BYTE1 at > org.apache.harmony.archive.tests.internal.pack200.CodecTest.testCodecToString(CodecTest.java:59) > at > java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > Any ideas or comments? > -- 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] - 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] Resolved: (HARMONY-1386) Update to Pack200 decoding libraries
Yes, the HelloWorld.pack is different and needs to be replaced with the one in the bug report. Thanks, Alex. On 13/09/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/HARMONY-1386?page=all ] Mikhail Loenko resolved HARMONY-1386. - Resolution: Fixed Thanks for the patch! Ive applied it in revision 442918 the tests passed it's not clear what to do with HelloWorld.pack. should I replace that one in SVN? > Update to Pack200 decoding libraries > > > Key: HARMONY-1386 > URL: http://issues.apache.org/jira/browse/HARMONY-1386 > Project: Harmony > Issue Type: Improvement > Components: Classlib >Reporter: Alex Blewitt > Assigned To: Mikhail Loenko >Priority: Minor > Attachments: HelloWorld.pack, HelloWorld.pack, pack200.patch, pack200.patch > > > I've updated the Pack200 decoding to take into account of the dynamic codec switching (although it currently throws an error if it's detected that such a dynamic switch is used) as well as adding more descriptive logging of what bands are being parsed, including remaining unimplemented bands. No output should be seen unless -Ddebug.pack200=true, but this is only for use whilst ensuring the unpacking is right. > I'm not sure whether the patch contains the updated binary for HelloWorld.pack, so I'll attach that in addition to the patch. > I've also fixed a couple of minor bugs in parsing the class and field bands. > This patch passes all the tests with against the HEAD, but it wouldn't surprise me if the patch was missing some required file :-( -- 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]
[classlib][pack200] Patch in queue
Is anyone able to apply http://issues.apache.org/jira/browse/HARMONY-1386 into the codebase? It's basically more of the same; but I'm waiting until it's applied and I've updated before continuing with development. Thanks, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [jira] Created: (HARMONY-1386) Update to Pack200 decoding libraries
You know, when I added the files in the initial bug report, I didn't see anything that would have made me add the license. I also couldn't figure out how to change it, so I uploaded it again. :-) On 06/09/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Hi Alex Thanks for the patches! Could you please grant ASF license to make their inclusion possible? Thanks, Mikhail 2006/9/6, Alex Blewitt (JIRA) <[EMAIL PROTECTED]>: > Update to Pack200 decoding libraries > > > Key: HARMONY-1386 > URL: http://issues.apache.org/jira/browse/HARMONY-1386 > Project: Harmony > Issue Type: Improvement > Components: Classlib >Reporter: Alex Blewitt >Priority: Minor > Attachments: HelloWorld.pack, pack200.patch > > I've updated the Pack200 decoding to take into account of the dynamic codec switching (although it currently throws an error if it's detected that such a dynamic switch is used) as well as adding more descriptive logging of what bands are being parsed, including remaining unimplemented bands. No output should be seen unless -Ddebug.pack200=true, but this is only for use whilst ensuring the unpacking is right. > > I'm not sure whether the patch contains the updated binary for HelloWorld.pack, so I'll attach that in addition to the patch. > > I've also fixed a couple of minor bugs in parsing the class and field bands. > > This patch passes all the tests with against the HEAD, but it wouldn't surprise me if the patch was missing some required file :-( > > -- > 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [classlib][TestNG] groups of Harmony test
On 04/09/06, Richard Liang <[EMAIL PROTECTED]> wrote: On 9/4/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > If you've got fast and slow tests, then have a group for fast and slow > tests. Then you can choose to just run the fast tests, and any > automated build system can handle running the slow tests. IMHO, "fast or slow" may not be the key point. The question is whether we have any requirements to run only the regression tests. No, probably not the key point, but (a) groups don't have to be mutually exclusive (so you can decorate it with whatever groups you want) and (b) it might be useful for an automated build system to run fast tests first, followed by slow (or non-fast) tests. Mind you, I don't know what's going to happen with an automated test'n'build system; so it might not make sense to do it at this point. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][TestNG] groups of Harmony test
IMNSO it doesn't make sense to arbitrarily partition the tests based
on a moniker, such as 'integration test', 'unit test', 'regression
test' etc. For one thing, developers are generally not good at
agreeing on the difference between them :-)
If you've got fast and slow tests, then have a group for fast and slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
Alex.
On 04/09/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
On 9/4/06, Richard Liang <[EMAIL PROTECTED]> wrote:
>
>
>
> Mikhail Loenko wrote:
> > Hi Vladimir
> >
> > Could you please decribe for what purpose it will be used?
> >
> > I mean why one might have to either exclude or run only regression
> tests?
>
> If running all tests takes up much time, running all regression test
> (for one particular version) may be a convenient way to verify the
> correctness of bug-fixing.
Thanks Richard. It is exactly what I want to say :)
On the other hand may be all proposed groups need similar explanation (smt.
like use-case for group)?
thanks, Vladimir
Best regards,
> Richard.
>
> >
> > Thanks,
> > Mikhail
> >
> > 2006/8/30, Vladimir Ivanov <[EMAIL PROTECTED]>:
> >> On 8/30/06, Richard Liang <[EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> >
> >> > Vladimir Ivanov wrote:
> >> > > Also some tag for regression tests should be added.
> >> > Yes. Do you think we could annotate regression test as
> >> > *level.regression*? Thanks a lot.
> >>
> >>
> >> Yes, I do. While tests can have more than one group it will enough.
> >> thanks, Vladimir
> >>
> >>
> >> Richard
> >> > > thanks, Vladimir
> >> > >
> >> > >
> >> > > On 8/28/06, Richard Liang <[EMAIL PROTECTED]> wrote:
> >> > >>
> >> > >>
> >> > >>
> >> > >> Richard Liang wrote:
> >> > >> > Hello All,
> >> > >> >
> >> > >> > Now let's talk about the TestNG groups. I have read the related
> >> > >> > threads which posted by George, Vladimir Ivanov and Alexei
> >> Zakharov.
> >> > >> > All of them are good discussion about TestNG groups.
> >> > >> >
> >> > >> > IMHO, we may define Harmony test groups according the following
> 4
> >> > >> > dimensions:
> >> > >> >
> >> > >> > 1) [Platform] os.any, os.
> >> > >> > *os.any* - group of tests which pass on any platform. IMHO,
> >> most of
> >> > >> > our tests should be in this group.
> >> > >> > *os.* - group of tests which are designed for one
> >> > >> > specific platform. A test may be in more than one of the
> >> groups. e.g
> >> > .,
> >> > >> > @Test(groups={"os.win.IA32", "os.linux.IA32"})
> >> > >> >
> >> > >> >** os.any and os. are mutually exclusive, that
> >> is,
> >> > >> > tests in os.any group should not be in os.win.IA32.
> >> > >> >
> >> > >> > 2) [Test state] state.broken, state.broken.
> >> > >> > *state.broken* - group of tests which fail on every platform,
> >> because
> >> > >> > of bugs of tests or implementation. We need to fix the bugs of
> >> tests
> >> > >> > or implementation to make them pass.
> >> > >> > *state.broken.* - groups of test which only fail
> >> on one
> >> > >> > specific platform. A test may be in more than one of the
> >> groups. e.g
> >> > .,
> >> > >> > @Test(groups={"state.broken.linux.IA32", "os.broken.linux.IA64
> "})
> >> > >> >
> >> > >> > **state.broken. group may be used as a
> >> convenient
> >> > way
> >> > >> > to indicate that a test is platform-specific. e.g., If we
> >> support 10
> >> > >> > platforms, and one test are designed for 9 platforms except for
> >> > MacOS,
> >> > >> > instead of list 9 os., we can just use
> >> > state.broken.MacOS
> >> > >> >
> >> > >> > 3) [Test type] type.api , type.impl
> >> > >> > *type.api* - group of tests which are tests for APIs in the Java
> >> > >> > Specification
> >> > >> > *type.impl* - groups of tests which are tests for
> >> Harmony-specific
> >> > >> > implementation
> >> > >> >
> >> > >> > ** type.api and type.impl are also mutually exclusive.
> >> > >> >
> >> > >> > 4) [Test Level] level.unit, level.integration, level.system,
> >> > >> > level.stress, etc. (Levels of Test refer to the increase in
> >> > complexity
> >> > >> > as moving through test cycle. )
> >> > >> >** A test may be in more than one of the groups.
> >> > >> >** In fact, some tests such as System tests are the
> >> verification
> >> > of
> >> > >> > the entire system. Maybe we'll put them into a separate
> project.
> >> > >> > e.g., harmony/enhanced/SVT (System Verification Test).
> >> > >> >
> >> > >> > If we want to run all the unit test for APIs on windows, we
> >> may use
> >> > >> > TestNG groups to select the tests:
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> Hello All,
> >> > >>
> >> > >> I'm sorry. It seems that the example does not work. I will try to
> >> > figure
> >> > >> another examp
Re: Re: [general] compatibility packages
Bear in mind that this isn't standard across all VMs. For example, Mac VMs use JAVA_HOME/../Classes/classes.jar, instead of rt.jar. Alex. On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: I assume for #1 we'll offer a patch :) Or just create an rt.jar if someone needs that. There is no reason not to... geir Anton Luht wrote: > Hello, > > There's another issues on compatibility: some applications rely on the > existence of "/lib/rt.jar" - the example is [1]. Some > require tools.jar [2]. Harmony doesn't have these jars now so > applications can fail on it just because they're bound to the > implementation specifics. > > [1] > http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar > > [2] > http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar > > > - 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: Re: [general] compatibility packages
On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: 3) Clearly there's value in providing these [sun.* classes], as other implementations (BEA, IBM, Apple) include them. Possibly true, but for different reasons. They license the source code bulk from Sun, not re-implement their own. (They have patches etc. that sit on top of them, of course.) As a result, there's a bunch of internal stuff that is exactly the same as Sun's, and so depends on the sun.* classes. The value (to them) is that they don't have to spend time re-writing the sun.* classes instead of something else. There's no value necessarily to the end user; it's a selfish decision on their part, nothing more. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [general] compatibility packages
On 13/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > On 12/08/06, Jeroen Frijters <[EMAIL PROTECTED]> wrote: >> However, I've spoken with Mark Reinhold about this issue and he told me >> that Sun sometimes reverts changes to sun.* classes because a customer >> complains that it broke their code. > > And with this statement, you've highlighed precisely why we shouldn't > include suncompat.jar by default. Because once we do, there's no going > back -- ever. If we do, we risk the wrath of some user down in the > future. I don't think we'll ship with suncompat.jar forever. I'd probably say it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in bootclasspath by default...). The problem (that I see) is that once you have something in a release, it's almost impossible to remove it at a later stage without running the risk of breaking something. I don't think it's reasonable to expect a reversal in decision at any point on this issue ... > (Very good related material can be found at > http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and > http://www.xom.nu/designprinciples.xhtml) Yah, but there's a difference between deprecated and what we're doing here. You deprecate when something that was part of the API contract needs to go away. We're never saying that suncompat is part of our API contract. The point being that once something is there, it's almost impossible to remove it. It doesn't matter whether it's called 'deprecated' or 'suncompat'; it's either there, or it isn't. Once it is there, it's very difficult to stop it being there without breaking something. The point of those links was to help emphasise that regardless of warnings, terminology, or semantics applied to those elements, removing them is almost impossible. Maybe it's simply semantics, but I see that these are important semantics. I believe the fundamental difference is that you see it is possible to go from a 'enabled by default' to 'not enabled by default' -- my experience suggests otherwise. The semantics of the label attached to the library is irrelivant; it's whether you can go backwards or not. I do not believe you can. > Surely we should be working towards that aim as well? I fail to see > how this helps anyone in the medium or long term. Users will make or break us. Yes, and they'll break us when, after some time shipping suncompat.jar by default, we disable it by default. Far better to train them to do the right thing from the beginning (enable it if they need it) than to throw them at a much later stage. > If we include it by > default *now*, we include it by default *for ever*. If we don't > include it by default, but have a FAQ up that tells people about the > workarounds, then those people for whom it's a problem can fix it, and > the rest of the world can get on without it quite happily. But adding > it by default is a one-way street that can never be reversed. I don't agree at all. Yes, this is the fundamental objection I have, and you disagree with it. > There seems to be three options we can go forwards with: > > 1) Neither have suncompat.jar nor make it default (i.e. where we were > before last week) > 2) Have suncompat.jar, but don't make it default (instead, provide > FAQs like > http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) > > 3) Have suncompat.jar, and make it default. I vote for #3, because at this stage of the project, we want to get rid of the speedbumps, switching to #2 at some point. As for #1, this is open source... we can't dictate that. And what if it were impossible to move from 3->2? Your decision would have locked us into shipping the sun.* packages for ever. Is that what you want? (Actually, that would be a howler wouldn't it... to become the RI for sun.*...) :-) > The transition from 1->2->3 is irreversible, and the decision to go > down that path should be considered carefully for both immediate > short-term (My app doesn't run on Harmony!) and medium- and long-term > goals (non-Sun VMs shouldn't have/need sun. classes) I absolutely don't agree that the transition is irreversible. I'd have *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle because at all times, we're going to make it clear what the situation is and why we're doing it. Let me get this straight: You're happy to argue strongly enough *for* the suncompat.jar, that you think it should be the default (so that any application, no matter how badly written, will run without any changes). Yet you're happy for us to pull the rug out unde
Fwd: Re: Adding new files to SVN and subsequently trying to update
Mark Phippard very kindly took on board my comments, and added a FAQ to subversion as well as raising an issue for this. A couple of things are worth noting: 1) I should have used 'svn revert' rather than editing the entries file by hand. "mv new.file new.file.old; svn revert new.file" will apparently do the work 2) A new subversion option --force is in the works (svn 1.5), which will overwrite any local changes. It only applies to update files, but if the below issue is addressed it should allow for added files too. However, I think that the --force will discard any local changes, even if you've made subsequent edits since the patch was fled, so it might still be an idea to rename it to a separate file so that you can do manual diff checks. Thanks, Mark! Alex. -- Forwarded message -- From: Mark Phippard Date: 12-Aug-2006 14:04 Subject: Re: Re: Adding new files to SVN and subsequently trying to update To: Alex Blewitt OK, the FAQ has been added: http://svn.collab.net/viewvc/svn?view=rev&revision=21056 http://subversion.tigris.org/faq.html#obstructed-add And also an issue has been filed: http://subversion.tigris.org/issues/show_bug.cgi?id=2593 Thanks Mark - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [general] compatibility packages
On 12/08/06, Jeroen Frijters <[EMAIL PROTECTED]> wrote: You also keep hammering on CharToByteConverter as an example of bad code that should trivially be fixed (and it obviously should, if possible, but it's not always that easy), but there is also code out there that uses sun.* classes to do things that are impossible to do with the documented APIs. How would you fix those? You can't trivially fix such problems; in each case, someone has to debug and find out where the dependency is. And let's face it, if someone refers to sun.foo.Bar (and it's not in suncompat.jar in the first instance) they're going to be in exactly the same situation. It's only really for the benefit of people who aren't the first to fall over (e.g. the BASE64 encoder). However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) I asked him if they would be documenting these classes when they do this, but he said they wouldn't. So they seem to live in a dream world where on the one hand they want to discourage usage of sun.* and on the other hand continue to support it. Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. If we include it by default *now*, we include it by default *for ever*. If we don't include it by default, but have a FAQ up that tells people about the workarounds, then those people for whom it's a problem can fix it, and the rest of the world can get on without it quite happily. But adding it by default is a one-way street that can never be reversed. Like compatibility in general this is a hard problem and we need to take a pragmatic approach and I really like the current plan of having an optional suncompat module. There seems to be three options we can go forwards with: 1) Neither have suncompat.jar nor make it default (i.e. where we were before last week) 2) Have suncompat.jar, but don't make it default (instead, provide FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) 3) Have suncompat.jar, and make it default. The transition from 1->2->3 is irreversible, and the decision to go down that path should be considered carefully for both immediate short-term (My app doesn't run on Harmony!) and medium- and long-term goals (non-Sun VMs shouldn't have/need sun. classes) I strongly disagree with the suggestion that we must do 3 to support a tiny proportion of apps that may go against Sun's FAQ (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed, they go as far as saying that: "The sun.* packages are not part of the supported, public interface. A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform. "In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported." Why should we support them when Sun don't even claim to? Furthermore, by taking a stance of 1) or 2), we are actively helping push Sun's advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a strong stand against these packages. Harmony will be great, regardless of whether the sun.* packages are there. There will be at least one program that doesn't work because of this (but that's been fixed already) -- there will be others in the future. The adoption of Harmony as an open-source JVM will happen regardless of the sun.* packages. Some people will complain, some will vociferously declare that the suncompat module should be there by default. Some programs won't work. If we go with option 2), they can be made to work or to raise the issue that the program is not a portable Java application (or both). I strongly urge everyone to vote against the suncompat module being on the classpath by default. In two years time, we will be able to look back to this post and either congratulate ourselves on a wise decision made now, or rue the day that we gave up the chance to allow a strong stand on the restriction of sun.* packages for any running code. Alex. PS The whole 'on the classpath for runtime but not for compile time' is completely bogus. If it's on the classpath, then an IDE such as Eclipse that provides its own compiler will still be able to compile against the class, as will e.g. references in JSPs for application servers that suppy their own compi
Re: Re: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Cool, thanks. On 11/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Done in 430723 Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [classlib][suncompat] created
I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 11:13 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib][suncompat] created > > Oh - definitely only add as needed, and yes, we need to have good > documentation to assist users. > > And I'm very +1 about including this by default for now. See other > threads as for why. > > geir > > Alex Blewitt wrote: > > Sounds like a FAQ in the making :-) > > > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> Alex Blewitt wrote: > >> > OK. What's the plan with regards to adding items in here e.g. Base64 > >> > or tools like JavaC? Or do we just add them organically as we find > >> > problems? > >> > >> Let's try and keep this JAR as small as possible, only adding types > >> after a debate on the list concludes that it is a 'necessity'. > >> > >> Regards, > >> Tim > >> > >> -- > >> > >> Tim Ellison ([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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][suncompat] created
Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > OK. What's the plan with regards to adding items in here e.g. Base64 > or tools like JavaC? Or do we just add them organically as we find > problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([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: Re: [classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
I think we should follow the ISO-3166 standard for everything; after
all, that's the point of the standard :-) If the RI has bugs in, then
fair enough, but the point of the ISO codes is to have a standard way
of referencing it (CD) -- how it appears on displays shouldn't be
important, and you shouldn't have code that depends on the display
name when you've got the ISO code ...
It's much easier to be strict about it now (and fix bugs as they get
found in other apps) than to be lax now and try and add strictness
later. So I'd say, let's go with the ISO-3166 for everything.
Alex.
On 10/08/06, Ilya Okomin <[EMAIL PROTECTED]> wrote:
On 8/10/06, Spark Shen <[EMAIL PROTECTED]> wrote:
> 2006/8/10, Richard Liang <[EMAIL PROTECTED]>:
> >
> >
> >
> > Spark Shen wrote:
> > > Hi All:
> > > Construct a locale like this:
> > > Locale l = new Locale("", "CD");
> > > On RI, l.getDisplayCountry() will return "The Democratic Republic Of
> > > Congo",
> > > which is different from ISO 3166-1 standard.
> > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> > > Republic
> > > of the")
> > IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
> > think user applications would be broken because of the difference with
> RI.
>
>
> I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale("", "KP");
ISO-3166 expected value: "Korea, Democratic People's Republic of "
RI returns: "North Korea"
new Locale("", "MK");
ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
RI returns: "Macedonia"
..and so on.
IMO in this case to be compatible with RI we can use "The Democratic
Republic Of Congo" for "CD" country. To follow completely the ISO-3166
standard we have to make changes not only for "CD" country.
Thanks,
Ilya.
> Best regards
>
> Richard.
> > >
> > > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> > > DEMOCRATIC REPUBLIC OF THE" data item or a
> > > "CD"->" Congo, the Democratic Republic of
> > > the< http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
> > > data item at all.
> > >
> > > This test case will fail on Harmony since the returned displayCountry
> is
> > > "CD".
> > > public void test_getDisplayCountry() {
> > >
> > >Locale l_countryCD = new Locale("", "CD");
> > >assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> > >l_countryCD.getDisplayCountry());
> > >}
> > >
> > > I need to add a mapping into harmony locale data. But which?
> > >
> > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> > >or
> > > "CD"->"Congo, the Democratic Republic of the"
> > >or
> > > "CD"->"The Democratic Republic Of Congo" (RI)
> > >
> > > Personally, I prefer RI, since there may be applications relies on the
>
> > > returned displayCountry value. Your opinions?
> > >
> > > Best regards
> > >
> >
> > --
> > 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]
> >
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
--
--
Ilya Okomin
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: [classlib][suncompat] created
OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Alex. On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Just FYI, I went ahead and created a suncompat.jar. As I wrote elsewhere it is trivial to create a new module, and trivial to remove it if we decide this is the wrong direction. By default it is unused in the JRE, to enable it you need to uncomment the lines at the end of jre/lib/boot/bootclasspath.properties Regards, Tim -- Tim Ellison ([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: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Only one problem I've found so far (possibly because it was in an earlier patch but not subsequent ones) -- the src/test/java/org/apache/harmony/archive/tests/AllTests.java doesn't have a suite.addTest(org.apache.harmony.archive.tests.internal.pack200.AllTests.suite()); in it. Can you add that, or do you want me to send a patch? (Mind you, with my record of submitting patches, I'm not sure that's such a good idea ;-) Alex. On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Finally it's in! :) 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > Don't you just hate it when that happens? > > :-) > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > I've found this file in > > http://issues.apache.org/jira/browse/HARMONY-634 > > > > Tim decisded not to commit it as it was not used at the moment > > > > I'll check if it solves the problem > > > > Thanks, > > Mikhail > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > The test still fails. > > > > > > I have not found any file named JustResources* in SVN. > > > > > > The only pack file I've found is HelloWorld.pack > > > > > > Do you remember who has added a JustResources there? Was it a JIRA issue > > > reported by you? > > > > > > Thanks, > > > Mikhail > > > > > > 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > > > > Bizzare. I moved it, but it didn't get added. Or at least, I think so. > > > > I did discover why the file wasn't included though at my end ... it > > > > wasn't part of the change set, so wasn't included in the patch. > > > > > > > > I've re-generated the patch with it in this time and attached to > > > > Harmony-1019 ... is that any better? > > > > > > > > Alex. > > > > > > > > On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > > > > I believe that the JustResources.pack file was moved to a different > > > > > location, and so the test was updated to reflect that new location. I > > > > > saw the same problem myself ... can you confirm that there is a file > > > > > in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I > > > > > think that's where the segment ended up. I didn't actually move the > > > > > file ... someone else did IIRC. > > > > > > > > > > Alex. > > > > > > > > > > > > > > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > One more problem caused by the patch: > > > > > > > > > > > > java.lang.NullPointerException at > > > > > > org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) > > > > > > at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) > > > > > > at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) > > > > > > at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) > > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > > > > > > > > > Thanks, > > > > > > Mikhail > > > > > > > > > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > > > > PopulationCodecTest is missing, but there are other new files in the patch. > > > > > > > > > > > > > > You can see all of them if open the patch with a text editor and seek for > > > > > > > "(revision 0)" substring > > > > > > > > > > > > > > Thanks, > > > > > > > Mikhail > > > > > > > > > > > > > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > > > Weird. I don't know what happened. I've attached PopulationCodec (a > > > > > > > > new file) separately to the bug report. There's also BHSDCodec, which > > > > > > > > is new in the patch, as well as PopulationCodecTest. Are they there > > > > > > > > too? > > > > > > > > > > > > > > > > Alex. > > > > > > > > > > > > > > > > On 08/
Re: Re: Adding new files to SVN and subsequently trying to update
Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: > OK, so for anyone else reading this thread (or googling for 'object of > the same name already exists'): > > 1) If it's a case insensitive filing system (e.g. Windows) then see > the Subversion FAQ: http://subversion.tigris.org/faq.html > 2) If it's a case senstive filing system, and the case is right, and > you're adding a new file to an open-source project and someone's > already committed that and you're trying to update to pretty much the > same file: > > 2a) Move the old file to a new name (e.g. mv AddedFile.java > AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) > 2b) Go into the .svn directory, and open up the file 'entries' > 2c) Where there is an entry like >name="AddedFile.java" > kind="file" > schedule="add" > revision="0"/> > then delete it from the entries file. It may well be marked as > read-only, so you'll either have to edit it on something that ignores > the readonly flag or mark it r/w first (chmod +w entries or attrib -r > entries) > 2d) svn up AddedFile.java (which brings it in) > 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the > changes are > 2f) Delete AddedFile.java.bak since it's no longer necessary. > > Repeat 2a-2f for as many new files as you've added. Swear, drink > caffeinated/alchoholic beverage of your choice, and vow to add as few > new files as possible in the future by writing humungous class files. > > Hope that's useful to anyone else in this position. > > Alex. > > On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: >> Can't even friggin delete it ... >> >> apple[pack200] svn up >> subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) >> svn: Failed to add file 'JustResources.pack': object of the same name >> is already scheduled for addition >> >> On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: >> > One thing that annoys me is when I submit new files, and do an update, >> > I get a message: >> > >> > apple[pack200] ls >> > HelloWorld.pack JustResources.pack >> > apple[pack200] svn up >> > subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) >> > svn: Failed to add file 'JustResources.pack': object of the same name >> > already exists >> > >> > The normal answer/faq "The case is wrong" doesn't apply -- I've got a >> > case sensitive file system. The problem is that the JustResources.pack >> > doesn't exist on the SVN branch that I'm working on at the moment, but >> > someone else has added it for me; and when I try update to their copy, >> > I get this message. >> > >> > Surely SVN can't be dozy enough that it doesn't realise that the >> > file's contents is exactly the same in this case, and/or offer to try >> > and merge it? Is there some kind of --stop-being-anal flag that I need >> > to pass to SVN
Re: Re: Adding new files to SVN and subsequently trying to update
OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position. Alex. On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > One thing that annoys me is when I submit new files, and do an update, > I get a message: > > apple[pack200] ls > HelloWorld.pack JustResources.pack > apple[pack200] svn up > subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) > svn: Failed to add file 'JustResources.pack': object of the same name > already exists > > The normal answer/faq "The case is wrong" doesn't apply -- I've got a > case sensitive file system. The problem is that the JustResources.pack > doesn't exist on the SVN branch that I'm working on at the moment, but > someone else has added it for me; and when I try update to their copy, > I get this message. > > Surely SVN can't be dozy enough that it doesn't realise that the > file's contents is exactly the same in this case, and/or offer to try > and merge it? Is there some kind of --stop-being-anal flag that I need > to pass to SVN to convince it to do the work properly? > > The wisdom of 'well, just delete the file and update' is all well and > good, but (a) I want to check that the file's been added properly, and > (b) see if any changes have been made between the patch that I sent up > and what's currently in SVN. If I just delete it, I'm taking it on > faith that it's the same as it was before (and, for that matter, that > it's been added successfully). > > It's also a right pain when it's not just one or two, but perhaps a > handful (7) of new files. > > Is there any way of configuring either the command-line update or > subclipse to get it right, or am I doomed to this process every time I > create a new file? > > Alex. > > On 10/08/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: > > [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] > > > > Mikhail Loenko resolved HARMONY-1019. > > - > > > > Resolution: Fixed > > > > Alex, > > the patch was applied in revision 430314 > > missing copyrights were added to the new files > > please let me know if it's OK for you > > > > > Adding RunCodec and segment encoding tests > > > -- > > > > > > Key: HARMONY-1019 > > > URL: http://issues.apache.org/jira/browse/HARMONY-1019 > > > Project: Harmony > > > Issue Type: Improvement > > > Components: Classlib > > >Reporter: Alex Blewitt > > > Assigned To: Mikhail Loenko > > >Priority: Minor > > > Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java > > > > > > > > > This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently,
Re: Adding new files to SVN and subsequently trying to update
Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq "The case is wrong" doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: > [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] > > Mikhail Loenko resolved HARMONY-1019. > - > > Resolution: Fixed > > Alex, > the patch was applied in revision 430314 > missing copyrights were added to the new files > please let me know if it's OK for you > > > Adding RunCodec and segment encoding tests > > -- > > > > Key: HARMONY-1019 > > URL: http://issues.apache.org/jira/browse/HARMONY-1019 > > Project: Harmony > > Issue Type: Improvement > > Components: Classlib > >Reporter: Alex Blewitt > > Assigned To: Mikhail Loenko > >Priority: Minor > > Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java > > > > > > This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). > > Note to whoever applies this fix: please apply this fix as-is first (and commit) and then apply any typographical fixes/renames/spaces and commit a second time. It's a real nightmare trying to update-and-merge code after I've submitted it and minor changes have been made to this patch file prior to committing. At least if you commit it as is first, I can then easily update to that version and then merge upwards to take into account your changes automatically. Thanks! > > -- > 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]
Adding new files to SVN and subsequently trying to update
One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq "The case is wrong" doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] Mikhail Loenko resolved HARMONY-1019. - Resolution: Fixed Alex, the patch was applied in revision 430314 missing copyrights were added to the new files please let me know if it's OK for you > Adding RunCodec and segment encoding tests > -- > > Key: HARMONY-1019 > URL: http://issues.apache.org/jira/browse/HARMONY-1019 > Project: Harmony > Issue Type: Improvement > Components: Classlib >Reporter: Alex Blewitt > Assigned To: Mikhail Loenko >Priority: Minor > Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java > > > This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). > Note to whoever applies this fix: please apply this fix as-is first (and commit) and then apply any typographical fixes/renames/spaces and commit a second time. It's a real nightmare trying to update-and-merge code after I've submitted it and minor changes have been made to this patch file prior to committing. At least if you commit it as is first, I can then easily update to that version and then merge upwards to take into account your changes automatically. Thanks! -- 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: Re: Re: Re: Re: [classlib][pack200] Status update
Don't you just hate it when that happens? :-) On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: I've found this file in http://issues.apache.org/jira/browse/HARMONY-634 Tim decisded not to commit it as it was not used at the moment I'll check if it solves the problem Thanks, Mikhail 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > The test still fails. > > I have not found any file named JustResources* in SVN. > > The only pack file I've found is HelloWorld.pack > > Do you remember who has added a JustResources there? Was it a JIRA issue > reported by you? > > Thanks, > Mikhail > > 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > > Bizzare. I moved it, but it didn't get added. Or at least, I think so. > > I did discover why the file wasn't included though at my end ... it > > wasn't part of the change set, so wasn't included in the patch. > > > > I've re-generated the patch with it in this time and attached to > > Harmony-1019 ... is that any better? > > > > Alex. > > > > On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > > I believe that the JustResources.pack file was moved to a different > > > location, and so the test was updated to reflect that new location. I > > > saw the same problem myself ... can you confirm that there is a file > > > in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I > > > think that's where the segment ended up. I didn't actually move the > > > file ... someone else did IIRC. > > > > > > Alex. > > > > > > > > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > One more problem caused by the patch: > > > > > > > > java.lang.NullPointerException at > > > > org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) > > > > at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) > > > > at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) > > > > at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > > PopulationCodecTest is missing, but there are other new files in the patch. > > > > > > > > > > You can see all of them if open the patch with a text editor and seek for > > > > > "(revision 0)" substring > > > > > > > > > > Thanks, > > > > > Mikhail > > > > > > > > > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > Weird. I don't know what happened. I've attached PopulationCodec (a > > > > > > new file) separately to the bug report. There's also BHSDCodec, which > > > > > > is new in the patch, as well as PopulationCodecTest. Are they there > > > > > > too? > > > > > > > > > > > > Alex. > > > > > > > > > > > > On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > Hi Alex > > > > > > > > > > > > > > Thanks for the patch! > > > > > > > > > > > > > > I have a problem with integration: this classes > > > > > > > org.apache.harmony.archive.internal.pack200.CodecEncoding > > > > > > > refers to the PopulationCodec class that seems to be missing > > > > > > > > > > > > > > I'm trying to apply 'patch' [1]. Am I doing anything wrong? > > > > > > > > > > > > > > Thanks, > > > > > > > Mikhail > > > > > > > > > > > > > > [1] http://issues.apache.org/jira/secure/attachment/12338321/patch > > > > > > > > > > > > > > 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > > > I've been getting further towards the Pack200 implementation with > > > > > > > > finishing off the codecs that are used to decode values from the file. > > > > > > > > Although most of the default codecs were in place, the pack200 spec >
Re: Re: Re: Re: Re: [classlib][pack200] Status update
I'm pretty sure that I added it in a different location at one point. I've added a new patch to the Harmony-1019 that supersedes the others, and it's got JustResources in it. Could you try that one instead? Apologies for all the hastle :-) Alex. On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: The test still fails. I have not found any file named JustResources* in SVN. The only pack file I've found is HelloWorld.pack Do you remember who has added a JustResources there? Was it a JIRA issue reported by you? Thanks, Mikhail 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > Bizzare. I moved it, but it didn't get added. Or at least, I think so. > I did discover why the file wasn't included though at my end ... it > wasn't part of the change set, so wasn't included in the patch. > > I've re-generated the patch with it in this time and attached to > Harmony-1019 ... is that any better? > > Alex. > > On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > I believe that the JustResources.pack file was moved to a different > > location, and so the test was updated to reflect that new location. I > > saw the same problem myself ... can you confirm that there is a file > > in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I > > think that's where the segment ended up. I didn't actually move the > > file ... someone else did IIRC. > > > > Alex. > > > > > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > One more problem caused by the patch: > > > > > > java.lang.NullPointerException at > > > org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) > > > at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) > > > at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) > > > at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > > > Thanks, > > > Mikhail > > > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > PopulationCodecTest is missing, but there are other new files in the patch. > > > > > > > > You can see all of them if open the patch with a text editor and seek for > > > > "(revision 0)" substring > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > Weird. I don't know what happened. I've attached PopulationCodec (a > > > > > new file) separately to the bug report. There's also BHSDCodec, which > > > > > is new in the patch, as well as PopulationCodecTest. Are they there > > > > > too? > > > > > > > > > > Alex. > > > > > > > > > > On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > Hi Alex > > > > > > > > > > > > Thanks for the patch! > > > > > > > > > > > > I have a problem with integration: this classes > > > > > > org.apache.harmony.archive.internal.pack200.CodecEncoding > > > > > > refers to the PopulationCodec class that seems to be missing > > > > > > > > > > > > I'm trying to apply 'patch' [1]. Am I doing anything wrong? > > > > > > > > > > > > Thanks, > > > > > > Mikhail > > > > > > > > > > > > [1] http://issues.apache.org/jira/secure/attachment/12338321/patch > > > > > > > > > > > > 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > > I've been getting further towards the Pack200 implementation with > > > > > > > finishing off the codecs that are used to decode values from the file. > > > > > > > Although most of the default codecs were in place, the pack200 spec > > > > > > > allows for dynamic switching to arbitrary codecs should the compressor > > > > > > > warrant it, including a population-based encoding for (in)frequent > > > > > > > values. I've submitted Harmony 1019 with the patch; if someone could > > > > > > > apply that, I'd be grateful. > > > > > > > > > > > > > > At pres
Re: Re: Exceptions found while running servlet...
On 10/08/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
I've looked into this, I feel puzzled, the stack trace shows that:
org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89)
but there are checks for overflow:
if (0 <= offset && offset <= buffer.length && 0 <= count
&& count <= buffer.length - offset){
...
}
What would happen if you were writing out "" and the buffer was
zero-sized? Should it be offset < buffer.length instead of offset <=
buffer.length?
Not knowing where the code is, this is just a guess, but if
buffer.length is the size, then the range would be [0,buffer.length-1]
which suggests a less-than would fix that type of issue ...
(Of course, I could be completely wrong :-)
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: BASE64Encoder class missing?
On 10/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Anthony Green wrote: > On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: >> Yes- the idea is to provide that "suncompat.jar" for that reason with >> those clases in the sun.* namespace that user apps depend on. > > This way lies madness. I urge you to take a strong stand against bad > applications. Oh, don't get me wrong - we really want to. But we want adoption of the harmony codebase as well. We think that we have a reasonable balance - provide the functionality in an separable, modular way at first to make it easy for people to try and adopt harmony. May I suggest that we try and: 1) Make available a suncompat.jar, which re-writes calls to o.a.h or similar (or subclasses them ...) 2) Explicitly don't make it part of the default classpath ala 'tools.jar' in the standard Sun implementation when running HarmonyVM code 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the suncompat in the classpath' That way, out-of-the-box we don't have it, but there's an easy fix for people who trip up over it. However, if people just need to get it running, then they have a trivial workaround that doesn't involve changing their code. The same could also be provided for code that depends on sun.JavaC or whatever ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: [classlib][pack200] Status update
Bizzare. I moved it, but it didn't get added. Or at least, I think so. I did discover why the file wasn't included though at my end ... it wasn't part of the change set, so wasn't included in the patch. I've re-generated the patch with it in this time and attached to Harmony-1019 ... is that any better? Alex. On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > One more problem caused by the patch: > > java.lang.NullPointerException at > org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) > at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) > at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) > at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > Thanks, > Mikhail > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > PopulationCodecTest is missing, but there are other new files in the patch. > > > > You can see all of them if open the patch with a text editor and seek for > > "(revision 0)" substring > > > > Thanks, > > Mikhail > > > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > > Weird. I don't know what happened. I've attached PopulationCodec (a > > > new file) separately to the bug report. There's also BHSDCodec, which > > > is new in the patch, as well as PopulationCodecTest. Are they there > > > too? > > > > > > Alex. > > > > > > On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Hi Alex > > > > > > > > Thanks for the patch! > > > > > > > > I have a problem with integration: this classes > > > > org.apache.harmony.archive.internal.pack200.CodecEncoding > > > > refers to the PopulationCodec class that seems to be missing > > > > > > > > I'm trying to apply 'patch' [1]. Am I doing anything wrong? > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > [1] http://issues.apache.org/jira/secure/attachment/12338321/patch > > > > > > > > 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > I've been getting further towards the Pack200 implementation with > > > > > finishing off the codecs that are used to decode values from the file. > > > > > Although most of the default codecs were in place, the pack200 spec > > > > > allows for dynamic switching to arbitrary codecs should the compressor > > > > > warrant it, including a population-based encoding for (in)frequent > > > > > values. I've submitted Harmony 1019 with the patch; if someone could > > > > > apply that, I'd be grateful. > > > > > > > > > > At present, the pack200 algorithm gets as far as the inner class > > > > > definitions, but I've still got to decode the annotations and > > > > > bytecode. I'm thinking that as a first-cut, I will ignore any pack > > > > > files with annotations in and plough through the bytecode so that we > > > > > can at least start using it for simple pack files. > > > > > > > > > > I've got a bit of work left to integrate the dynamic switching of band > > > > > encodings (but that's OK since most of the simple pack files only use > > > > > the default) that will involve a bit of refactoring, and essentially > > > > > then just the bytecode (as long as there are no annotations). I don't > > > > > think it will be too long before we can unpack simple files on some of > > > > > the lower-quality settings :-) > > > > > > > > > > Also, when I get around to implementing some of the coding (as opposed > > > > > to decoding), I'm pretty sure that some of the techniques might be > > > > > useful for compressing arbitrary data streams. It would be interesting > > > > > to
Re: Re: Re: [classlib][pack200] Status update
I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: One more problem caused by the patch: java.lang.NullPointerException at org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > PopulationCodecTest is missing, but there are other new files in the patch. > > You can see all of them if open the patch with a text editor and seek for > "(revision 0)" substring > > Thanks, > Mikhail > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > Weird. I don't know what happened. I've attached PopulationCodec (a > > new file) separately to the bug report. There's also BHSDCodec, which > > is new in the patch, as well as PopulationCodecTest. Are they there > > too? > > > > Alex. > > > > On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > Hi Alex > > > > > > Thanks for the patch! > > > > > > I have a problem with integration: this classes > > > org.apache.harmony.archive.internal.pack200.CodecEncoding > > > refers to the PopulationCodec class that seems to be missing > > > > > > I'm trying to apply 'patch' [1]. Am I doing anything wrong? > > > > > > Thanks, > > > Mikhail > > > > > > [1] http://issues.apache.org/jira/secure/attachment/12338321/patch > > > > > > 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > > > > I've been getting further towards the Pack200 implementation with > > > > finishing off the codecs that are used to decode values from the file. > > > > Although most of the default codecs were in place, the pack200 spec > > > > allows for dynamic switching to arbitrary codecs should the compressor > > > > warrant it, including a population-based encoding for (in)frequent > > > > values. I've submitted Harmony 1019 with the patch; if someone could > > > > apply that, I'd be grateful. > > > > > > > > At present, the pack200 algorithm gets as far as the inner class > > > > definitions, but I've still got to decode the annotations and > > > > bytecode. I'm thinking that as a first-cut, I will ignore any pack > > > > files with annotations in and plough through the bytecode so that we > > > > can at least start using it for simple pack files. > > > > > > > > I've got a bit of work left to integrate the dynamic switching of band > > > > encodings (but that's OK since most of the simple pack files only use > > > > the default) that will involve a bit of refactoring, and essentially > > > > then just the bytecode (as long as there are no annotations). I don't > > > > think it will be too long before we can unpack simple files on some of > > > > the lower-quality settings :-) > > > > > > > > Also, when I get around to implementing some of the coding (as opposed > > > > to decoding), I'm pretty sure that some of the techniques might be > > > > useful for compressing arbitrary data streams. It would be interesting > > > > to see what other uses there are for the codecs. > > > > > > > > Onwards, upwards, and/or sideways, > > > > > > > > Alex. > > > > > > > > - > > > > 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][summary] Exception throwing compatibility
I think that as long as the spec says throws java.x.Y, and we throw a java.x.Y (or an o.a.h subclass of java.x.Y) then that meets the spec. I think the wording could be clearer though; for example, the 'public superclass' is almost certainly meant to be 'an exception in the standard Java class libraries'. For a start, sun.io.MalformedInputException might actually be a subclass of sun.io.GeneralInputException, which has the ACC_PUBLIC bit set (even though it's not a defined class in the Java spec). Perhaps "If the exception thrown is a direct instance of an exception from the Java libraries, we will throw the same exception; if it is an instance of an exception not in the Java libraries then we will throw an equivalent o.a.h exception or a parent exception in the Java libraries". It's possible that there's an exception class which is abstract that we must create a subclass for, though off the top of my head I can't think of an abstract exception class in the Java libraries ... Alex. On 09/08/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: "But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. " I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][pack200] Status update
Weird. I don't know what happened. I've attached PopulationCodec (a new file) separately to the bug report. There's also BHSDCodec, which is new in the patch, as well as PopulationCodecTest. Are they there too? Alex. On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Hi Alex Thanks for the patch! I have a problem with integration: this classes org.apache.harmony.archive.internal.pack200.CodecEncoding refers to the PopulationCodec class that seems to be missing I'm trying to apply 'patch' [1]. Am I doing anything wrong? Thanks, Mikhail [1] http://issues.apache.org/jira/secure/attachment/12338321/patch 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > I've been getting further towards the Pack200 implementation with > finishing off the codecs that are used to decode values from the file. > Although most of the default codecs were in place, the pack200 spec > allows for dynamic switching to arbitrary codecs should the compressor > warrant it, including a population-based encoding for (in)frequent > values. I've submitted Harmony 1019 with the patch; if someone could > apply that, I'd be grateful. > > At present, the pack200 algorithm gets as far as the inner class > definitions, but I've still got to decode the annotations and > bytecode. I'm thinking that as a first-cut, I will ignore any pack > files with annotations in and plough through the bytecode so that we > can at least start using it for simple pack files. > > I've got a bit of work left to integrate the dynamic switching of band > encodings (but that's OK since most of the simple pack files only use > the default) that will involve a bit of refactoring, and essentially > then just the bytecode (as long as there are no annotations). I don't > think it will be too long before we can unpack simple files on some of > the lower-quality settings :-) > > Also, when I get around to implementing some of the coding (as opposed > to decoding), I'm pretty sure that some of the techniques might be > useful for compressing arbitrary data streams. It would be interesting > to see what other uses there are for the codecs. > > Onwards, upwards, and/or sideways, > > Alex. > > - > 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: [classlib] Re: [jira] Created: (HARMONY-1088) ava.lang.NoClassDefFoundError: sun/misc/BASE64Encoder
I concur. We should not have any sun.* packages. Any program that explicitly depends on a sun.* class should fail. Alex. On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: I'm not sure it's legal to put any classes to sun.* packages Opinions? Thanks, Mikhail 2006/8/8, Martín Córdova (JIRA) <[EMAIL PROTECTED]>: > ava.lang.NoClassDefFoundError: sun/misc/BASE64Encoder > -- > > Key: HARMONY-1088 > URL: http://issues.apache.org/jira/browse/HARMONY-1088 > Project: Harmony > Issue Type: Bug > Environment: Windows XP SP2 latest Harmony JRE as of aug-8-2006 >Reporter: Martín Córdova > > > Harmony does not include this class. It's not a standard class, but has been of common usage for many years, and most JDKs (Sun, IBM and BEA) provide it under the SAME package. I think that there is no sense in not providing it under the usual package, it just breaks existing code. > > BTW, this JRE is seems to be running real fast. > > > > -- > 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]
[classlib][pack200] Status update
I've been getting further towards the Pack200 implementation with finishing off the codecs that are used to decode values from the file. Although most of the default codecs were in place, the pack200 spec allows for dynamic switching to arbitrary codecs should the compressor warrant it, including a population-based encoding for (in)frequent values. I've submitted Harmony 1019 with the patch; if someone could apply that, I'd be grateful. At present, the pack200 algorithm gets as far as the inner class definitions, but I've still got to decode the annotations and bytecode. I'm thinking that as a first-cut, I will ignore any pack files with annotations in and plough through the bytecode so that we can at least start using it for simple pack files. I've got a bit of work left to integrate the dynamic switching of band encodings (but that's OK since most of the simple pack files only use the default) that will involve a bit of refactoring, and essentially then just the bytecode (as long as there are no annotations). I don't think it will be too long before we can unpack simple files on some of the lower-quality settings :-) Also, when I get around to implementing some of the coding (as opposed to decoding), I'm pretty sure that some of the techniques might be useful for compressing arbitrary data streams. It would be interesting to see what other uses there are for the codecs. Onwards, upwards, and/or sideways, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [equinox-dev] buddy classloading & deadlock
I forwarded the ZIP file that Tom had posted to the harmony-dev list so that we could check that it wouldn't cause a problem. However, the mail list software thought it was spam, so it never made it ... I did CC Tom, though, and he confirmed that it wasn't a problem with harmony. I can forward the original zip file to people individually if we want to confirm it to, and/or to forward messages on to Tom. Alex. -- Forwarded message -- From: Tom Huybrechts Date: 04-Aug-2006 22:58 Subject: Re: [equinox-dev] buddy classloading & deadlock NOT A CONTRIBUTION I've tried it myself and I can confirm: using Harmony this does not cause a deadlock. Nice job :) Tom ps: I'm not on the list so if you need any further information from me, please CC. On 8/4/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: Tom's given me the OK to forward this message to the harmony-dev list; it's the zip file that gave the problem with the buddy classloading in Eclipse on a Sun VM. It would be good if we can verify that it doesn't cause the same error here. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: [equinox-dev] buddy classloading & deadlock
This message came up on equinox-dev recently. It highlights a
potential deadlock when the Sun VM locks the classloader prior to
calling loadClassInternal. I have no idea if this is an issue for the
VM we're using, but if it is, we ought to consider what can be done to
fix it.
Alex.
-- Forwarded message --
From: Thomas Watson
Date: 03-Aug-2006 16:32
Subject: Re: [equinox-dev] buddy classloading & deadlock
To: Equinox development mailing list
What vendor/version of the VM are you using?
There has been a long standing bug open against Sun on a similar
issue. It all boils down to the native VM locking the classloader
before loading a class from it using the ClassLoader.loadClassInternal
method. In your stacktrace below this happens when the VM calls
ClassLoader.loadClassInternal
(DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319).
The VM locks the classloader in native code before it ever calls into
the ClassLoader. This leaves us with no options, even if we override
the loadClassInternal method to make it non-synchronized it will make
no difference because the native code locks the ClassLoader no matter
what the method signature is for loadClassInternal. I have been told
that Sun plans to fix this in a future release of the VM, it may be
fixed in the latest 1.5 Sun VM. The IBM VMs have fixed this issue,
they will NOT lock the classloader before invoking it from the native
VM code.
Tom
---
Hi all,
I noticed that multithreading combined with buddy classloading can
produce some scary deadlocks. I had one in a project last week and
managed to recreate it in a toy example. Now I'm wondering if this is
just one of the dangers of breaking the classloading hierarchy or if
the framework could do something to avoid this ?
My toy example (also in attachment):
The main project has just one Application class:
public class Application implements IPlatformRunnable{
public Object run(Object args) throws Exception {
new Activator();
return true;
}
}
and the dependent project has an Activator
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
new Thread(new Runnable() {
public void run() {
try {
Class.forName("main.Application");
} catch (ClassNotFoundException e) { }
}).start();
// let other thread run to induce deadlock
try { Thread.sleep(100); } catch (InterruptedException e) {}
}
public void stop(BundleContext context) throws Exception {}
}
The main project depends on dependent, and the dependent project has a
global buddy policy.
This causes the following deadlock:
Thread [main] (Suspended)
owns: DefaultClassLoader (id=16)
waiting for: DefaultClassLoader (id=15)
ClasspathManager.findLocalClassImpl(String,
ClassLoadingStatsHook[]) line: 422
ClasspathManager.findLocalClass(String) line: 410
DefaultClassLoader.findLocalClass(String) line: 188
BundleLoader.findLocalClass(String) line: 339
SingleSourcePackage.loadClass(String) line: 37
BundleLoader.findClass(String, boolean) line: 388
BundleLoader.findClass(String) line: 352
DefaultClassLoader.loadClass(String, boolean) line:
83
DefaultClassLoader(ClassLoader).loadClass(String)
line: 251
DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319
Application.run(Object) line: 11
PlatformActivator$1.run(Object) line: 78
EclipseAppLauncher.runApplication(Object) line: 92
EclipseAppLauncher.start(Object) line: 68
EclipseStarter.run(Object) line: 400
EclipseStarter.run(String[], Runnable) line: 177
NativeMethodAccessorImpl.invoke0(Method, Object,
Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[])
line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[])
line: 25
Method.invoke(Object, Object...) line: 585
Main.invokeFramework(String[], URL[]) line: 336
Main.basicRun(String[]) line: 280
Main.run(String[]) line: 977
Main.main(String[]) line: 952
Thread [Thread-1] (Suspended)
owns: DefaultClassLoader (id=15)
waiting for: DefaultClassLoader (id=16)
ClasspathManager.findLocalClassImpl(String,
ClassLoadingStatsHook[]) line: 422
ClasspathManager.findLocalClass(String) line: 410
DefaultClassLoader.findLocalClass(String) line: 188
BundleLoader.findLocalClass(String) line: 339
BundleLoader.findClass(String, boolean) line: 391
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 31/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > Don't get me wrong; being able to specify minimum/maximum is a > reasonable idea for optimising a VM if you know what to put; but by > default, there shouldn't be any arbitrary limitations based on the > value of a #define constant ... So, would you be satisfied if the VM defaulted to, say, 3/4 of total physical memory available? (not a #define, but a value detected at startup) I would like to get some concrete practical conclusion from the whole discussion. The question should be: "Why have a maximum?" and not "What should the maximum be?" An algorithm that implicitly assumes a maximum is wrong. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 31/07/06, will pugh <[EMAIL PROTECTED]> wrote: What does matter is whether you are using more virtual memory than you have physical memory. I agree completely. But the VM developer (in C) does not know how much memory I have present. Why should it assume 256m? I have more memory than that on my laptop available, and a lot more on my desktop. And the problem with an arbitrary default is that if I want to disable that, I have to supply extra parameters. Don't get me wrong; being able to specify minimum/maximum is a reasonable idea for optimising a VM if you know what to put; but by default, there shouldn't be any arbitrary limitations based on the value of a #define constant ... My understanding is that one of the important reasons for having a Max on the allocation availble to a VM from the beginning was to make sure the heap never used more than physical memory. Agreed, but the strategy falls apart when Max << TotalAvailable. When JVMs first started, 256m might have sound like a reasonable max, but these days machines have >> 512m available. Thus, there shouldn't be a Max by default. You can't even do an analysis based on how much memory is currrently free. If I'm running a JVM and there's (say) 400m available, would you pick that? What happens if it was running out of memory, and I closed down some memory hog or IDE to free up some space? Why limit it just to 400m? In fact, can you think of any other system with automatic memory management (Smalltalk, C++ with GC, Python, Ruby, PHP, Basic, C#) that decides on a random upper limit 'to protect the user'? I can't think of a single instance when the default max has been helpful for me. Zones sound like an interesting strategy, but I'm not sure they help you much with wanting make the default memory option "unlimited". Generational is good at reducing the number of full GCs you do, but does not necassarily eliminate them. Zones were a completely orthogonal idea; I merely brought it up because they were something that I'd been thinking would be a good idea w.r.t. VMs, and since there were a few people here that were talking about low-level VM issues, thought it would be worth mentioning :-) The zones strategy you suggest may work well with apps that have a lot of class loaders and allocate somewhat evenly across them, but I think it may cause a lot of overhead. Would your approach be generational? Would you need Write Barriers for both references from other generations as well as other Class Loaders? I've no idea if it would cause a lot of overhead. It might do. I'd imagine that each zone would have a nursery and mature generation, but possibly share some permanent generation. If you were to have a Web Application, would you basically need a write barrier for every string you allocate, since the String Class is loaded in a parent class loader? If so, this may cause more overhead than you would want for the stated benefit. I suspect that if a write barrier was needed, this would quickly kill any of the efficiencies. Perhaps there would be some other optimisations that could avoid such things? Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 30/07/06, will pugh <[EMAIL PROTECTED]> wrote: Isn't Full GCs a big problem? If have a bunch of pages in virtual memory, and need to do a full heap walk. Won't you basically have an exercise in page faults? Realistically, doesn't that happen for any full GC though, regardless of how they're laid out? Even if the JVM requests a single large contiguous space, it will still be treated as many pages by the OS, and you'll get a similar amount of page faults. It doesn't matter what virtual address space they're mapped into. One of the suggestions I put forward elsewhere was having several zones (one per classloader); the advantage would then be you could GC each zone separately, and potentially at different intervals. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 30/07/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Agree that maximum size is still desirable for system stability reason. :-) ( I hope the OS MM can be more intelligent to deal with overcommitment.) But here in this specific discussion context, I think the word `unlimit' or `infinite' is meaning `unlimit under certain limit'. Whatever the limit is can be defined by the clever OS (which returns a ENOMEM, for example) or user heuristics. Infinite in a computer science, rather than mathematical sense :-) For example, there may be practical reasons why 4Gb is the maximum (or 2Gb if signed pointers are used). But even if the OS has 512mb of memory, and (say) 256m free, there's no reason to limit the amount of memory that the JVM requests. The user will notice a slow-down in performance as soon as the *practical* limit is transgressed, but unless the user starts with a -Xmx option, the memory should be 'unlimited' in the 'largest amount of space that is possible'. Given that most OSs have virtual memory, why should the JVM decide that it's not going to use it? I'd argue that if not specified, the limit should be unlimited in the sense that the largest possible amount that the process can possible acquire. If the user wants to limit the amount of memory to prevent swapping, that's fine, but it has to be a user-supplied option and not a JVM-enforced-default. Let's face it, the only reason why -Xmx is used at all in almost all JVMs is not to limit the amount of space, but rather a workaround because the JVM gets it wrong. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 30/07/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Alex, you made good point. It is definitely possible to design GC with dynamic heap size, we will need is careful design for both convenience and performance. Besides the points I mentioned previously, performance tradeoff with heap size is yet another a factor. On one hand, the heap size has a minimal to keep all the live objects during the execution; on the other hand, a larger heap size trigers GC less frequently. So sometimes the GC needs to decide if it should increase the heap size or just trigger a collection, assuming the heap size is enough to hold all the live objects. Yes, there are obvious conditions like this which need to be decided :-) However, I'm sure that heuristics could play a part; if the GC remembers what it did from the previous run/runs, then perhaps it could guide what happens next. For example, if the last GC freed up (say) less than 5% of memory, the next decision would be to request more memory. Or, if a GC doesn't free up the requisite amount of memory, then a request for more memory could follow on as part of the same GC cycle. I'm pretty sure that hashtables have a built-in load factor (about 70% utilisation of buckets?) and that when the hashtable goes above the load factor, it rehashes. Could we not have some kind of load factor in the memory, such that a post-GC compaction triggers more memory when the load factor goes above a certain percentage (e.g. 70%)? Obviously, the numbers would have to be fine-tuned (or be subsituted with another -XX:GCLoadFactor non-non-standard option ;-) Of course, it's possible that this idea wouldn't work well at all ... Yes, to allocate/release blocks when needed is possible. I'd give you more cases that requires careful design. consider a case . For example, if the block is bigger than an OS page in size, even the GC design can perfectly allocate/release its blocks, the system memory is still fragmented. I would assume that a VM block size would be a multiple of OS page sizes, for obvious performance reasons, including the one that you mention. I can't see there being any benefit in not doing so ... can we determine what the OS page size is, either statically or dynamically? For example, on Mac OS X the page size is 4k, as returned by sysconf(_SC_PAGE_SIZE) in unistd.h ... Perhaps 4k would be a bit small, so some multiple of those is probably needed to round up the size. But some power-of-two multiple would probably be useful; you could take the page size and <<1 until it was bigger than a more reasonable number (e.g. 32k?) Another case is, GC sometimes needs to align the block to certain size boundary, which also leaves fragments in system space. Yet another case is, if the system memory space is already seriously fragmented, GC may not be able to utilize the remaining vacant space although the sum size of the fragments can be large. Yes, all true. The same happens with filing systems, too. But note that if the memory is already fragmented, asking the VM to start by attempting to claim a large space on a heap is almost certainly destined to fail. At least but having the memory split into blocks, it's more likely that you'll be able to obtain memory space and/or use it. Many of these point to OS/JVM interactions finally. I've been looking at this area. :-) Cool :-) I'm just an ideas man, mostly -- my C background is pretty slim, or else I'd like to help out. But I've still got to get the Pack200 stuff up and running, first. Speaking of ideas, I've often thought that allowing a VM to 'zone' out pages of related code would be an excellent idea. For example, if each ClassLoader had its own zone of pages, and that new instances of classes owned by that ClassLoader were created in its zone, then you'd have a way of partitioning the memory space without having to change any Java code. So, instead of having a global memory space with two or three generations, you'd have a set of them instead (perhaps each with their own generations). This would be great for J2EE servers that typically create their own ClassLoaders, normally one per app. Furthermore, when the app is stopped (and the ClassLoader unloaded) then all of the memory 'assigned to' that ClassLoader could be returned to the OS. It would also mean that if a J2EE server had many apps, and not all of them were being used, then the page(s) in the ClassLoader's zone could be paged out, and they'd not be needed to be paged in again until the app was requested. Back to the file system analogy; instead of having a single filesystem for all files (and the fragmentation that woudl go along with that), it's like having a separate filesystem for each J2EE app so that the app's files don't get mixed with each other. I've often thought this would be a really cool thing to do. Does the idea have any merit? Alex. - Terms of use : http://incubator.apache.org/harmo
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 29/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > Sorry, the first version would lead to integer overflow and the to assertion > failure. The updated patch should work. It runs Hello on Windows/ia32 with a warning > about reducing maximum heap size to the virtual address range it could allocate. This is done because GC needs to have contiguous address range for the heap, and allocates virtual address range upfront. It would seem that for an infinite amount of memory, attempting to allocate a contiguous address range for the heap would be a problem. It's also probably why other VMs have the -Xmx option, and attempt to obtain the range all in one go. However, if the GC is generational, why does it need to be contiguous? Why not allocate chunks per generation? Or, for that matter, why can't it be split into pages/blocks of memory? That way, you wouldn't need to attempt to allocate it all up front, but rather you could tack a new page/block onto the end of the memory list. Obviously, there would be special cases (like when allocating a large array that is greater than the page/block size) but all of these problems have been solved by filing systems in the past. I mean, it's not like creating a ZIP file attempts to allocate a contiguous block of 256Mb and then fills it up as files are added. (However, that is pretty much what happens when you create a DMG on Mac OS X ...) Incidentally, a very good book on file system design discusses the Be Filing System (BFS) and it's available at http://www.nobius.org/~dbg/practical-file-system-design.pdf Note that I'm mostly asking these questions in an attempt to find out why it can't be done, and/or how much would need to change to be able to do something like this instead. I can imagine that if there were some kind of page-on-demand memory obtaining, then you wouldn't need a -Xmx parameter (unless you wanted it), and that you'd be able to deal with this kind of DLL-in-the-middle problem that you saw on Windows. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On 29/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > 3) That it's necessary to put limits on a system that uses garbage > collection and should be able to release memory back to the OS at all? This point is quite moot. Most existing JVMs have sensible defaults, In DRLVM, I plan to do something similar for the defaults eventually, but have not got to it yet. Currently, it has hardcoded defaults of -Xms64m and -Xmx256m. But the point is, this is a hardcoded default maximum of 256m for no particularly good reason. Why should it not be infinity? In fact, it's really a bad idea to have any non-infinte number by default, because if your default is too small (which it will be for a number of situations e.g. heavy server processing, massive Eclipse installs etc.) then people *have* to override the default to allow their applications to run. So, answering your question, if you do not want to put any artificial limit to the memory used by the java heap, then do not specify any -Xmx and -Xms options, and the JVM will decide itself. The JVM will decide on another arbitrary default, though. If I don't specify a maximum, I don't expect there to be a maximum. If I'm running a J2EE system on a 3Gb PowerPC platform, why does the default not allow me to run a J2EE server that takes advantage of all the memory that I have? Why should it arbitrarily limit it to a small percentage of what is currently available? However, if you *do* want to limit the amount of memory used for the JVM, then these options are very useful. Agreed, when you do want to limit the resources (e.g. limiting each process to a 1Gb chunk on a multi-processor, multi-core system) would make sense. But if you *don't* want to limit it, you shouldn't specify -Xmx and there should be no limit. Let's face it, the only reason why J2EE servers (or indeed, Eclipse) allow you to put in your own VM args for -Xmx is because the default is too low for that particular use. There is absolutely no reason why an upper limit is needed from a user's perspective, and the fact that the VM chooses Math.random() as an upper limit for you is no help at all. If you do specify -Xmx2056m then the VM will agressively take up all that memory without releasing pages back to the OS, and for some VMs, will actually try to request that much memory when the VM starts up. Why not just request more memory when it's needed, and release it when it's not? Then the only maximum is how much the operating system can give. When was the last time you saw the message: "I'm sorry, Word cannot load the document. You will have to re-run Word with -Xmx1024m in order to be able to load it" Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [drlvm] string interning in java
On 29/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: Still, we need to have this functionality, because it is in spec. True, intern() is part of the spec, and GC-intern() will be much better :-) > However, by hard-coding the message like this, you're > guaranteeing that the VM will intern() the string "how are you?", even > if it never prints this message out (because it's in the constant > pool). This is not the case, at least for DRLVM (I do not know about other JVMs). The string literal in the .java file is compiled to the constant pool entry in the class file, and essentially, the whole contents of the class file is loaded to memory (native memory). No java object instances are created at this point. The memory (for the message key) is still taking up space in the constant pool for the class, though as part of the class loading process. From what I've seen, message keys tend to be longer than the equivalent field names (also stored in the constant pool). And that's before the String instance is created. We may consider the opportunity to save memory by not keeping the class file contents in memory, and loading it on demand, but I personally do not know for sure how is it done now. Neither do I :-) It might only load constants from the constant pool on demand, but my expectation is that the whole class's contents are loaded into memory from whatever storage container (e.g. Jar) that they came from. Perhaps the constants could be optimised in some kinds of ways e.g. by writing them out to a memory mapped temporary file. The java specification does not require eager loading of the string literals, and DRLVM in fact does not do it. Interesting. Perhaps I misunderstood the spec, but I was under the impression that all String literals were interned like this. Perhaps it's just because I've seen examples such as: private static final MESSAGE_HELLO_WORLD_KEY = "hello.world"; which, of course, would be assigned when the class is loaded (and thus the string literal interned approrpiately). Lazy instantiation of such keys would delay this behaviour. It only keeps space in class file if it is never used. Saving space on class loading is a separate issue, not related to strings interning. I think that they are related; but only in that the context of internationalisation of messages and message keys is often where the intern() is used (especially with respect to the way message key is initialised). However, the relationship is not symmetric; it's possible to discuss intern() without reference to any kind of message keys. > Importantly, it explains why the Eclipse NLS class uses static string > variables to refer to messages, and not to String literals for exactly > this reason. If you use a static string variable that is dynamically > initialised from a properties file, you only take the memory up when > you need to refer to that message actually, I think, this should read "... when you need to refer to any of messages contained in the resource bundle ..." True, the class loading will cause all messages in the same messages class/file to be loaded at once. (Bundle might be misleading here; an eclipse bundle/plug-in often has one messages class/file, but may have several.) The interned strings design does not precludes from garbage collecting interned strings. The patches I've sent in fact do just that. Yes, this sounds like a good plan. > In other words, all of the benefits of intern(), and yet none of the > disadvantages. Remind me again why we're not using this method for > doing messages in Harmony? The Eclipse approach for localizing messages from java code looks promising, but requires some work duplication or complex tooling support. As far as I understand, Eclipse approach is completely orthogonal to traditional localization approach, so it imposes no restrictions on using two approaches simultaneously. Feel free to submit patches to use it :) Yes, it should be possible to use this too. Eclipse also has tooling to search for string literals and propose replacements for them automatically ... http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/documents/3.1/message_bundles.html http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/tasks/tasks-188.htm http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/reference/ref-wizard-externalize-strings.htm The only issue might be that Eclipse uses an NLS class to do the in-lining of messages, so we'd either need to re-implement or to re-use the Eclipse NLS file directly. I think that discussions following on re: internationalisation should continue in the new thread created for that purpose. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [drlvm] string interning in java
On 29/07/06, Robert Lougher <[EMAIL PROTECTED]> wrote:
Which implies that freeing of the dynamically loaded string when the
class is unloaded is something special. It is not. Nor is an
interned string a memory leak. It will be collected when there are no
more references to it like any other object.
Just to be clear; an intern()'d string (assuming GC on the intern()
pool, which I doubt it is) will stay around as long as there's a
reference, just like any other GC object in Java.
However, the argument is equivalent to:
public class Argument {
public void method() {
String local = reader.readLine();
}
}
versus
public class Argument {
private static List local = new ArrayList();
public void method() {
local.add(reader.readLine());
}
}
In the former, the object is eligible for GC at the end of the method.
In the latter, it's eligible for GC when the class is unloaded. It's
not a memory leak in the traditional C sense, but it *is* a leak of
resources that is programmer error. A constant string pool of:
public class Argument {
public void method() {
getMessage("Some Key That Is Going To Be In The Intern Table");
}
}
will remain in the constant pool/intern pool until Argument.class is
unloaded, whereas
public class Argument {
public void method() {
getMessage(Thing.message);
}
}
will *only* get loaded when the Thing.class is loaded (which will be
delayed until the method is invoked). Furthermore, if it is defined
as:
public class Thing {
private static String message;
static {
message = reader.readLine()
};
}
then there's *no* resource taken up by this until Thing.class is
loaded, which in turn only happens when the first class needs to use
it. Additionally, it doesn't pollute the intern() pool, and as such,
you get GC for free when Thing.class is unloaded (and thus doesn't
care whether the intern() pool is GC or not).
In the case we have a perfect intern() GC mechanism, there's no
significant difference. In the case we have an imperfect intern() GC
mechanism (like, there is no GC) then it's demonstrably better.
Regardless of which approach is used, it's also worth noting that if
there are several Thing.classes (e.g. one for exceptions, one for
debug messages, one for info messages) then you only load the class
(sic) of messages that you use. If you never do a
log.debug(Debug.message), then you'll never load the Debug.class, so
no resources would ever be taken up. (Same applies whether they're
dynamically read fields or hard-coded string literals.) OTOH our
current approach to messages (stick all messages in one place for one
module) somewhat defeats this benefit, because you trigger the loading
of all messages as soon as you need the first one. A slightly smarter
solution might be to have a single messages file (for ease of
management/translation) but many message classes (e.g. Info.class,
Debug.class, Exception.class) per module; that way, when the first
message is printed, you only load a sub-set of the messages for that
module.
Of course, one could put the argument forward that this is all
premature optimisation and thus we shouldn't do anything :-) But we
have a tool (Eclipse) that can do all of this for us at the moment,
and we've already got the experience of others investigating the
memory footprint of Eclipse and determining that the cause of memory
bloat was the String intern() calls; and the tools/mechanism to fix
this problem. We could, of course, reinvent the wheel (c.f. HashCode
object when there's a tool to generate decent hashCode()/equals()
implementations) -- but I'd be interested in knowing why our proposed
solution is better or what it gives us that the Eclipse NLS
infrastructure doesn't.
Oh, and for the record -- I think a GC intern() would be a cool idea.
Let's hope it happens, because there's bound to be programs that do
silly intern()'ing that need help. Hopefully Harmony doesn't need to
be one of them :-)
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[rant] Memory options in VM -- why is the default not 'unlimited'
I believe this might be of general interest and worth debating here, from a post on EclipseZone: http://www.eclipsezone.com/eclipse/forums/t77021.html#92035043 "Am I the only one that's frustrated that: 1) The -X options even exist at all. After all, they're so standard now (e.g. -Xmx256m) that the point of calling them 'non-standard' options is pretty much laughable. 2) That they felt the need to build another level of non-non-standard into command line options such that -XX is even necessary 3) That it's necessary to put limits on a system that uses garbage collection and should be able to release memory back to the OS at all? I mean, what is the point in artificially limiting the size of these anyway? I can see that there may be optimal tweaks that you'd want to perform on some server systems (e.g. initial sizes) and maybe for some constrained systems the maximal size too; but why isn't the default 'unlimited'? The only time I should see an OutOfMemoryError is when the OS refuses to give any more memory to the app, not when some artificial hard-coded limit is reached in some random defaults hard-coded into a C file. Name one other language/system/application that has such an arbitrary self-enforced maximal non-unlimited default built in. Heck, even OS resources (like ulimit or #file handles) are specified at the OS, not the application, level. With any luck, open-source VMs like Harmony won't be as anal with their memory management, and the default for such things will be unlimited. Just one of the benefits of an open-source version; you won't have to be artificially cramped by random decisions at the VM level." Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [drlvm] string interning in java
On 29/07/06, Robert Lougher <[EMAIL PROTECTED]> wrote:
The interned String table should be garbage-collected. If the only
reference to an interned String is from the class constant pool it
will be collected when the class is unloaded. If the intern table is
preventing Strings from being collected it's a bug in the VM!
Garbage collection only occurs when there's no references left. String
literals in classes are stored in the constant pool; the constant pool
thus points to the (auto-intern()'d) Strings. So constant string
literals can never be garbage collected, regardless of whether an
intern()'d table is GC'd or not.
Ergo, any code of the form Message.get("some text") has just wasted
"somem text".length() chars in the intern() table permanently, until
that class gets unloaded, *regardless of whether that message is ever
used*
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [drlvm] string interning in java
On 28/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Alex Blewitt wrote:
> There's a heck of a lot wrong with intern()
My original observation was that interning makes perfect sense
for localized log messages, because the code like
println(MessageBundle.get("how are you?"));
Yes, but I disagree with your conclusion; to me, it doesn't make
sense. Which is better, performance for printing out a message, or
memory requirements? Like I said, unless you are in a seriously
time-critical loop (in which case, you'd have to wonder why printing
out any kind of message at all is desired), the time taken to look up
the message from the bundle is really going to be of no/little
concern. However, by hard-coding the message like this, you're
guaranteeing that the VM will intern() the string "how are you?", even
if it never prints this message out (because it's in the constant
pool). Many, many, messages are never printed out in the course of a
normal code flow; yet they're all cached in the intern() pool, and in
fact, have to be because of the way that constant pools are supposed
to work.
So this 'perfect sense' is trading off speed of lookup of a message
for memory requirements, even if it's never used. If it's never used,
the speed of lookup is irrelivant (think exception messages like
'Invalid URL format') but it still takes up space.
Reading the Eclipse Performance Bloopoers is a very good summary of
the techniques taken by the Eclipse development team to try and limit
the amount of memory used, and should be read by anyone with an
interest in intern()'d strings, or for that matter, messages in
general:
http://wiki.eclipse.org/index.php/Performance_Bloopers
Importantly, it explains why the Eclipse NLS class uses static string
variables to refer to messages, and not to String literals for exactly
this reason. If you use a static string variable that is dynamically
initialised from a properties file, you only take the memory up when
you need to refer to that message (e.g. in the constructor of an
exception in an exceptional condition). Furthermore, because it's a
dynamically read in string, it doesn't pollute the intern() pool, and
thus when the class is unloaded, the string is unloaded too. Once a
String is intern()'d, it's like a memory leak -- you'll never see that
memory again.
Lastly, the Eclipse approach ensures that there are no String values
saved as keys anywhere in the system -- they're always referred to by
the static field contents. So regardless of whether they're intern()'d
or not, you are always comparing by reference anyway.
In other words, all of the benefits of intern(), and yet none of the
disadvantages. Remind me again why we're not using this method for
doing messages in Harmony?
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [drlvm] string interning in java
There's a heck of a lot wrong with intern().
1) People claim inefficiencies, without actually measuring them (see
other points I've made about permature optimisation)
2) The claim that performing an intern() reduces comparisons (because
you just do a pointer compare) is, in most cases, completely
irrelivant. When you perform an intern(), it has to search through all
previously intern()'d strings, and perform hashCode() and equals() on
each match it considers. Thus, a == b.intern() is equivalent to
a.hashCode()==b.hashCode() && a.equals(b) anyway. All you're doing is
moving where the delay happens.
It *really* gets on my nerves when developers do things like a ==
bufferedReader.readLine().intern() claiming that it speeds things up,
when the cost is just moving place. And in these situations, it's
their fault if they get out of OOM messages :-)
And with the point regarding 'fast lookup of messages' -- the Eclipse
messaging mechanism (by loading them into static variables) has
*exactly* the same effect, whilst not polluting any global pools.
Remember that pointer comparison will work when it's the same pointer,
and in the case it's not, it will do the equals() comparison. Unless
you're providing a really, really, really fast logging system then the
cost of printing/looking up a message is an unbelivably minor part of
a system. You probably have much more wastage in (e.g.)
StringBuffer().append(msg1).append(object).append(msg2), instead of
writer.write(msg1),write(object),write(msg2). For that matter,
parameterised messages (e.g. File {0} is broken) are going to cause
exactly these kind of StringBuffer-related horribleness.
The only time intern() should be used is by the compiler when
interning string literals in compiled source code. I'd go as far as
saying that the use of intern() should be marked as a warning, if not
an error, in any decent IDE.
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] metadata approach
The question I'd like to raise now is – aren't we ready for TestNG right now? For example, we could replace our harness from jUnit to TestNG and lazily start converting of some failing and platform dependent tests to javadoc version of TestNG. Thought? Suggestions? Opposite opinions? I think that if the decision is made to go down the TestNG route (and my hope is that we will) then this sounds like a good approach. Of course, everyone would have to be happy at the migration (sounds like we're heading towards a vote on it) and like you say, we can always use the TestNG harness to run the existing set of JUnit tests, so we should still be in the same position. As for the metadata decisions (e.g. platforms) there still seems to be some ways we can achieve this. Do we want to finish deciding that before the migration, or are we confident that we will get to a point where a decision is made and we can start transitioning beforehand? Lastly, do we have entries (e.g. on the wiki) about how to write new tests that are either (a) compatible with JUnit+TestNG, or (b) use TestNG alone? It seems like this would be a good way to ensure new tests are TestNG-compatible and thus increase the coverage of TestNG tests. We probably also need to have pointers at least for how to run the tests from My Favourite IDE (tm) and/or the build itself. Are there any other systems e.g. JUnitReport that we need to consider for this? Does TestNG's reporting suit what we want to do and/or can we leverage any of the reporting that it does on the web? Alex.
Re: Re: [optimization] Algorithmic tricks
On 26/07/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: Some hashCode functions are actually very *hot* methods (e.g. String) In this case I think that a bad but fast hashCode() could be better than good but slow. May be I'm wrong but only tests can show the difference. So if you have tests, I'm +1 Speaking of which ... I recall seeing an interesting behaviour back in the Java 1.1 days when the hashCode() of a String used all the characters when the String was less than a certain threshold (about 100 chars?) and then for larger sizes, took a stride of about every tenth character. It was a real problem when I was doing a bunch of hash inserts on long similar names that often only changed at the end; so com.example.some.thing.here.ClassA and com.example.some.thing.here.ClassB ended up having the same hash because the stride was in effect and so didn't see the difference between the two :-) What effect would there be if we were communicating (via RMI) with an implementation of a remote VM that isn't harmony? I.e.,if we have a String "asdfasdfasdf" which hashes to (say) 8 on a Harmony VM, and a remote implementation uses a hash of 12 for the same value, would that cause any problems in an RMI layer? Do we care about such a scenario? Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [optimization] Algorithmic tricks
On 26/07/06, Denis Kishenko <[EMAIL PROTECTED]> wrote:
Frequently hash code is a sum of several other hashes. Such implementation
kill hash idea, it's terrible.
I agree that simple addition is not a good thing. However, exclusive
or can work just as well, as can a simple multiplication of numbers by
primes.
and many others... also I have found such "algorithms" =)>
private long* *token;
public int hashCode() {
return (int) token;
}
This isn't an incorrect hash function, and if there's only one token,
it doesn't really matter that much. Even if the token itself isn't
widely distributed, chances are the bottom few bits are going to be
distributed fairly evenly, and often it's the bottom part of a
hashcode that's considered rather than the top part. So, it's not
optimal, but shifting some bits around doesn't make that much
difference.
The most of hashCode() functions are implemented in different ways. It's not
problem, but it looks like scrappy, there is no single style. And finally we
have class *org.appache.harmony.misc.HashCode *for this aim!
Interesting, but I wonder what the impact is of using an additional
class to calculate the hash from each time is going to be. Hopefully a
decent JIT will remove much of the problem, but bear in mind that the
hashCode may get called repeatedly during a single operation with a
collection (and in the case that it's already in the collection, may
be called by every other operation on that collection too. You might
find that even a simple (say) sort of a list would easily overwhelm
the nursery generation of a generational GC.
Of course, it's difficult to say without measuring it and knowing for sure :-)
But only several classes are using it. I suggest integrate HashCode in
all hashCode() implementations (about 200 files), I can do this. Anybody
else can improve HashCode work.
Any comments?
There are other approaches that could be used instead of this. For
example, the value of the hashCode could be cached in a private
variable and then invalidated when any setValue() methods are called.
One could even imagine a superclass performing this caching work:
public abstract class HashCode {
private boolean valid = false;
private int hash;
public final int hashCode() {
if (!valid) {
hash = recalculateHashCode();
valid = true;
}
return hash;
}
protected abstract int recalculateHash();
protected void invalidate() { valid = false; }
}
Of course, you could use the HashCode object to calculate the hash value :-)
Such an approach won't work when the class hierarchy cannot be
changed, of course.
Lastly, an easier approach is to use a tool (such as Eclipse) to
generate the implementation of hashCode() automatically based on the
non-static, non-final variables of a class. This one sounds like (a)
the easiest, and (b) all-round better performant than any of the
above.
Alex.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [classlib] TwoKeyHashMap
On 25/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: In general before we get rid of that class or decide to keep it, I think we should work out an approach to performance optimizations. It's a rare case when perofmance might be significantly improved for free, a regular price is: additional complexity, more code, lack of readability, additional memory footprint etc. So let's discuss how we approach performance in general and that return to this specific class. Performance in general: premature optimisation is the root of all evil [Knuth] http://mindprod.com/jgloss/knuth.html In this case, we've not only dupllicated logic from a HashMap, but at the expense of a potential problem that we've not even measured. For example, there is an assumption that the cost of creating (and recycling) objects in a wrapper for an equivalent use of a Map is something that's not even been measured, yet we have code that assumes that that is a bottleneck. Is this code even on the critical path? That is, have we profiled this code to know whether any access is actually directly responsible for performance problems? If not, then it sounds like assumptions have been made prior to writing this. So, we should strive to make code: 1) Correct 2) Easy to understand and maintain 3) Performant 4) Optimised (for memory, speed) in that order. In this case, I'm not sure whether we've violated 2 in preference for 4. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] App-driven Improvement
On 24/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Now that we have a distribution of the VM + classlib in the JRE, we can start encouraging people to try real applications and tell us what's wrong. I'm guessing this will be an avalanche of useful information :) Good idea! Let's just hope it's not too successful :-) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] TwoKeyHashMap
I don't think that it makes sense to maintain a completely separate data structure just because there's a pair of keys. An object that holds two values will do the job just as well, and there should be no problem with an object being created, used for a lookup, and then recycled in the nursery generation. On the other hand, having a separate algorithm is more likely to result in duplicated information and maintenance. This sounds like premature optimisation to me. After all, how many lookups are being performed in the crypto framework? If it's just a pairing of (say) provider/hash algorithm, how frequently is it being used? Do we have any stats that show the bottleneck is on the access of a value from the hashmap? Alex. On 23/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: It's created for performance optimization. Without it a new object has to be created every time a record is seeked in a hashmap. it's used in crypto framework and JSSE provider. Thanks, Mikhail 2006/7/22, Geir Magnusson Jr <[EMAIL PROTECTED]>: > If it's not being used anywhere, and if no one claims it, +1 > > (and if it's being used and can be replaced +1) > > Nathan Beyer wrote: > > I'm all for removing it. The last time I looked through that code I came to > > the same conclusion your questions infer. If I recall correctly, some of the > > actual Map interface methods won't even work correctly if used. Also, I > > believe the actual keys were just Strings, so concatenated Strings could > > even be used. > > > > -Nathan > > > >> -Original Message- > >> From: Tim Ellison [mailto:[EMAIL PROTECTED] > >> Sent: Friday, July 21, 2006 11:52 AM > >> To: harmony-dev > >> Subject: [classlib] TwoKeyHashMap > >> > >> Does anyone know why we have a TwoKeyHashMap [1] utility class? > >> > >> I've only looked at it briefly, but I'm left wondering why the author > >> chose to write all that rather than use a regular HashMap with an object > >> that combines the 'TwoKey's? > >> > >> There may be a subtlety I missed. Anyone know? > >> > >> [1] > >> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod > >> ules/luni/src/main/java/org/apache/harmony/luni/util/TwoKeyHashMap.java?vi > >> ew=co > >> > >> Regards, > >> Tim > >> > >> -- > >> > >> Tim Ellison ([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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [build-test-infra] Build Test Infrastructure
FWIW Mac OS X doesn't have tools.jar in $JAVA_HOME/lib. Instead, the tools are in the classes.jar file (no, it's not called rt.jar either) in $JAVA_HOME/../Classes/classes.jar. It's a bit unfortunate that it has both the run-time libraries and the tools in one place, but essentially it means that the sun tools are on the classpath whatever happens. Not that it's spectacularly relevant, but I thought I'd mention it here in case there's going to be a Mac port in the future ... Alex. On 11/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Richard Liang wrote: > > It seems that JAVA_HOME is required by cc/cruisecontrol.sh on my Ubuntu > :-) Do I miss something? Thanks a lot. That seems to be the case :) If you set it, does it work? It seems to want it for two things, tools.jar (for it's JSPs?) and where to find java executable. The latter we just deal with (expect it to be on the executable path), but tools is more 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] Testing conventions - a proposal
On 10/07/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Hi George, > For the purposes of this discussion it would be fascinating to find out > why you refer to TestNG as being an "unstable" test harness. What is > that statement based on ? My exact statement was referring to TestNG as "probably unstable" rather than simply "unstable". ;) This statement was based on posts from Richard Liang about the bug in the TestNG migration tool and on common sense. If the project has such an obvious bug in one place it may probably have other bugs in other places. JUnit is quite famous and widely used toolkit that proved to be stable enough. TestNG is neither famous nor widely used. Unfortunately, this isn't terribly correct :-) The purpose of the JUnit migration tool is to automatically add annotations to an existing source, and is independent from the test harness itself. TestNG is also quite famous, and indeed, a lot of what's available in JUnit4 was based on ideas from TestNG. It's also been around since August 2004, so it's had almost a couple of years out in the field (and as the download page [1] shows, it's pretty active). There's also plugins for any build system you care to name (ant, maven, Eclipse, IntelliJ) and it's pretty widely adopted in certain areas. In short, not a terribly common-sense post :-) Alex. [1] http://testng.org/doc/download.html - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] Testing conventions - a proposal
On 08/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: So while I like the annotations, and expect we can use them effectively, I have an instinctive skepticism of annotations right now because in general (in general in Java), I'm not convinced we've used them enough to grok good design patterns. There's really no reason to get hung up on the annotations. TestNG works just as well with JavaDoc source comments; annotations are only another means to that end. (They're probably a better one for the future, but it's just an implementation detail.) Now since I still haven't read the thread fully, I'm jumping to conclusions, taking it to the extreme, etc etc, but my thinking in writing the above is that if we bury everything about our test 'parameter space' in annotations, some of the visible organization we have now w/ on-disk layout becomes invisible, and the readable "summaries" of aspects of testing that we'd have in an XML metadata document (or whatever) also are hard because you need to scan the sources to find all instances of annotation "X". I'm hoping that this would be just as applicable to using JavaDoc variants, and that the problem's not with annotations per se. In either case, both are grokkable with tools -- either annotation-savy readers or a JavaDoc tag processor, and it wouldn't be hard to configure one of those to periodically scan the codebase to generate reports. Furthermore, as long as the annotation X is well defined, *you* don't have to scan it -- you leave it up to TestNG to figure it out. Actually, there's a very valid benefit for using TestNG markers (= annotations/JavaDoc) for grouping tests; the directory structure is a tree, whereas the markers can form any slice of tests, and the sets don't need to be strict subsets (with a tree, everything has to be a strict subset of its parents). That means that it's possible to define a marker IO to run all the IO tests, or a marker Win32 to run all the Win32 tests, and both of those will contain IO-specific Win32 tests. You can't do that in a tree structure without duplicating content somewhere along the line (e.g. /win/io or /io/win). Neither of these scale well, and every time you add a new dimension, you're doubling the structure of the directory, but merely adding a new marker with TestNG. So if you wanted to have (say) boot classpath tests vs api tests, then you'd ahve to have /api/win/io and /boot/win/io (or various permutations as applicable). Most of the directory-based arguments seem to be along the lines of "/api/win/io is better! No, /win/io/api is better!". Just have an 'api', 'win', 'io' TestNG marker, and then let TestNG figure out which ones to run. You can then even get specific, and only run the Windows IO API tests, if you really want -- but if you don't, you get the benefit of being able to run all IO tests (both API and boot). There doesn't seem to be any benefit to having a strict tree-like structure to the tests when it's possible to have a multi-dimensional matrix of all possible combinations that's managed by the tool. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Re: [classlib] compatibility of toString
On 07/07/06, Magnusson, Geir <[EMAIL PROTECTED]> wrote: > If people are relying on one implementation that's undocumented > behaviour, then it's bad code. It may well fail on any other system > (inc. embedded systems, or other OS, or even between different > versions). No kidding. Welcome to the real world :) People do all sorts of stupid things. Yup, I've done a few myself ... 1) We are asking Sun about this, so it's clear we're bringing it up as an issue to them. Yes, and if Sun give the OK then there's no issue. 2) We try to get it from the RI via black-box, and if we can't, we can't and use our best judgement. Providing Sun don't have problems, I'd say that's fine. If they do, then it might be less desirable. > I say that we follow the spec, and if the spec doesn't list an > explicit format, we use our own. If it is amazingly obvious (e.g. a > Point may be printed (1,2)) and it happens to correspond with the Sun > RI, then great, but we shouldn't be striving to be the same in all > cases. So if we are satisfied that it doesn't put us at risk from defense-of-cleanroom perspective, do you still have a problem if we at least try? If we're satisfied that there's no problems, then like I said, there's no problems if it's the same as the RI. Maybe we should pick this thread up again when Sun get back to you regarding the toString() and exception messages, and in the meantime, only follow what's in the JavaDoc/spec? Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] compatibility of toString
On 06/07/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Here here; if only the API was printOn(OutputStream) then we'd all be happy(er). I suspect that it's hear, hear, at least there (in Parliament). :-) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] compatibility of toString
On 06/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > IMNSHO I don't think we should by default copy the toString() > behaviour from the RI, unless mandated by the spec in JavaDoc. Ok. Good rant, and I agree with it, but I still don't see a reason here why we shouldn't, other than to teach people a lesson? If people are relying on one implementation that's undocumented behaviour, then it's bad code. It may well fail on any other system (inc. embedded systems, or other OS, or even between different versions). But the real reason is one of defense; how can you say that you've implemented a clean-room version of the code from the spec, when all the toString() results are identical with a proprietary implementation that you have no way of knowing what the result should be, except by running the propetary version to find out? Obviously, some cases it will be obvious (e.g. we can guess what a java.net.URL looks like) but in most cases it won't be (e.g. java.net.URLConnection). I say that we follow the spec, and if the spec doesn't list an explicit format, we use our own. If it is amazingly obvious (e.g. a Point may be printed (1,2)) and it happens to correspond with the Sun RI, then great, but we shouldn't be striving to be the same in all cases. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] compatibility of toString
IMNSHO I don't think we should by default copy the toString()
behaviour from the RI, unless mandated by the spec in JavaDoc.
Frankly, the toString() has always been undefined, and I'm sick off
Java developers saying "Well, yes, but I always expect it to be
[name='value',name='other value']" and then writing toString() methods
that do exactly the same.
toString() was never meant to be a dump of the object's fields and
values. It was meant to be a string representation of the object. And
it's an insanely ineffecient measure to dump out all of an object's
fields using toString() anyway, because of all the wasted
concatenation that goes on when you have nested objects.
It would be much better if Java developers on the whole got over the
fascination with toString() and its format, and used better mechanisms
for writing out debug state (e.g. dump(Writer) *) if they needed -- or
better yet, just used a debugger.
Alex.
* Why everyone wants to stream toString() values is beyond me. If you
just write the output to a stream in the first place, you get the
concatenation for free without having to do all that expensive memory
manipuation.
On 06/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Yep. No answer yet. I pinged them for an update, and also asked the
toString() question.
geir
Mikhail Loenko wrote:
> IIRC Geir was going to ask Sun if we are allowed to copy their
> exception messages
>
> Thanks,
> Mikhail
>
> 2006/7/5, Richard Liang <[EMAIL PROTECTED]>:
>>
>>
>> Geir Magnusson Jr wrote:
>> > Richard Liang wrote:
>> >
>> >> Geir Magnusson Jr wrote:
>> >>
>> >>> Tim Ellison wrote:
>> >>>
>> >>>
>> >
>> >
>> Yep, if the spec tells you what the format of the string should
>> be then
>> follow it (since apps may be dependent upon it), otherwise I'd be
>> inclined to invent your own useful string representation.
>>
>>
>>
>> >>> This idea scares me. I think people do depend on toString() when
>> >>> writing apps, and tend to shove that kind of thing to log files
>> and such
>> >>> on server apps. To have our outptut different from Sun's, BEA's,
>> IBM's,
>> >>> Apple's seens like we're asking for trouble.
>> >>>
>> >>>
>> >>>
>> >> Hello Geir,
>> >>
>> >> IMHO, as long as the method does not give confusing message to
>> >> developers, we are not required to have the same behavior. You may
>> want
>> >> to refer to the spec of java.lang.Object.toString:
>> >> ...
>> >> In general, the toString method returns a string that "textually
>> >> represents" this object. The result should be a concise but
>> informative
>> >> representation that is easy for **a person to read**.
>> >> ...
>> >>
>> >
>> > Sure, but that doesn't mean that it would be reasonable to randomly
>> > change the output of a given Class's toString() as long as it would be
>> > easy for a person to read :)
>> >
>> > I know that's not what you are advocating, and I certainly agree
>> that no
>> > one should depend on toString() output like that, but I also know that
>> > in production systems *I* have done it, and I'm sure others have as
>> well.
>> >
>> >
>> >> And there are some cases that we even cannot follow RI.
>> >> e.g.,
>> >> URLConnection conn = new
>> URL("http://www.apache.org";).openConnection();
>> >> System.out.println(conn.toString());
>> >>
>> >> The code above will print
>> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org";
>> >>
>> >> Any comments? Thanks a lot.
>> >>
>> >
>> > Well, we could actually print that if that was our impl of
>> URLConnection
>> > for HTTP, but still, I think
>> >
>> > "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org";
>> >
>> > would be more reasonable than
>> >
>> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection,
>> > Target URI : http://www.apache.org";
>> >
>> > or something like that, even thought the second is perfectly good.
>> >
>> > All I'm saying is that unless the output from the RI's toString() is
>> > particularly brain-dead, it doesn't seem to be too much of a bother to
>> > be similar.
>> >
>> >
>> Agree. And in fact, it's easier to have the same output as RI's if we
>> are allowed. :-) Could we think this rule also apply to the message when
>> an exception is thrown?
>>
>> Any comments? Thanks a lot.
>>
>> Best regards,
>> Richard
>>
>> > Just my $0.02
>> >
>> > geir
>> >
>> >
>> >> Best regards,
>> >> Richard
>> >>
>> >>> geir
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> 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: Re: [classlib] Testing conventions - a proposal
On 06/07/06, Richard Liang <[EMAIL PROTECTED]> wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html "Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src" :-) There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] Testing conventions - a proposal
On 06/07/06, Richard Liang <[EMAIL PROTECTED]> wrote: George Harley wrote: > A couple of weeks ago I mentioned that the TestNG framework [2] seemed > like a reasonably good way of allowing us to both group together > different kinds of tests and permit the exclusion of individual > tests/groups of tests [3]. I would like to strongly propose that we > consider using TestNG as a means of providing the different test > configurations required by Harmony. Will try to study TestNG before I can give comment ;-) I'd strongly recommend TestNG for this purpose, too. It's possible to have a limiteless set of annotations for TestNG as well as allowing different (sub)sets of those tests to be run. You can also set up dependencies between stages (e.g. to test sockets, you've got to test the IO ones first) as well as allowing re-running of just failed tests from the command line (a test run can output markers as to which tests passed/failed, and then on subsequent runs just re-run the failing tests). It would also solve a lot of the problems that we've been seeing for OS-specific issues; you can mark a test only to be run on Windows, or on Linux etc. the best thing is that all of these annotations can be combined in whatever ways that you want -- as opposed to a directory-based approach, which is hierarchical and thus not easy to split based on OS or enviornment alone without an exponetial explosion in the possible combinations. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] compatibility of toString
On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: Agree. But there are always exceptions. Some "toString" methods have to contain some key information as spec required, for example, the size or index. Can you give examples of where the spec specifically mandates the return values of either size or index? BTW, are these toString information (RI) copyrighted? I don't believe they can be copyrighted. However, the only way to tell if the RI and Harmony return the same results would be to execute both and compare them, and I believe that such reverse engineering would be outside the remit of Harmony. I doubt that the TCK would test for such features exactly, without specifying them. For example, the AbstractCollection and AbstractMap does specify what it should return: http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractCollection.html#toString() http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractMap.html#toString() I think you'd find it difficult to explain why (in all cases) toString() returned exactly the same value as the RI without such detailed comments as to their format :-) Alex. - 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] compatibility of toString
I'd say that (like hashCode()) there's not a lot of point in testing the exact output, only behaviour. In other words, if it returns a String, that should be good enough. There's nothing in the spec to say what it should be -- all of the toString() methods could return "Harmony is Great!" and it'd still be within spec. I suspect that tests that look at the exact output for toString() are being done because it may be a quick-and-dirty way of testing all properties set in a JavaBean-esque way. OTOH there are some things that probably are worth testing -- IIRC the XxxList implementations return [...] when the list grows beyond a certain size (1000?) to avoid doing an insane amount of toString calculation. That's the kind of property that I would expect to be tested in that particular test case. Alex. On 30/06/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: Hi community! While looking through some of java.beans tests I found many places where exact output of toString() method is being tested. Moreover, the test patterns differ from the output generated by RI's toString's. IMHO there is no much sense in testing of toString() since normally users do not rely on it's output. However, I'd like to listen to opinions. Does compatibility testing of toString() make sense to anybody? -- Alexei Zakharov, Intel Middleware Product 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: [doc] Re: ANN: Apache Harmony featured on javaref.com where AJAX meets javadocs
Shame it doesn't JavaDoc the internals ... I put a bunch of comments in the pack200 code that isn't part of the externally visible spec :-) Alex. On 28/06/06, Tim Ellison <[EMAIL PROTECTED]> wrote: (breaking out into a new thread) Here's the link for those that want to try it: http://www.javaref.com/app?service=external/LibraryDisplayPage&sp=2 Regards, Tim Javaref Scribe wrote: > Hello everyone, >Javaref.com is where ajax meets javadocs. The site provides multi-API > javadocs which are cross-referenced with a UI that is ajax driven > (enabling featuers such as class/package/method search with > auto-complete)! And since the Sun JDK is copyrighted, Apache Harmony > takes center stage as the JDK library. I've loaded the class library > from the SVN repository as of Jun 27, 10 pm. I'll continue to update the > javadocs for it every 2 weeks or so. In the mean time, I hope this will > bring Harmony a lot more attention and visibility and also encourage us > users to contribute to the documentation! > > Thanks! > Javaref ... -- Tim Ellison ([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: RI's bug of Socket.getOutputStream().write(byte[]) ?
Sometimes the close() can cause problems for the remote server, since
it yanks the connection out. There's no particular guarantee that the
server will have time to process the entire request and send you the
results.
Also, on some systems, closing the output stream can close the socket
too, so you may never be able to read from it if you do this. I would
strongly suggest moving the close to the end.
Alex.
On 23/06/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Tim,
Thank you very much. I revised the test case a little according to your
suggestion, but RI still fails sometimes.
Would you please review the test? The error message is: expected <400> but
was: <200>
Thanks a lot in advance!
public void test_SocketChannel_BlockWriteRead() throws IOException {
final int CAPACITY_NORMAL = 200;
InetSocketAddress localAddr1 = new InetSocketAddress("127.0.0.1
",1234);
ServerSocket server = new ServerSocket(1234);
SocketChannel channel = SocketChannel.open();
channel.connect(localAddr1);
Socket serverSocket = server.accept();
OutputStream out = serverSocket.getOutputStream();
byte[] sendBuf = new byte[CAPACITY_NORMAL * 2];
for (int i = 0; i < CAPACITY_NORMAL * 2; i++) {
sendBuf[i] = (byte) i;
}
// send CAPACITY_NORMAL * 2 bytes data
out.write(sendBuf);
out.flush();
out.close();
ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
ByteBuffer[] buf ={buf1, buf2};
// should receive CAPACITY_NORMAL * 2 bytes data
long count = 0;
do{
long ret = channel.read(buf);
if(ret == -1){
break;
}
count += ret;
}while(count < CAPACITY_NORMAL*2);
assertEquals(CAPACITY_NORMAL * 2, count);
}
Best regards,
On 6/23/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Andrew,
>
> There is no guarantee that the out.flush() will actually send the bytes
> (it will just ensure that they get from Java to the OS). Indeed, there
> is no guaranteed way to force the TCP stack to send the bytes; but you
> can try by reducing the socket send buffer size (SO_SNDBUF) and setting
> no delay on (TCP_NODELAY). The best bet is to close the output stream
> socket when you have finished writing, and read until you get a -1 on
> the client.
>
> Regards,
> Tim
>
> Andrew Zhang wrote:
> > Hi everybody,
> >
> > It seems RI Socket.getOutputStream().write(byte[]) doesn't send all
> data
> > sometimes. Consider following test, which often blocks on RI:
> >
> >public void test_SocketChannel_BlockWriteRead() throws IOException {
> >final int CAPACITY_NORMAL = 200;
> >InetSocketAddress localAddr1 = new InetSocketAddress("127.0.0.1
> > ",1234);
> >ServerSocket server = new ServerSocket(1234);
> >
> >SocketChannel channel = SocketChannel.open();
> >channel.connect(localAddr1);
> >Socket serverSocket = server.accept();
> >
> >OutputStream out = serverSocket.getOutputStream();
> >byte[] sendBuf = new byte[CAPACITY_NORMAL * 2];
> >for (int i = 0; i < CAPACITY_NORMAL * 2; i++) {
> >sendBuf[i] = (byte) i;
> >}
> >// send CAPACITY_NORMAL * 2 bytes data
> >out.write(sendBuf);
> >out.flush();
> >
> >ByteBuffer buf1 = ByteBuffer.allocate(CAPACITY_NORMAL);
> >ByteBuffer buf2 = ByteBuffer.allocate(CAPACITY_NORMAL);
> >ByteBuffer[] buf ={buf1, buf2};
> >
> >// should receive CAPACITY_NORMAL * 2 bytes data
> >// RI often hangs here, with CAPACITY_NORMAL bytes data received.
> >long count = 0;
> >do{
> >count += channel.read(buf);
> >}while(count < CAPACITY_NORMAL*2);
> >assertEquals(CAPACITY_NORMAL * 2, count);
> >}
> >
> > I think it's a bug of RI. Am I missing something? Please correct me if
> I'm
> > wrong. There're also some similar tests in NIO module with FIXME mark.
> >
> > If it's a bug of RI, I'll raise a JIRA to tidy up those "FIXME" in NIO.
> >
> > Thanks!
> >
> > Best regards,
> >
>
> --
>
> Tim Ellison ([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]
>
>
--
Andrew Zhang
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-634) Pack200 file with just resources
Here's what it looks like in GMail. Normally, the reply-to looks OK, but in the [jira] case, it's not filled in. And here's the GMail mail header: X-Gmail-Received: 6912720e939c46a2efe12022cbcd40744ee744be Delivered-To: [EMAIL PROTECTED] Received: by 10.70.103.19 with SMTP id a19cs319376wxc; Wed, 21 Jun 2006 04:31:36 -0700 (PDT) Received: by 10.64.179.19 with SMTP id b19mr784713qbf; Wed, 21 Jun 2006 04:31:36 -0700 (PDT) Return-Path: <[EMAIL PROTECTED]> Received: from brutus.apache.org (brutus.apache.org [209.237.227.198]) by mx.gmail.com with ESMTP id e15si351702qbe.2006.06.21.04.31.35; Wed, 21 Jun 2006 04:31:36 -0700 (PDT) Received-SPF: pass (gmail.com: best guess record for domain of [EMAIL PROTECTED] designates 209.237.227.198 as permitted sender) Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A846E410007 for <[EMAIL PROTECTED]>; Wed, 21 Jun 2006 11:30:30 + (GMT) Message-ID: <[EMAIL PROTECTED]> Date: Wed, 21 Jun 2006 11:30:30 + (GMT+00:00) From: "Tim Ellison (JIRA)" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [jira] Commented: (HARMONY-634) Pack200 file with just resources In-Reply-To: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080 ] There doesn't look like there's a Reply-To set there. What does the mail header look like to you? Is it GMail that's stripping it out? Alex. PS I'm glad I got a chance to use OmniDazzle. Funky, huh? On 21/06/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Odd - my "reply" using thunderbird on a JIRA email does the right thing... geir Alex Blewitt wrote: > Not from the JIRA e-mails I get ... the reply to results in > "[EMAIL PROTECTED]". I'm using GoogleMail from a Mac on Safari. > > Alex. > > On 21/06/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> Alex Blewitt wrote: >> > (Apologies for the large to: list; I'm still unsure how to reply to >> > automatically generated e-mails) >> >> Hit "reply" on you mailer? >> >> The "reply-to" is set to the list. >> >> > >> > It wouldn't hurt having the resources test as well as the hello world >> > test. At some point, I should probably expand the test to check for >> > the right filename etc. But we don't have to comment out the >> > helloworld test if it's still working. >> > >> > Alex. >> > >> > On 21/06/06, Tim Ellison (JIRA) <[EMAIL PROTECTED]> wrote: >> >> [ >> >> >> http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080 >> >> >> ] >> >> >> >> Tim Ellison commented on HARMONY-634: >> >> - >> >> >> >> So given that the SegmentTest is still working ok with the >> >> HelloWorld.pack, do you still want to apply this and switch to the >> >> resources file? >> >> >> >> >> >> > Pack200 file with just resources >> >> > >> >> > >> >> > Key: HARMONY-634 >> >> > URL: http://issues.apache.org/jira/browse/HARMONY-634 >> >> > Project: Harmony >> >> > Type: Bug >> >> >> >> > Components: Classlib >> >> > Reporter: Alex Blewitt >> >> > Assignee: Tim Ellison >> >> > Priority: Trivial >> >> > Attachments: JustResources.pack, JustResources.patch >> >> > >> >> > This file is a pack200 Jar file that just contains resources, which >> >> can be used to substitute the HelloWorld.pack that's used in the >> >> SegmentTest test case. I've commented out the one that will fail and >> >> the JustResources.pack can be put in the same place as the >> >> HelloWorld.pack one >> >> > Index: >> >> >> /Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java >> >> >> >> >> > === >> >> > --- >> >> >> /Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java >> >> >> (revision 415823) >> &g
