[classlib]hythreads implementation
Hi, I've noticed such a strange thing when examined drlvm building process. The drlvm replaces hythreads shared library with its own simple implementation based on APR. The drlvm hythreads library exports less than 1/2 functions comparing with the original hythr.dll. I thought the rest of functions are used by J9 VM, but replacing hythread classlib implementation with the slightly modified drlvm one doesn't lead to problems (all tests passed with j9 vm too). So, the question : Why we have so much code in the hythreads module if nobody neads it? Marina
Re: [classlib][testing]resource files: location and usage
Yes, it'll be useful. But currently few resource files follow conventions only 4 files ... I created HARMONY-641 with small script to check serialization data file names. Results can be placed on wiki or web if needed – is it needed? Thanks, Vladimir On 6/20/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/20/06, Vladimir Ivanov wrote: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? Resource files for testing serialization is the first case. To work out further conventions we should at least understand what kinds of resource files are required for testing. For example, we may agree that resource files for net-based tests should be put separately in 'net' sub-folder. And I'd suggest to put all other resources into 'other' folder (i.esrc/test/resources/other). b) At least, specify that resource file name should contain test name – for easy resource file search? Agree. c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. No. IIRC we agreed to move 'things' used across different modules to trunk/support/. 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? Sure. I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions :-) Thanks, Stepan. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource (serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- 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][testing]resource files: location and usage
It does not work well. Single resource might be used by many tests OK. But in the other case, when one resource is used by one tests (I believe most typical situation), lets name the resource file using test name. Thanks, Vladimir On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Vladimir Ivanov [EMAIL PROTECTED]: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? b) At least, specify that resource file name should contain test name – for easy resource file search? It does not work well. Single resource might be used by many tests c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. +1 It smells like we already discussed that and agreed to distribute trunk/support between modules. not sure. Thanks, Mikhail 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource(serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- 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]
Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if the
socket is not bound yet. That's how spec describes getLocalPort method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
Andrew Zhang
China Software Development Lab, IBM
Re: [drlvm] what's next?
Weldon Washburn wrote: On 6/21/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: If no one else is doing it, I will start the porting of SableVM's gen GC into DRLVM. Good idea. Go for it. I talked to Carl Lebsack today. He mentioned that SableVM asked permission to relicense his generational GC under Apache license. It seems possible that all of SableVM will be relicensed under Apache license. :) Carl mentioned that the SableVM/GC interface is not But it *is* relicensed since last March see: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] well defined but sees value in what we are proposing here. Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nektarios K. Papadopoulos inAccess Networks - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Geir Magnusson Jr wrote: Oliver Deakin wrote: Geir Magnusson Jr wrote: However, in our case, when I say exec never returns I mean exec() never returns. so you'd never actually get to do IO above, because you are hanging in exec(). Big difference, right? Certainly So I assume you agree? (Just want to make sure that I'm not missing something terribly important here...) Yes, that is a different case to what I was imagining (and what was on that page I linked). Seems that *I* was missing something important ;) - do you have a stack trace that gives more info for what each of the threads are doing? Could you attach it to the JIRA if you do please - Ive just tried running a cut down version of the test on my SLES9 machine and it exited fine, so it would be useful to have a trace from your machine to see what's happening. Done Thanks Regards, Oliver geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - 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 problems
Mark Hindess wrote:
On 22 June 2006 at 10:25, Vladimir Ivanov [EMAIL PROTECTED] wrote:
1) the dependency on ecj_3.2RC5 is not checked:
[copy] Copying
C:\harmony\trunk_0427\depends\jars\bcprov-jdk14-133\bcprov.jar to
C:\harmony\trunk_0427\deploy\jdk\jre\lib\ext\bcprov.jar
BUILD FAILED
C:\harmony\trunk_0427\build.xml:83: The following error occurred while
executing this line:
C:\harmony\trunk_0427\make\build-java.xml:161:
C:\harmony\trunk_0427\depends\jars\ecj_3.2RC5 not found.
Total time: 2 minutes 31 seconds
...
Fixed in r416240. Thanks for the report.
Apologies, that was my oversight. There was code to check it, but I had
left it commented out.
2) the build failed on java-compilation on the WinXP with 1Gb RAM (650Mb
free) as:
...
compile:
[mkdir] Created dir: C:\users\TCKTeam\ws\trunk\build
[javac] Compiling 2895 source files to C:\users\TCKTeam\ws\trunk\build
[javac] The system is out of resources.
[javac] Consult the following stack trace for details.
[javac] java.lang.OutOfMemoryError: Java heap space
BUILD FAILED
C:\users\TCKTeam\ws\trunk\build.xml:83: The following error occurred while
executing this line:
C:\users\TCKTeam\ws\trunk\make\build-java.xml:84: Compile failed; see the
compiler error output for details.
Total time: 1 minute 8 seconds
To fix it the build-java.xml was updated (locally) as:
javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
destdir=${build.output} source=${hy.javac.source} target=${
hy.javac.target} debug=on
Good idea. Fixed in r416245.
Not a good idea :-( I'm compiling successfully with the non-forked VM
and -Xmx256m (that works with Sun 5.0 JDK), now I have to fork another
process that will immediately grab 512Mb RAM ?! That's excessive.
As a compromise can we remove the inital size param and reduce the max
memory?
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]
Re: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Thorbjørn Ravn Andersen wrote: Tim Ellison skrev den 21-06-2006 11:58: The build instructions are here [1], let me know if they need updating. Just got around to update and check. The reference to the build.xml file in the help text shown if the dependencies have not been downloaded does not reflect that it now is ant -f make/depends.xml download instead. Not sure that I understand... I just removed a dependency and did a default build, it complains like this: Missing dependency. The jar from: http://www.ibiblio.org/maven/xalan/jars/xalan-2.7.0.jar should be downloaded to: depends/jars/xalan-j_2.7.0/xalan.jar Run ant fetch-depends to automatically fetch dependencies. Note: Some of Harmony's dependencies are licensed under terms other than the Apache License v2. Total time: 0 seconds Then 'ant fetch-depends' went to get it for me. (This was changed within the last three days or so.) For example, I think they may need to catch up with the build.xml file movement that took place yesterday. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html While it is building I would like to mention that the primary reason why I did what I did was to see if it was necessary at all to download Sun's JDK (to get tools.jar) to build on Ubuntu. It isn't - by downloading ecj and telling ant to use it - you can get by just with a JRE or a clone like gcj (or perhaps kaffe), which is available in the default repositories. Personally I like this approach the best :) Yep, we have had enough code to host our own build scripts for a while now :-) Given that ECJ is now a dependency for our emerging javac tool, perhaps we should make it the default in the build system too? 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]
Re: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Geir Magnusson Jr wrote: Thorbjørn Ravn Andersen wrote: Tim Ellison skrev den 21-06-2006 11:58: The build instructions are here [1], let me know if they need updating. Just got around to update and check. The reference to the build.xml file in the help text shown if the dependencies have not been downloaded does not reflect that it now is ant -f make/depends.xml download instead. That's only because I took out the make/ in the error message, which was there forever (and didn't make sense), except since the change yeterday, it now makes sense to have it there :) People should use the 'fetch-depends' target in the top-level build.xml. The stuff in make/ is the inner-workings of the build scripts. 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]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Oliver Deakin wrote: Paulex Yang wrote: Seems no one objects this proposal:), so I'm going to implement the JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578, Because this implementation requires some native codes, so I probably need to reintroduce hynio.dll(.so), but I have some questions.(Excuse me about my ignorance on the native layout evolution). At first, seems native codes will be separated into modules(I guess Oli is working on?), so should I assume my native codes will be directly put into nio modules, or still in native-src/win.IA32/nio directory? because I'm used to provide a shell to move/svn add new files in the patch, so it will be easier for me to know how others think about it. It depends on whether you want to wait for what I'm doing or not :) If you want to get the code out now, then you can temporarily put it under native-src/win.IA32/nio and I will move it later as part of the natives modularisation. However, if you don't mind waiting a day or so I should be able to submit my first patch to move the prefs natives. This ought to be enough of an example for you to put your native code directly into modules/nio/src/main/native. And second, the native codes probably need portlib, so the portlib's header file must be accessible, say, portsock.h, but now it has been moved into luni/src/main/native/blabla, should I include one in my patch so that nio module can have a copy? or the header file itself should be put some other well known directory(deploy/build/include I guess)? At build time, the copy.native.includes target in luni/make/build.xml is called - it copies a selection of the header files in luni/src/main/native/include that need to be shared between modules into the deploy/include directory. This is done with an explicit fileset in luni/make/build.xml - if you need to have portsock.h added to the list of shared header files, then this is the place to make that change. Just add its filename to the list, and next time you build it will appear in the deploy/include directory. Your nio code should include the headers from the deploy/include dir, and *not* directly from the luni/src/main/native/include dir. Oli, I tried to modify the luni/make/build.xml, and it successfully copied the portsock.h, but I found I still cannot build my native codes. So I looked inside the portsock.h, and found that all its content is just to include another file: ../port/hysock.h, my native codes in modules/nio/src/main/native cannot find ../port/hysock.h so it fails. I guess the reason why the luni natives still can build is all LUNI's native codes are still located in native-src/luni, so they can found the hysock.h in native-src/port. Seems portsock.h is useless and confusable, so I suggest the steps below to fix this problem: 1. svn delete portsock.h in luni 2. svn move hysock.h from native-src to luni 3. update all reference to portsock.h to hysock.h 4. rebuild If no one objects, I'll raise a separated JIRA and provide patch I hope this makes more sense now - if it doesn't, please let me know. I am in the process of writing up some documentation for the website on the natives layout and where headers should go (and also how modules should build against the HDK) - once that is complete it should all be a lot clearer. Regards, Oliver -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Help wanted!
Nathan Beyer wrote:
I've been hacking away at those warnings every chance I get. The 'luni'
module is going to be filled warnings until we can begin using annotations,
specifically the @SuppressWarning, especially the Collections classes. There
are a number of cases where unchecked type uses are a requirement because of
limitations in current APIs, backwards compatability and generic array
construction.
Here are some of the major pieces that can't be avoided and need suppressing
annotations:
* Cloning - When you clone a generified object you have no choice but to do
an unchecked cast.
* Generic Array Construction - The only thing you can do is T[] = (T[])new
Object[size]; and suppress the warning.
I agree, do we need a list on these unavoidable cases?
here goes some other samples come form PriorityQueue
1. Deserialization to generic array or collections: elements[i] =
(E)in.readObject()
2. ComparatorT.compare(), for the given Object, you must cast it to T
3. Accept a Comparator from another collection, the collection's
generic type is probably ? extends E, but the Comparator's is
generally ? super E, so codes like this cannot be avoidable:
void getFromSortedSet(SortedSet? extends E c) {
comparator = (Comparator? super E) c.comparator();
...
}
In any case, I'm all for keep this stuff as clean as possible. I have my
Eclipse compiler settings cranked to the max in the IDE.
-Nathan
-Original Message-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 12:49 AM
To: Apache Harmony Dev List
Subject: [classlib] Help wanted!
I was looking at building (and testing) with Eclipse + IBM VME. I think
this is really important since ecj has a much cleaner classpath when it
compiles so it helps us find errors quicker.
The logs come out at over 3MB! There are lots of warnings about less
than ideal type checking - mostly as a result of our adoption of more
generics. For example:
[javac] 1. WARNING in
/pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac] (at line 44)
[javac] relations.add(relation);
[javac] ^^^
[javac] Type safety: The method add(Object) belongs to the raw type
Vector.
References to generic type VectorE should be parameterized
[javac] --
[javac] 2. WARNING in
/pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac] (at line 88)
[javac] (AccessibleRelation[])relations.toArray(new
AccessibleRelation[r
elations.size()]);
[javac]
^^
^
[javac] Type safety: The method toArray(Object[]) belongs to the raw
type Ve
ctor. References to generic type VectorE should be parameterized
I think we should try to improve these, but there are rather too many
for me to do on my own! What do others think? I think we could disable
the warnings from Eclipse but I don't think that's really the right
thing to do.
The distribution of warnings is as follows:
4 accessibility
24 archive
90 auth
707 awt
61 beans
7 crypto
128 jndi
206 luni
10 luni-kernel
4 misc
8 nio
7 nio_char
32 prefs
17 regex
260 rmi
568 security
936 swing
26 text
14 x-net
Regards,
Mark.
-
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]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
On the 0x18F day of Apache Harmony Rana Dasgupta wrote:
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Geir,
[...]
4. We should also look at enhancements to the JITs ...and other than support
for new platforms ( 64 bit , down level platforms that support x87 but not
SSE* instructions..based on the minimum machine model we want to support eg
a pentium III running Windows/Linux )some of this work would benefit from
performance guidance...helpers should be inlined, some of the
optimizations eg., devirtualization perfected, polling to support
collection should consume less overhead, more optimized JNI invocation at
some point.
Addressing JIT changes, I would suggest some short-term
iprovements/projects that are interesting to do to quickly catch up
with DRLVM optimizing JIT(s):
* Devirtualization improvements
Currently DRLVM does *not* devirtualize interface calls.
A not-so-quick hack for the start: make a class-test based on the
class that
a) implements the interface
b) has the the method invoked with some instance (first invocations are
easy to register in JIT since they initiate compilation phase)
In future, a more sophisticated heuristic would be interesting to
experiment with. Ideas?
* Back-Branch-Polling (BBP) improvements
BBP is an optimization pass that inserts extra helper-function-calls
(safepoints) in loops to make them interruptable
(suspendable). Necessary for Thread::stop() and quick response to
GC.
In DRLVM BBP introduces an overhead about 1-2% (on single-threaded
workloads), which could be optimized out. Currently, backedges are
polled for non-interruptable loops. We could detect finite loops and
poll them more wisely.
BTW, Jrockit sometimes forgets about polling. Harmony should be better.
Yet, we can turn BBP off with a quick experimental option:
-Xjit ia32::bbp=off{0},jet::no_bbp=true
* Over-synchronization removal
Nested synchronization blocks on the same object can be removed. Not
done in DRLVM yet.
So, any compiler-guy interested in JIT enhancements is welcome to
participate. Any JIT-related questions are welcome too.
Voluteers? :)
[1] LIL: An Architecture-Neutral Language for Virtual-Machine Stubs
(http://www.usenix.org/events/vm04/tech/full_papers/glew/glew_html/index.html)
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: build problems
On 22 June 2006 at 9:28, Tim Ellison [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 22 June 2006 at 10:25, Vladimir Ivanov [EMAIL PROTECTED] wrote:
1) the dependency on ecj_3.2RC5 is not checked:
[copy] Copying
C:\harmony\trunk_0427\depends\jars\bcprov-jdk14-133\bcprov.jar to
C:\harmony\trunk_0427\deploy\jdk\jre\lib\ext\bcprov.jar
BUILD FAILED
C:\harmony\trunk_0427\build.xml:83: The following error occurred while
executing this line:
C:\harmony\trunk_0427\make\build-java.xml:161:
C:\harmony\trunk_0427\depends\jars\ecj_3.2RC5 not found.
Total time: 2 minutes 31 seconds
...
Fixed in r416240. Thanks for the report.
Apologies, that was my oversight. There was code to check it, but I had
left it commented out.
2) the build failed on java-compilation on the WinXP with 1Gb RAM (650Mb
free) as:
...
compile:
[mkdir] Created dir: C:\users\TCKTeam\ws\trunk\build
[javac] Compiling 2895 source files to C:\users\TCKTeam\ws\trunk\build
[javac] The system is out of resources.
[javac] Consult the following stack trace for details.
[javac] java.lang.OutOfMemoryError: Java heap space
BUILD FAILED
C:\users\TCKTeam\ws\trunk\build.xml:83: The following error occurred while
executing this line:
C:\users\TCKTeam\ws\trunk\make\build-java.xml:84: Compile failed; see the
compiler error output for details.
Total time: 1 minute 8 seconds
To fix it the build-java.xml was updated (locally) as:
javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
destdir=${build.output} source=${hy.javac.source} target=${
hy.javac.target} debug=on
Good idea. Fixed in r416245.
Not a good idea :-( I'm compiling successfully with the non-forked VM
and -Xmx256m (that works with Sun 5.0 JDK), now I have to fork another
process that will immediately grab 512Mb RAM ?! That's excessive.
As a compromise can we remove the inital size param and reduce the max
memory?
Good point. Yes. Feel free to change it to something more appropriate,
I'm still able to compile with -Xmx512m (on Windows and Linux) so assume
that should be enough for Vladimir too?
Regards,
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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Tim Ellison skrev den 22-06-2006 10:37: Given that ECJ is now a dependency for our emerging javac tool, perhaps we should make it the default in the build system too? Sounds like a good idea. It also loosens the initial Java requirement on the host system to be a JRE instead of a JDK. I just built classlib with the ecj compiler adapter and build.xml, so it should be trivial to change. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
On 22 June 2006 at 11:45, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL PROTECTED] wrote: Tim Ellison skrev den 22-06-2006 10:37: Given that ECJ is now a dependency for our emerging javac tool, perhaps we should make it the default in the build system too? +1 Sounds like a good idea. It also loosens the initial Java requirement on the host system to be a JRE instead of a JDK. I just built classlib with the ecj compiler adapter and build.xml, so it should be trivial to change. And it might give people an incentive to fix the compiler warnings. ;-) Regards, 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: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Magnusson, Geir wrote: Could you send me the code for Process so I can see what's going on here? :) Process is a boring abstract type, I suspect that you want to look at SystemProcess [1] and the associated natives [2]. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/process/SystemProcess.java?view=markup [2] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/luni/process.c?view=markup 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]
[general] Produce updated snapshots in time for ApacheConEU?
It has been about a month since our last snapshot, how about we do another in the next few days (in time for ApacheConEU)? Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? 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]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Paulex Yang wrote: Oliver Deakin wrote: Paulex Yang wrote: Seems no one objects this proposal:), so I'm going to implement the JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578, Because this implementation requires some native codes, so I probably need to reintroduce hynio.dll(.so), but I have some questions.(Excuse me about my ignorance on the native layout evolution). At first, seems native codes will be separated into modules(I guess Oli is working on?), so should I assume my native codes will be directly put into nio modules, or still in native-src/win.IA32/nio directory? because I'm used to provide a shell to move/svn add new files in the patch, so it will be easier for me to know how others think about it. It depends on whether you want to wait for what I'm doing or not :) If you want to get the code out now, then you can temporarily put it under native-src/win.IA32/nio and I will move it later as part of the natives modularisation. However, if you don't mind waiting a day or so I should be able to submit my first patch to move the prefs natives. This ought to be enough of an example for you to put your native code directly into modules/nio/src/main/native. And second, the native codes probably need portlib, so the portlib's header file must be accessible, say, portsock.h, but now it has been moved into luni/src/main/native/blabla, should I include one in my patch so that nio module can have a copy? or the header file itself should be put some other well known directory(deploy/build/include I guess)? At build time, the copy.native.includes target in luni/make/build.xml is called - it copies a selection of the header files in luni/src/main/native/include that need to be shared between modules into the deploy/include directory. This is done with an explicit fileset in luni/make/build.xml - if you need to have portsock.h added to the list of shared header files, then this is the place to make that change. Just add its filename to the list, and next time you build it will appear in the deploy/include directory. Your nio code should include the headers from the deploy/include dir, and *not* directly from the luni/src/main/native/include dir. Oli, I tried to modify the luni/make/build.xml, and it successfully copied the portsock.h, but I found I still cannot build my native codes. So I looked inside the portsock.h, and found that all its content is just to include another file: ../port/hysock.h, my native codes in modules/nio/src/main/native cannot find ../port/hysock.h so it fails. I guess the reason why the luni natives still can build is all LUNI's native codes are still located in native-src/luni, so they can found the hysock.h in native-src/port. Seems portsock.h is useless and confusable, so I suggest the steps below to fix this problem: 1. svn delete portsock.h in luni 2. svn move hysock.h from native-src to luni 3. update all reference to portsock.h to hysock.h 4. rebuild Yes, that sounds reasonable. From what I can see portsock.h is basically pointless, since it just includes hysock.h. Your plan to replace portsock.h with hysock.h sounds like the right thing to do here. If no one objects, I'll raise a separated JIRA and provide patch Thanks! Regards, Oliver I hope this makes more sense now - if it doesn't, please let me know. I am in the process of writing up some documentation for the website on the natives layout and where headers should go (and also how modules should build against the HDK) - once that is complete it should all be a lot clearer. Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - 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] Produce updated snapshots in time for ApacheConEU?
Tim Ellison skrev den 22-06-2006 12:49: It has been about a month since our last snapshot, how about we do another in the next few days (in time for ApacheConEU)? Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Perhaps this is a good time to get the automated builds going? I would be interested in helping out on that. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: [classlib] Help wanted!
Nathan Beyer wrote: I've been hacking away at those warnings every chance I get. The 'luni' module is going to be filled warnings until we can begin using annotations, specifically the @SuppressWarning, especially the Collections classes. Thanks to George [1] you can now use @SuppressWarning. [1] http://svn.apache.org/viewvc?view=revrevision=416121 Regards, Tim There are a number of cases where unchecked type uses are a requirement because of limitations in current APIs, backwards compatability and generic array construction. Here are some of the major pieces that can't be avoided and need suppressing annotations: * Cloning - When you clone a generified object you have no choice but to do an unchecked cast. * Generic Array Construction - The only thing you can do is T[] = (T[])new Object[size]; and suppress the warning. In any case, I'm all for keep this stuff as clean as possible. I have my Eclipse compiler settings cranked to the max in the IDE. -Nathan -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 12:49 AM To: Apache Harmony Dev List Subject: [classlib] Help wanted! I was looking at building (and testing) with Eclipse + IBM VME. I think this is really important since ecj has a much cleaner classpath when it compiles so it helps us find errors quicker. The logs come out at over 3MB! There are lots of warnings about less than ideal type checking - mostly as a result of our adoption of more generics. For example: [javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 44) [javac] relations.add(relation); [javac] ^^^ [javac] Type safety: The method add(Object) belongs to the raw type Vector. References to generic type VectorE should be parameterized [javac] -- [javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 88) [javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r elations.size()]); [javac] ^^ ^ [javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve ctor. References to generic type VectorE should be parameterized I think we should try to improve these, but there are rather too many for me to do on my own! What do others think? I think we could disable the warnings from Eclipse but I don't think that's really the right thing to do. The distribution of warnings is as follows: 4 accessibility 24 archive 90 auth 707 awt 61 beans 7 crypto 128 jndi 206 luni 10 luni-kernel 4 misc 8 nio 7 nio_char 32 prefs 17 regex 260 rmi 568 security 936 swing 26 text 14 x-net Regards, Mark. - 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] -- 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]
Re: build problems
Initial size can be reduced, it works fine. So far… Since the number of
files to compile will only grow as time goes.
Isn't it more general solution compile sources by modules (in same VM,
without fork)?
Thanks, Vladimir
On 6/22/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 22 June 2006 at 9:28, Tim Ellison [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 22 June 2006 at 10:25, Vladimir Ivanov [EMAIL PROTECTED]
wrote:
1) the dependency on ecj_3.2RC5 is not checked:
[copy] Copying
C:\harmony\trunk_0427\depends\jars\bcprov-jdk14-133\bcprov.jar to
C:\harmony\trunk_0427\deploy\jdk\jre\lib\ext\bcprov.jar
BUILD FAILED
C:\harmony\trunk_0427\build.xml:83: The following error occurred
while
executing this line:
C:\harmony\trunk_0427\make\build-java.xml:161:
C:\harmony\trunk_0427\depends\jars\ecj_3.2RC5 not found.
Total time: 2 minutes 31 seconds
...
Fixed in r416240. Thanks for the report.
Apologies, that was my oversight. There was code to check it, but I had
left it commented out.
2) the build failed on java-compilation on the WinXP with 1Gb RAM
(650Mb
free) as:
...
compile:
[mkdir] Created dir: C:\users\TCKTeam\ws\trunk\build
[javac] Compiling 2895 source files to
C:\users\TCKTeam\ws\trunk\build
[javac] The system is out of resources.
[javac] Consult the following stack trace for details.
[javac] java.lang.OutOfMemoryError: Java heap space
BUILD FAILED
C:\users\TCKTeam\ws\trunk\build.xml:83: The following error occurred
while
executing this line:
C:\users\TCKTeam\ws\trunk\make\build-java.xml:84: Compile failed; see
the
compiler error output for details.
Total time: 1 minute 8 seconds
To fix it the build-java.xml was updated (locally) as:
javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
destdir=${ build.output} source=${hy.javac.source} target=${
hy.javac.target} debug=on
Good idea. Fixed in r416245.
Not a good idea :-( I'm compiling successfully with the non-forked VM
and -Xmx256m (that works with Sun 5.0 JDK), now I have to fork another
process that will immediately grab 512Mb RAM ?! That's excessive.
As a compromise can we remove the inital size param and reduce the max
memory?
Good point. Yes. Feel free to change it to something more appropriate,
I'm still able to compile with -Xmx512m (on Windows and Linux) so assume
that should be enough for Vladimir too?
Regards,
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: build problems
Vladimir Ivanov wrote: Initial size can be reduced, it works fine. So far… Since the number of files to compile will only grow as time goes. Isn't it more general solution compile sources by modules (in same VM, without fork)? That's how I normally work anyway, and as we have snapshots available to compile against people can always bootstrap the module compilation from a previous build. However, we do need to retain the option to rebuild the entire world from scratch, so I expect there will always be a top level build. I'll reduce the footprint options -- please howl if it does not suit. 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]
Re: [classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
Mikhail, I can convert it to JUnit, but I'm not pretty sure about returning pass/fail. When you think test should return fail? Results of test execution can be different on different VM's, it also dependent of machine speed, etc. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and
Re: [general] Produce updated snapshots in time for ApacheConEU?
Thorbjørn Ravn Andersen wrote: Tim Ellison skrev den 22-06-2006 12:49: It has been about a month since our last snapshot, how about we do another in the next few days (in time for ApacheConEU)? Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Perhaps this is a good time to get the automated builds going? I would be interested in helping out on that. Thanks! that would be great. The problem, AIUI, is that we are only building Windows/Linux 32-bit code at the moment, and there is no ASF infrastructure where we can host automated builds on those platforms. IBM are running continuum builds regularly on Win/Lin 32, but it is not ideal since (a) people cannot login to IBM machines and tweak/download the automated builds, and (b) for some unknown reason the build reports don't make it through to the commit list. If you have some ideas I'd be delighted to hear them. 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]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Archie Cobbs wrote:
Paulex Yang wrote:
I'm still curious what mechanism will be used to wakeup blocked threads
though.
And when Thread.interrupt() executes the interruptAction and closes
the channel, generally the blocking I/O operation will return with an
error code, and if Harmony user implements a subclass of
AbstractInterruptibleChannel, he is required by spec to implement
implCloseChannel(which is invoked by close()) in similar way, in both
cases, the thread is waken up as by product.
The blocking select is waken up in similar way by invoke wakeup() in
interruptAction.
Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(),
Thread.join(), or Thread.sleep(), I guess they will require an
interrupt action which invokes a native method (equivalent to
the current situation), right? I.e., these cases would be handled
entirely by the VM.
Actually I propose the default value of interrupt action is null,
which means the VM will do what it suppose to do for the general
cases(wait(), join(), etc) as before, so the interrupt() might looks like:
public void interrupt(){
if(action != null){
action.run();
}
//call native method to do what it supposed to do
interruptImpl();
}
And as the part of the proposal, the end() of AbstractSelector and
AbstractInterruptibleChannel will reset the thread's interrupt action to
null, which marks the blocking I/O/select operation ends.
-Archie
__
Archie Cobbs *CTO, Awarix*
http://www.awarix.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
thx - I've figured out what's going on... fork() is failing When I run eclipse w a big max heap, it fails. When it's default heap, it doesn't. I'd love to claim that it's Eclipe's fault, but clearly there's some ulimit thingy in Ubuntu. Anyway, I'm going to rework the natives so that fork failure results in an exception since I can make it happen. Stay tuned. geir Tim Ellison wrote: Magnusson, Geir wrote: Could you send me the code for Process so I can see what's going on here? :) Process is a boring abstract type, I suspect that you want to look at SystemProcess [1] and the associated natives [2]. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/process/SystemProcess.java?view=markup [2] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/luni/process.c?view=markup Regards, Tim - 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] Produce updated snapshots in time for ApacheConEU?
Tim Ellison wrote: It has been about a month since our last snapshot, how about we do another in the next few days (in time for ApacheConEU)? Definitely (so we can knock that off the roadmap list :) Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Yes. I think that we'd want 3 : 1) classlib 2) drlvm + classlib 3) jchevm + adapater + classlib (hey, archie, when are you going to make adapter redundant for jchevm???) I have the 'federation code' in progress, so I'll take the task of adding the 'federated snapshot' to that. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Produce updated snapshots in time for ApacheConEU?
Tim Ellison wrote: Thorbjørn Ravn Andersen wrote: Tim Ellison skrev den 22-06-2006 12:49: It has been about a month since our last snapshot, how about we do another in the next few days (in time for ApacheConEU)? Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Perhaps this is a good time to get the automated builds going? I would be interested in helping out on that. Thanks! that would be great. The problem, AIUI, is that we are only building Windows/Linux 32-bit code at the moment, and there is no ASF infrastructure where we can host automated builds on those platforms. And I don't think we'll ever have that as we want in terms of diversity. We can get something going at some point, but I really feel that making it easy for anyone to just checkout the build/CI/test infrastructure and run it would give us lots of eyes and lots of diversity (this is the core of the testing/build discussion we started a while ago) IBM are running continuum builds regularly on Win/Lin 32, but it is not ideal since (a) people cannot login to IBM machines and tweak/download the automated builds, and (b) for some unknown reason the build reports don't make it through to the commit list. The do. Just not huge ones. There's a size limit on the list. If you have some ideas I'd be delighted to hear them. What I threw out there was to get that continuum configuration donated by IBM to seed our build/testing subproject. Then we all can be running the same thing and start enhancing it with additional testing and tooling. I keep bugging mark, and it's on his list :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SableVM] please tell us the status of the Apache License 2.0
Etienne, My apologies if its already been disclosed on harmony-dev. I searched for 20 minutes and could not find anything more recent than: http://sablevm.org/lists/sablevm-devel/2006-March/000620.html -- Weldon Washburn 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]
[classlib] [beans] xml resource files in tests
Hi people, While working on java.beans tests I've faced a funny problem. There are tests for XMLEncoder that perform line by line comparison of the encoder's output with static xml files from /test/resources folder (string compare). And it seems that at some point of time someone simply prepend Apache license to all static xmls and all tests fail since then. :) Since there is no easy way to force XMLEncoder to generate Apache license, I see two possible resolutions: 1. Remove the license from xmls. I am not sure we can do that. 2. Replace string compare with xml compare, by means of sax parser for example. Comments will be thrown away in this case. Personally I like (2) more. However, it will take additional efforts. Suggestions? -- 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]
Re: svn commit: r415915 - /incubator/harmony/enhanced/classlib/trunk/depends/jars/
This change reminded me about something. The big javac in
make/build-java.xml currently has:
classpath
fileset dir=${depends.jars}
include name=**/*.jar /
/fileset
/classpath
which means that if you have old versions of dependencies in
depends/jars/*/*.jar then they will be picked up by the build. I
actually saw a compiler error the other day because of this - building
with a version of ecj.
I assume Mikhail put these back because (like me) he likes to keep
the old versions around just in case he wants to test an old classlib
version - for instance doing a binary chop to find when a regression
occurred.
The fix for this would be to defined in depends.xml a reference property
that defined the fileset for the current versions of these dependencies.
I will take a look at this unless anyone objects.
Regards,
Mark.
On 21 June 2006 at 5:24, [EMAIL PROTECTED] wrote:
Author: mloenko
Date: Tue Jun 20 22:24:58 2006
New Revision: 415915
URL: http://svn.apache.org/viewvc?rev=415915view=rev
Log:
add depends jars to svn:ignore
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/jars/ (props changed)
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/jars/
-
-
--- svn:ignore (original)
+++ svn:ignore Tue Jun 20 22:24:58 2006
@@ -1,3 +1,4 @@
+
bcprov-jdk14-133
ecj_3.2RC5
icu4j_3.4.4
@@ -5,3 +6,7 @@
mx4j_3.0.1
xalan-j_2.7.0
xerces_2.8.0
+bcprov-jdk14-132
+junit_3.8.1
+xalan-j_2.6.0
+xerces_2.6.2
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[admin] FYI Tweak to the ACQ
Somebody pointed out to me privately that our contributor questionnaire [1] doesn't explicitly mention JNDI (javax.naming.*) as part of the class library. I'll add it for completeness so people do not have to remember to mention it in the 'other' category. There is no substantial change to the form (and the existing form is still perfectly valid). [1] http://incubator.apache.org/harmony/auth_cont_quest.html 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]
automated builds (was: Re: [general] Produce updated snapshots in time for ApacheConEU?)
Geir Magnusson Jr wrote: Tim Ellison wrote: snip The problem, AIUI, is that we are only building Windows/Linux 32-bit code at the moment, and there is no ASF infrastructure where we can host automated builds on those platforms. And I don't think we'll ever have that as we want in terms of diversity. We can get something going at some point, but I really feel that making it easy for anyone to just checkout the build/CI/test infrastructure and run it would give us lots of eyes and lots of diversity (this is the core of the testing/build discussion we started a while ago) Anyone can checkout the code today and invoke the build / test target from a build machine. What infrastructure were you thinking of? I meant access to the build machines directly so you can look at build history, access old builds, test results, etc. IBM are running continuum builds regularly on Win/Lin 32, but it is not ideal since (a) people cannot login to IBM machines and tweak/download the automated builds, and (b) for some unknown reason the build reports don't make it through to the commit list. The do. Just not huge ones. There's a size limit on the list. What is the limit? 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]
Re: [classlib] [beans] xml resource files in tests
Hi, Is it easier to preprocess golden files data before the string comparison? Removing first XML comment with the text Copyright*Apache seems to be an action which can not modify content used in the comparison. Thank you. Ilya Neverov, Intel Middleware Products Division On 6/22/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi people, While working on java.beans tests I've faced a funny problem. There are tests for XMLEncoder that perform line by line comparison of the encoder's output with static xml files from /test/resources folder (string compare). And it seems that at some point of time someone simply prepend Apache license to all static xmls and all tests fail since then. :) Since there is no easy way to force XMLEncoder to generate Apache license, I see two possible resolutions: 1. Remove the license from xmls. I am not sure we can do that. 2. Replace string compare with xml compare, by means of sax parser for example. Comments will be thrown away in this case. Personally I like (2) more. However, it will take additional efforts. Suggestions? -- 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]
[general] Re: automated builds
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: snip The problem, AIUI, is that we are only building Windows/Linux 32-bit code at the moment, and there is no ASF infrastructure where we can host automated builds on those platforms. And I don't think we'll ever have that as we want in terms of diversity. We can get something going at some point, but I really feel that making it easy for anyone to just checkout the build/CI/test infrastructure and run it would give us lots of eyes and lots of diversity (this is the core of the testing/build discussion we started a while ago) Anyone can checkout the code today and invoke the build / test target from a build machine. What infrastructure were you thinking of? We want to set up something broader than that. You should go re-read what I wrote, but the recap is to start another peer 'subproject' called 'testing' or something, from which you can checkout a complete configuration that uses whatever we choose (continuum right now) to do automated checkout, build and test of everything, including end to end testing, stress testing, TCK when we get it, etc. Just checkout, do a minor configure, and get out of the way :) This will allow anyone in the community to run the identical setup, on a wider variety of platforms than ever possible to host at the ASF, etc. We'll still eventually get something going at the ASF that uses this, but the focus should be on the configuration, rather than the place where it is done. I'd then guess we'd have all those machine reporting breakage, and keep a tally of the OS version, platforms, etc that people are using to test. I meant access to the build machines directly so you can look at build history, access old builds, test results, etc. While I'm sure we'll be doing some builds here, I'd like to spin the perspective so that we get a 'testing community' started around a common configuration. IBM are running continuum builds regularly on Win/Lin 32, but it is not ideal since (a) people cannot login to IBM machines and tweak/download the automated builds, and (b) for some unknown reason the build reports don't make it through to the commit list. The do. Just not huge ones. There's a size limit on the list. What is the limit? I don't remember. I can look it up, but this seems to be a losing proposition. Maybe the solution is to copy the result file to a directory somewhere on people.apache.org and send a pointer or osmething.. geir Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415915 - /incubator/harmony/enhanced/classlib/trunk/depends/jars/
Hi Mark,
I've added the things to svn::ignore to not commit the binaries accidently.
Mikhail
2006/6/22, Mark Hindess [EMAIL PROTECTED]:
This change reminded me about something. The big javac in
make/build-java.xml currently has:
classpath
fileset dir=${depends.jars}
include name=**/*.jar /
/fileset
/classpath
which means that if you have old versions of dependencies in
depends/jars/*/*.jar then they will be picked up by the build. I
actually saw a compiler error the other day because of this - building
with a version of ecj.
I assume Mikhail put these back because (like me) he likes to keep
the old versions around just in case he wants to test an old classlib
version - for instance doing a binary chop to find when a regression
occurred.
The fix for this would be to defined in depends.xml a reference property
that defined the fileset for the current versions of these dependencies.
I will take a look at this unless anyone objects.
Regards,
Mark.
On 21 June 2006 at 5:24, [EMAIL PROTECTED] wrote:
Author: mloenko
Date: Tue Jun 20 22:24:58 2006
New Revision: 415915
URL: http://svn.apache.org/viewvc?rev=415915view=rev
Log:
add depends jars to svn:ignore
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/jars/ (props changed)
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/jars/
-
-
--- svn:ignore (original)
+++ svn:ignore Tue Jun 20 22:24:58 2006
@@ -1,3 +1,4 @@
+
bcprov-jdk14-133
ecj_3.2RC5
icu4j_3.4.4
@@ -5,3 +6,7 @@
mx4j_3.0.1
xalan-j_2.7.0
xerces_2.8.0
+bcprov-jdk14-132
+junit_3.8.1
+xalan-j_2.6.0
+xerces_2.6.2
-
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][math] Location of performance tests (was: Re: performance improvement for java.math package)
The first thing that came into my mind is as far as it is a regression test, put somewhere next to the test both old and new Math implementations, measure 'golden' performances and than measure where the current performance in comparison to the golden is. This scenario might be simplified. If your optimization works e.g. for numbers less than say 1'000'000, you can compare performance for 999'999 and 1'000'001 Thanks, Mikhail 2006/6/22, Vladimir Strigun [EMAIL PROTECTED]: Mikhail, I can convert it to JUnit, but I'm not pretty sure about returning pass/fail. When you think test should return fail? Results of test execution can be different on different VM's, it also dependent of machine speed, etc. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after
Re: Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
Hi Andrew,
have you noticed, does RI return 0 for any unbound socket or
only for the sockets obtained from SocketChannel?
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if the
socket is not bound yet. That's how spec describes getLocalPort method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
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: [classlib] [beans] xml resource files in tests
Ilya, yes, it is technically possible. But IMHO is not very elegant at the same time. 2006/6/22, Ilya Neverov [EMAIL PROTECTED]: Hi, Is it easier to preprocess golden files data before the string comparison? Removing first XML comment with the text Copyright*Apache seems to be an action which can not modify content used in the comparison. Thank you. Ilya Neverov, Intel Middleware Products Division On 6/22/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi people, While working on java.beans tests I've faced a funny problem. There are tests for XMLEncoder that perform line by line comparison of the encoder's output with static xml files from /test/resources folder (string compare). And it seems that at some point of time someone simply prepend Apache license to all static xmls and all tests fail since then. :) Since there is no easy way to force XMLEncoder to generate Apache license, I see two possible resolutions: 1. Remove the license from xmls. I am not sure we can do that. 2. Replace string compare with xml compare, by means of sax parser for example. Comments will be thrown away in this case. Personally I like (2) more. However, it will take additional efforts. Suggestions? -- Alexei Zakharov, Intel Middleware Product Division -- 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]
Re: Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
Hi Mikhail,
So far as I know, only the socket obtained from SocketChannel returns 0
instead of -1.
If the socket is constructed directly, it returns -1 as spec says. Following
test passes against RI without any problem.
public void test_socket() throws IOException {
Socket s = new Socket();
assertFalse(s.isBound());
assertEquals(-1, s.getLocalPort());
}
Thanks!
On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Andrew,
have you noticed, does RI return 0 for any unbound socket or
only for the sockets obtained from SocketChannel?
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if
the
socket is not bound yet. That's how spec describes getLocalPort method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [general] Re: automated builds
Geir Magnusson Jr wrote: big snip I don't remember. I can look it up, but this seems to be a losing proposition. Maybe the solution is to copy the result file to a directory somewhere on people.apache.org and send a pointer or osmething.. Isn't this a reasonable first problem to solve? i.e. we (Harmony) have a simple build/test framework (our Ant scripts) but no way to report the results of running them back to the community. 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]
Re: Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
Andrew,
How the current Harmony codes looks like?
According to our compatibility guideline[1], we should stick to Spec if
it is clearly stated.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Andrew Zhang wrote:
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if the
socket is not bound yet. That's how spec describes getLocalPort method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [beans] xml resource files in tests
Well, the real question I'd like to get an answer for was: is it really impossible to remove the license from these files? 2006/6/22, Alexei Zakharov [EMAIL PROTECTED]: Ilya, yes, it is technically possible. But IMHO is not very elegant at the same time. 2006/6/22, Ilya Neverov [EMAIL PROTECTED]: Hi, Is it easier to preprocess golden files data before the string comparison? Removing first XML comment with the text Copyright*Apache seems to be an action which can not modify content used in the comparison. Thank you. Ilya Neverov, Intel Middleware Products Division On 6/22/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi people, While working on java.beans tests I've faced a funny problem. There are tests for XMLEncoder that perform line by line comparison of the encoder's output with static xml files from /test/resources folder (string compare). And it seems that at some point of time someone simply prepend Apache license to all static xmls and all tests fail since then. :) Since there is no easy way to force XMLEncoder to generate Apache license, I see two possible resolutions: 1. Remove the license from xmls. I am not sure we can do that. 2. Replace string compare with xml compare, by means of sax parser for example. Comments will be thrown away in this case. Personally I like (2) more. However, it will take additional efforts. Suggestions? -- Alexei Zakharov, Intel Middleware Product Division -- 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]
Yet more build.xml cleanup...
More items for discussion:
1) Move src/main class files from build to build/classes. I mentioned
this a day or two ago so I'm going to do this soon unless anyone
objects.
2) Move the archive, luni, nio_char, and text clauses from
make/build-test.xml in to the respective module ant files. And at the
same time change the target of the moves to be the bin/test directory
within the module. (To more easily facilitate the creation of module
test jars.)
3) Move the deploy/build/*.{mak,mk} files to deploy/build/make.
4) Make a jar from the test support classes to live in the deploy/build/
test. To enable me to do ...
5) Add a call to the test support jar target to the end of the top-level
'build' target. This is to enable the following to just work:
svn co ...
cd classlib
ant build
cd modules/luni
# work on module
ant test
I'd like to say this is the last of the things I'd like to fix, but I'm
sure I'll see more when I go to fix these.
Regards,
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: [general] Re: automated builds
Tim Ellison wrote: Geir Magnusson Jr wrote: big snip I don't remember. I can look it up, but this seems to be a losing proposition. Maybe the solution is to copy the result file to a directory somewhere on people.apache.org and send a pointer or osmething.. Isn't this a reasonable first problem to solve? i.e. we (Harmony) have a simple build/test framework (our Ant scripts) but no way to report the results of running them back to the community. Yes, a good first problem Right now, the list is 100k (I think I'm reading it right) I'll goose it upward as a temporary hack (first, please tell me how big the messages are that aren't getting through...), but I think we need to start thinking about how community members can publish their results on the website... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Re: automated builds
try it - I set it to 330k max now (I asked Mark) Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: big snip I don't remember. I can look it up, but this seems to be a losing proposition. Maybe the solution is to copy the result file to a directory somewhere on people.apache.org and send a pointer or osmething.. Isn't this a reasonable first problem to solve? i.e. we (Harmony) have a simple build/test framework (our Ant scripts) but no way to report the results of running them back to the community. Yes, a good first problem Right now, the list is 100k (I think I'm reading it right) I'll goose it upward as a temporary hack (first, please tell me how big the messages are that aren't getting through...), but I think we need to start thinking about how community members can publish their results on the website... 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: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote:
Actually I propose the default value of interrupt action is null,
which means the VM will do what it suppose to do for the general
cases(wait(), join(), etc) as before, so the interrupt() might looks like:
public void interrupt(){
if(action != null){
action.run();
}
//call native method to do what it supposed to do
interruptImpl();
}
If you do that, and the VM uses signals, then interruptImpl() is going to
unexpectedly
wake up your NIO threads with a signal, right?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Produce updated snapshots in time for ApacheConEU?
Geir Magnusson Jr wrote: Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Yes. I think that we'd want 3 : 1) classlib 2) drlvm + classlib 3) jchevm + adapater + classlib (hey, archie, when are you going to make adapter redundant for jchevm???) I thought we wanted to keep the adpater distinct, so that one could (in theory) re-use it with other Classpath-compatible JVMs... ? Similarly, it's advantageous for JCHEVM to remain compatible with both classlib and Classpath for testing and comparison purposes. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
Then I believe we should go spec
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
So far as I know, only the socket obtained from SocketChannel returns 0
instead of -1.
If the socket is constructed directly, it returns -1 as spec says. Following
test passes against RI without any problem.
public void test_socket() throws IOException {
Socket s = new Socket();
assertFalse(s.isBound());
assertEquals(-1, s.getLocalPort());
}
Thanks!
On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Andrew,
have you noticed, does RI return 0 for any unbound socket or
only for the sockets obtained from SocketChannel?
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if
the
socket is not bound yet. That's how spec describes getLocalPort method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
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]
--
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] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
This is now resolved. Waiting for squawks of protest before closing. Things to think about/do : 1) We need richer return codes from procimpl.c execProgram() for windows. 2) I'll find out what config on Ubuntu allowed this behavior (had fork() fail) and we should add a regression for it, and start doing more stress testing, as I wonder what else we'll find geir Geir Magnusson Jr wrote: And btw, thanks to Tim, Mark and Oliver for thinking about this problem... Geir Magnusson Jr wrote: thx - I've figured out what's going on... fork() is failing When I run eclipse w a big max heap, it fails. When it's default heap, it doesn't. I'd love to claim that it's Eclipe's fault, but clearly there's some ulimit thingy in Ubuntu. Anyway, I'm going to rework the natives so that fork failure results in an exception since I can make it happen. Stay tuned. geir Tim Ellison wrote: Magnusson, Geir wrote: Could you send me the code for Process so I can see what's going on here? :) Process is a boring abstract type, I suspect that you want to look at SystemProcess [1] and the associated natives [2]. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/process/SystemProcess.java?view=markup [2] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/luni/process.c?view=markup Regards, Tim - 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]
Stack Overflow Error support issues
Hello.
As far as I know, current implementation of DRL VM doesn't support Stack
Overflow Error (SOE).
I have found it out using following test:
public class Stack {
static int depth = 0;
public static void func() {
depth++;
func();
}
public static void main(String[] args) {
try {
func();
} catch (Throwable th) {
System.out.println(First SOE depth = + depth);
System.out.println(Caught = + th);
}
}
}
I'm experimenting to add Stack Overflow Error (SOE) support using protected
memory page on the stack. I see and use two main schemes of exception
processing.
1. If top frame is unwindable (regular java code), then signal handler or
vectored exception handler throws regular java exception, as it can happen
now for NullPointerException.
2. If top frame is non-unwindable (for example, JNI native code) VM sets
exceptions for the current thread and continues its execution from
interrupted place. A code which works in nonunwindable mode should
periodically check that no exception is raised.
During my experiments I found some problems in current VM implementation
(including JIT)
1. Some parts of VM which use long recursion calls in non-unwindable mode
(JIT compiler, verifier) don't check that StackOverflowError has occured. I
added check that there are 256 Kbytes of free stack, before starting
compilation. But I'm afraid it is not enough sometimes.
2. If StackOverflowError is thrown during the first two commands of compiled
method, function unwind of the JIT cannot always unwind frame correctly.
Are there any ideas how to fix them?
I have some code developed locally, and can submit it to JIRA if anyone is
interested in trying it.
Thanks.
Pavel Afremov.
Re: svn commit: r416344 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
should we make this a property with a default so we can set it arbitrarily?
Not asking you to do it, but just wondering how people feel about having
that sort of thing...
geir
[EMAIL PROTECTED] wrote:
Author: tellison
Date: Thu Jun 22 05:14:48 2006
New Revision: 416344
URL: http://svn.apache.org/viewvc?rev=416344view=rev
Log:
Reduce forked compilation VM memory requirements.
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?rev=416344r1=416343r2=416344view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Thu Jun 22
05:14:48 2006
@@ -80,7 +80,7 @@
description=Compile the source
mkdir dir=${build.output} /
-javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
+javac fork=yes memoryMaximumSize=384M
destdir=${build.output}
source=${hy.javac.source} target=${hy.javac.target}
debug=${hy.javac.debug}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [drlvm] the build.... why?
As far as I understand, the trick with preprocessing XML files allows to keep platform-specific configuration compactly in one readable file. And by the way, the XML transformation (what you call meta build system) is only limited to filtering XML fragments based on the detected platform. Sorry for jumping in with a late explanation and thanks to Salikh who have already answered the most: Yes, this is correct - the DRLVM build generates XML scripts on the fly primarily to filter out the XML fragments which are irrelevant to the selected configuration (which is defined by attributes - OS, Arch, compiler, release/debug mode). Another idea behind the DRLVM build was to share as much building code between the different modules as possible, while trying to keep flexibility for each individual module. An intent was to let the code developers do not write any building code (like javac tasks) for their modules, but rather describe what the specific module is (see examples os the component descriptors under the drlvm/trunk/build/make/components directory). Some of the concepts of DRLVM build can be found at: drlvm/trunk/build/make/components/readme.txt Though this scheme may look pretty tricky, it helped to minimize the code in XML files and allowed to avoid writing makefiles for each specific module (only descriptors have to be written for the modules). You now may see whether it's convenient enough or not, but at least it worked :) Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml build.tmp.xml is produced just to put all modules together into a single file in order to process the dependencies between the modules correctly. Thank you, Andrey Chernyshev Intel Middleware Products Division On 6/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Geir Magnusson Jr wrote: What I don't understand is the motivation or the theory behind how and why it was done. I'm hoping that if I grok that, all will fall into place for me and with that different perspective, I might find it easier to work with. The two main requirements behind the design of this build system were 1. Unify the build system for the class library and VM But we can *easily* do that simply by having a top level script first invoke the DRLVM build, and then the classlibrary (or whatever order is approrpros...) 2. Do not use Cygwin for the build on Windows That's fine, although at some point, someone will hopefully make that work too. (and a number of other reasonable requirements 3. incremental build 4. tracking C++ dependencies 5. keeping platform-specific configuration in a compact and readable form) Ok As I understand it, it's really a meta build system, as it's purpose seems to be to create the actual ant scripts that execute to do the work. Why? (less sure about this one) As far as I understand, the trick with preprocessing XML files allows to keep platform-specific configuration compactly in one readable file. And by the way, the XML transformation (what you call meta build system) is only limited to filtering XML fragments based on the detected platform. Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml Also, it doesn't use 'make' for building the C/C++ code. Why? Using GNU make leads to requirement to have GNU tools on Windows (contradicts requirement (2) above) NMAKE cannot be used since it is not available on the Linux. We seem to do ok w/ classlib though...? Moreover, cctask from Ant-contrib is not bad in tracking dependencies and running various kinds of compilers. We used GNU Make for some time while preparing DRLVM contribution, but moved on to Ant-based system later because of requirements (1), (2). Ok, thanks. -- Salikh Zakirov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Help building on Windows!
On 6/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote: You can always take a look at what command lines build calls C compiler if you call build.bat with -d switch (it is just passed to ant). I am not sure if it One more tip to see what Ant really executes for you is to run: build.sh -verbose is the case but could it be spaces in the path like Documents and Settings? On Wednesday 21 June 2006 19:09 Oliver Deakin wrote: Hi all, I'm trying to build drlvm, and with a small amount of effort Ive got its prereqs and got it to start building, which is great. However, I hit a snag which stops the build from completing (8 mins in, sigh): build.native.init: [echo] ## Building native of 'vm.vmi' build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] j9vmls.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\j9 vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\vm i.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such fil e or directory [cc] Generating Code... BUILD FAILED C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:373 : The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:380 : The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build_compone nt.xml :72: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\win_ia32_msvc_rele ase\se mis\build\targets\build.native.xml:75: cl failed with return code 2 Total time: 7 minutes 50 seconds It looks like the build cannot find the classlib header files it needs. Unfortunately the error messages are unhelpful in that they don't tell me anything about the include paths used. I have set the CLASSLIB_HOME variable in make/win.properties to point to a prebuilt classlib/trunk checkout. Is there something else I need to set? Thanks, Oliver -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] build works on linux
I now have drlvm working w/ independent classlib and configure/make building of APR on linux. This is great, thanks! One more suggestion - what if we try using the precompiled binaries for APR, Log4cxx? Their compilation takes the significant time and may be extra cause of various building issues. Does something prevent us from keeping these binaries under SVN similarly how the icu libraries are kept? Is there any licensing issues given that APR/Log are Apache projects? These binaries will have to be prepared stored for each supported platform/config, I guess... Thanks, Andrey. On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I now have drlvm working w/ independent classlib and configure/make building of APR on linux. I had a lot of fun working through a lot of the gcc issues that others have. It was a good refresher course for me. It's working on Ubuntu 6.whatever using gcc/g++ version 3.4 and Sun's java 5. I can now continue the federated build stuff I was doing last week, and will keep removing the self-hosted dependencies, and use properties to point to them, like APR. - 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: [drlvm] the build.... why?
Well, this is something to look at going forward. So far, none of the core build process has been changed, just how dependencies are handled. geir Andrey Chernyshev wrote: As far as I understand, the trick with preprocessing XML files allows to keep platform-specific configuration compactly in one readable file. And by the way, the XML transformation (what you call meta build system) is only limited to filtering XML fragments based on the detected platform. Sorry for jumping in with a late explanation and thanks to Salikh who have already answered the most: Yes, this is correct - the DRLVM build generates XML scripts on the fly primarily to filter out the XML fragments which are irrelevant to the selected configuration (which is defined by attributes - OS, Arch, compiler, release/debug mode). Another idea behind the DRLVM build was to share as much building code between the different modules as possible, while trying to keep flexibility for each individual module. An intent was to let the code developers do not write any building code (like javac tasks) for their modules, but rather describe what the specific module is (see examples os the component descriptors under the drlvm/trunk/build/make/components directory). Some of the concepts of DRLVM build can be found at: drlvm/trunk/build/make/components/readme.txt Though this scheme may look pretty tricky, it helped to minimize the code in XML files and allowed to avoid writing makefiles for each specific module (only descriptors have to be written for the modules). You now may see whether it's convenient enough or not, but at least it worked :) Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml build.tmp.xml is produced just to put all modules together into a single file in order to process the dependencies between the modules correctly. Thank you, Andrey Chernyshev Intel Middleware Products Division On 6/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Geir Magnusson Jr wrote: What I don't understand is the motivation or the theory behind how and why it was done. I'm hoping that if I grok that, all will fall into place for me and with that different perspective, I might find it easier to work with. The two main requirements behind the design of this build system were 1. Unify the build system for the class library and VM But we can *easily* do that simply by having a top level script first invoke the DRLVM build, and then the classlibrary (or whatever order is approrpros...) 2. Do not use Cygwin for the build on Windows That's fine, although at some point, someone will hopefully make that work too. (and a number of other reasonable requirements 3. incremental build 4. tracking C++ dependencies 5. keeping platform-specific configuration in a compact and readable form) Ok As I understand it, it's really a meta build system, as it's purpose seems to be to create the actual ant scripts that execute to do the work. Why? (less sure about this one) As far as I understand, the trick with preprocessing XML files allows to keep platform-specific configuration compactly in one readable file. And by the way, the XML transformation (what you call meta build system) is only limited to filtering XML fragments based on the detected platform. Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml Also, it doesn't use 'make' for building the C/C++ code. Why? Using GNU make leads to requirement to have GNU tools on Windows (contradicts requirement (2) above) NMAKE cannot be used since it is not available on the Linux. We seem to do ok w/ classlib though...? Moreover, cctask from Ant-contrib is not bad in tracking dependencies and running various kinds of compilers. We used GNU Make for some time while preparing DRLVM contribution, but moved on to Ant-based system later because of requirements (1), (2). Ok, thanks. -- Salikh Zakirov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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 :
Re: Bug to bug compatibility: SocketChannel.socket().getLocalPort() returns 0 while Harmony returns -1
I agree, it should return -1 as per spec.
Regards,
Tim
Mikhail Loenko wrote:
Then I believe we should go spec
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
So far as I know, only the socket obtained from SocketChannel returns 0
instead of -1.
If the socket is constructed directly, it returns -1 as spec says.
Following
test passes against RI without any problem.
public void test_socket() throws IOException {
Socket s = new Socket();
assertFalse(s.isBound());
assertEquals(-1, s.getLocalPort());
}
Thanks!
On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Andrew,
have you noticed, does RI return 0 for any unbound socket or
only for the sockets obtained from SocketChannel?
Thanks,
Mikhail
2006/6/22, Andrew Zhang [EMAIL PROTECTED]:
Hi everybody,
I found a bug of SocketChannel.socket() of RI.
Consider following test case:
public void test_socket() throws IOException {
SocketChannel sc = SocketChannel.open();
Socket socket = sc.socket();
assertFalse(socket.isBound());
// RI returns 0 instead of -1 here.
assertEquals(-1, socket.getLocalPort());
}
RI 1.5 fails while Harmony passes.
returns the local port number to which this socket is bound or -1 if
the
socket is not bound yet. That's how spec describes getLocalPort
method.
RI returns 0 for an unbound socket, violates spec apparently.
How shall we deal with this bug to bug compatibility?
Any suggestions? Thank you very much!
--
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]
--
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]
--
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]
Re: [drlvm] build works on linux
Andrey Chernyshev wrote: I now have drlvm working w/ independent classlib and configure/make building of APR on linux. This is great, thanks! One more suggestion - what if we try using the precompiled binaries for APR, Log4cxx? What I want to do is remove the dependency builds completely from DRLVM. We have a way to easily get them (and build where necessary) as a part of the DRLVM directory tree or a peer (like /deps), but it shouldn't be a part of the DRLVM build, and we should use properties to point to the deps wherever the developer chooses to put them. Their compilation takes the significant time and may be extra cause of various building issues. Yep Does something prevent us from keeping these binaries under SVN similarly how the icu libraries are kept? Is there any licensing issues given that APR/Log are Apache projects? These binaries will have to be prepared stored for each supported platform/config, I guess... We would be able to do it if really necessary, but I'd rather avoid if we can. I do think that the current DRLVM shows that it can be avoided (so we have a way for people to get started) as well as the flexibility for people who want the control. geir Thanks, Andrey. On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I now have drlvm working w/ independent classlib and configure/make building of APR on linux. I had a lot of fun working through a lot of the gcc issues that others have. It was a good refresher course for me. It's working on Ubuntu 6.whatever using gcc/g++ version 3.4 and Sun's java 5. I can now continue the federated build stuff I was doing last week, and will keep removing the self-hosted dependencies, and use properties to point to them, like APR. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416344 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Sure -- done in r416469.
Regards,
Tim
Geir Magnusson Jr wrote:
should we make this a property with a default so we can set it arbitrarily?
Not asking you to do it, but just wondering how people feel about having
that sort of thing...
geir
[EMAIL PROTECTED] wrote:
Author: tellison
Date: Thu Jun 22 05:14:48 2006
New Revision: 416344
URL: http://svn.apache.org/viewvc?rev=416344view=rev
Log:
Reduce forked compilation VM memory requirements.
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?rev=416344r1=416343r2=416344view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Thu Jun 22
05:14:48 2006
@@ -80,7 +80,7 @@
description=Compile the source
mkdir dir=${build.output} /
-javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
+javac fork=yes memoryMaximumSize=384M
destdir=${build.output}
source=${hy.javac.source} target=${hy.javac.target}
debug=${hy.javac.debug}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
Re: [classlib]hythreads implementation
Marina Goldburt wrote: Hi, I've noticed such a strange thing when examined drlvm building process. The drlvm replaces hythreads shared library with its own simple implementation based on APR. The drlvm hythreads library exports less than 1/2 functions comparing with the original hythr.dll. Yes, that is strange. Don't know why DRLVM would replace the classlib's thread library -- seems a bit impolite ;-) I thought the rest of functions are used by J9 VM, but replacing hythread classlib implementation with the slightly modified drlvm one doesn't lead to problems (all tests passed with j9 vm too). The IBM VME doesn't use Harmony's thread library (there is a remarkably similar library in the VM subdir called j9thr23). And,of course, if other VM's want to use their own thread library they are free to do so. So, the question : Why we have so much code in the hythreads module if nobody neads it? The honest answer is, not all the thread library code is needed by classlib -- but it forms a comprehensive library for any VM / classlib / tools development. 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]
Re: [drlvm] build works on linux
On Friday 23 June 2006 00:44 Geir Magnusson Jr wrote: Does something prevent us from keeping these binaries under SVN similarly how the icu libraries are kept? Is there any licensing issues given that APR/Log are Apache projects? These binaries will have to be prepared stored for each supported platform/config, I guess... We would be able to do it if really necessary, but I'd rather avoid if we can. I do think that the current DRLVM shows that it can be avoided (so we have a way for people to get started) as well as the flexibility for people who want the control. From the Gentoo user standpoint who can just type emerge ant cpptasks eclipse log4cxx apr icu icu4j and get all the dependencies installed in the system I wholeheartedly support the way for build just to point to locations of already installed binaries. After all it is the way all other software actually installs on Linux. Yes for windows maybe we'll need binaries kept somewhere in a shed. -- Gregory Shimansky, 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: [DRLVM] building from svn on FC5
I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen build.native.cpp: [cc] Starting dependency analysis for 136 files. [cc] 136 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 5 total files to be compiled. [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? On 6/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 June 2006 at 0:03, Naveen Neelakantam [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn. I am running Fedora Core 5 with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3). However, I am getting the build error shown below. Previous posts on the dev list led me to believe that this issue had been resolved. Did a patch get lost in the transition to svn? Hi Naveen, I'm still testing the latest version of Ivan's patch mentioned in the message below, so it is not committed in svn yet. (I hope to finish testing it today or tomorrow.) But I don't see a JIRA with Vladimir's fixes for FC5 so I don't think this will help you. Vladimir, can you create a new JIRA with your additional changes (on top of Ivan's patch or on drlvm/trunk if I've committed Ivan's patch by the time you read this.) Regards, Mark. Thanks, Naveen On May 19, 2006, at 12:57 AM, Vladimir Gorr wrote: Small changes are required to fix the build issue for Fedora 5. I've prepared this patch and I'm ready to put it into JIRA. There are two ways to make this thing: - renew the cumulative patch created by Ivan (see JIRA issue below); - attach these changes as separate patch and adding it to the HARMONY-443. What way is more preferable? Thanks, Vladimir. On 5/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: The updated patch DRLVM-GCC-3.4_and_4.x- cumulative.patch is now in Harmony-443 JIRA with detailed instructions. http://issues.apache.org/jira/browse/HARMONY-443 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] building from svn on FC5
Odd. Nothing should have changed re log4cxx Sure nothing else changed? geir [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn on FC5, and it has a build error that I've seen before. This issue was resolved when I was using r413745, but now I am using r416471 and it is back. The error is below: Thanks, Naveen build.native.cpp: [cc] Starting dependency analysis for 136 files. [cc] 136 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 5 total files to be compiled. [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/xml/domconfigurat or.h:243: error: extra qualification ? log4cxx::xml::DOMConfigurator::? on member ?subst? [cc] /work/nneelaka/Sandbox/HarmonyVM/build/lnx_ia32_gcc_rele ase/semis/extra/log4cxx/src/include/log4cxx/helpers/unicodehe lper.h:98: error: extra qualification ? log4cxx::helpers::UnicodeHelper::? on member ?lengthUTF8? On 6/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 June 2006 at 0:03, Naveen Neelakantam [EMAIL PROTECTED] wrote: I just tried building DRLVM out of svn. I am running Fedora Core 5 with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3). However, I am getting the build error shown below. Previous posts on the dev list led me to believe that this issue had been resolved. Did a patch get lost in the transition to svn? Hi Naveen, I'm still testing the latest version of Ivan's patch mentioned in the message below, so it is not committed in svn yet. (I hope to finish testing it today or tomorrow.) But I don't see a JIRA with Vladimir's fixes for FC5 so I don't think this will help you. Vladimir, can you create a new JIRA with your additional changes (on top of Ivan's patch or on drlvm/trunk if I've committed Ivan's patch by the time you read this.) Regards, Mark. Thanks, Naveen On May 19, 2006, at 12:57 AM, Vladimir Gorr wrote: Small changes are required to fix the build issue for Fedora 5. I've prepared this patch and I'm ready to put it into JIRA. There are two ways to make this thing: - renew the cumulative patch created by Ivan (see JIRA issue below); - attach these changes as separate patch and adding it to the HARMONY-443. What way is more preferable? Thanks, Vladimir. On 5/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: The updated patch DRLVM-GCC-3.4_and_4.x- cumulative.patch is now in Harmony-443 JIRA with detailed instructions. http://issues.apache.org/jira/browse/HARMONY-443 - 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]
[drlvm] [classlib] Running specjvm98
Hello I've tried to run specjvm98 on Linux on drlvm and encountered several problems with it. I've created JIRA HARMONY-644 with those which I could resolve, I don't want to repeat what I wrote in comments there already. I have several questions yet after it. 1. Is it ok to modify Applet to extend Panel? I am entering not a well known for me territory of classlib in the current state, so I am not sure if I don't break something with it. 2. What is VM.bootCallerClassLoader() is supposed to return? If I understand it correctly from the comments it should return bootstrap class loader object. But I always thought that it is null by specification. 3. Spec still doesn't run, it now fails on Uncaught exception in AWT-EventQueue: java.lang.UnsatisfiedLinkError: Can not find the library: libaccessors.so at java.lang.Runtime.loadLibrary0() at java.lang.System.loadLibrary() at org.apache.harmony.misc.accessors.MemoryAccessor.getInstance(MemoryAccessor.java:35) at org.apache.harmony.misc.accessors.AccessorFactory.getMemoryAccessor(AccessorFactory.java:55) at org.apache.harmony.awt.nativebridge.NativeBridge.clinit(NativeBridge.java:31) at org.apache.harmony.awt.nativebridge.BasicLibWrapper.clinit(BasicLibWrapper.java:29) at org.apache.harmony.awt.wtk.linux.LinuxWindowFactory.clinit(LinuxWindowFactory.java:46) at org.apache.harmony.awt.wtk.linux.LinuxWTK.init(LinuxWTK.java:86) at java.lang.reflect.VMReflection.newClassInstance() at java.lang.reflect.Constructor.newInstance() at java.lang.Class.newInstance() at java.awt.Toolkit.createWTK(Toolkit.java:876) at java.awt.Toolkit.access$200(Toolkit.java:42) at java.awt.Toolkit$1.run(Toolkit.java:462) at java.awt.EventDispatchThread.run(EventDispatchThread.java:48) I didn't find this library, perhaps I am missing something... Where is it supposed to appear from? Is it native code from awt/swing which wasn't merged to build from the contribution yet? -- Gregory Shimansky, 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: [drlvm] build works on linux
Gregory Shimansky wrote: On Friday 23 June 2006 02:18 Geir Magnusson Jr wrote: We would be able to do it if really necessary, but I'd rather avoid if we can. I do think that the current DRLVM shows that it can be avoided (so we have a way for people to get started) as well as the flexibility for people who want the control. From the Gentoo user standpoint who can just type emerge ant cpptasks eclipse log4cxx apr icu icu4j and get all the dependencies installed in the system I wholeheartedly support the way for build just to point to locations of already installed binaries. Exactly. I wanted to add that patching ant with cpptasks as it is done today should not be allowed since system wide installations are usually write protected. :) Note that when we're finished, DRLVM shouldn't do anything to the filesystem outside of harmony/enhanced/drlvm/trunk After all it is the way all other software actually installs on Linux. Yes for windows maybe we'll need binaries kept somewhere in a shed. Nah :) Ok a set of URLs probably should be enough. Since there is no package manager in windows every library has to be downloaded somehow. But I just don't know off top of my head where to get log4cxx or apr libraries for windows and googling doesn't give any easy answer. We'll provide that in our developer docs. There are no APR binaries for windows (or anything else for that matter). The assumption is that if you are going to build harmony, you'll have the tools installed to build the deps if need be. If not, we offer build snapshots. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Produce updated snapshots in time for ApacheConEU?
Archie Cobbs wrote: Geir Magnusson Jr wrote: Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Yes. I think that we'd want 3 : 1) classlib 2) drlvm + classlib 3) jchevm + adapater + classlib (hey, archie, when are you going to make adapter redundant for jchevm???) I thought we wanted to keep the adpater distinct, so that one could (in theory) re-use it with other Classpath-compatible JVMs... ? Of course, but to give an end user a complete snapshot to play with, we want them all together in one easy-to-download bundle, right? Similarly, it's advantageous for JCHEVM to remain compatible with both classlib and Classpath for testing and comparison purposes. It will be interesting to compare, although classlib has to go through an extra glue layer... geir -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416344 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
not quite what I meant.
I want to be able to have a build.properties file in by /trunk
directory that is personal, not checked in, that lets me override stuff.
I was playing with it by adding a
property file=build.properties /
before the import in build.xml, and the problem seems to be that our
invocation of build-java is inheritall=false and then we read the
properties.xml file again in the build-java file, and it seems that a
propertyset in the ant in build.xml doesn't go through. The import
in build-java kills it?
One way I thought of is to do a
property file=build.properties /
in build-java.xml as well right before the import and that works.
However, having to do this down the chain smells wrong, but I guess
we're doing it w/ the import. I don't understand the idea behind it
(my ant sk1lz are rusty) so I'm hoping someone can shine some light here...
geir
Tim Ellison wrote:
Sure -- done in r416469.
Regards,
Tim
Geir Magnusson Jr wrote:
should we make this a property with a default so we can set it arbitrarily?
Not asking you to do it, but just wondering how people feel about having
that sort of thing...
geir
[EMAIL PROTECTED] wrote:
Author: tellison
Date: Thu Jun 22 05:14:48 2006
New Revision: 416344
URL: http://svn.apache.org/viewvc?rev=416344view=rev
Log:
Reduce forked compilation VM memory requirements.
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?rev=416344r1=416343r2=416344view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Thu Jun
22 05:14:48 2006
@@ -80,7 +80,7 @@
description=Compile the source
mkdir dir=${build.output} /
-javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
+javac fork=yes memoryMaximumSize=384M
destdir=${build.output}
source=${hy.javac.source} target=${hy.javac.target}
debug=${hy.javac.debug}
-
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] Help wanted!
Yeah, I noticed that. Unfortunately, it can only be used luni for now, since the compiler is turning it into an interface class. The sooner we move to 1.5 class files the better; I'm tired of the weird 1.5 source to 1.4 class file behavior that's basically undefined. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 6:04 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Help wanted! Nathan Beyer wrote: I've been hacking away at those warnings every chance I get. The 'luni' module is going to be filled warnings until we can begin using annotations, specifically the @SuppressWarning, especially the Collections classes. Thanks to George [1] you can now use @SuppressWarning. [1] http://svn.apache.org/viewvc?view=revrevision=416121 Regards, Tim There are a number of cases where unchecked type uses are a requirement because of limitations in current APIs, backwards compatability and generic array construction. Here are some of the major pieces that can't be avoided and need suppressing annotations: * Cloning - When you clone a generified object you have no choice but to do an unchecked cast. * Generic Array Construction - The only thing you can do is T[] = (T[])new Object[size]; and suppress the warning. In any case, I'm all for keep this stuff as clean as possible. I have my Eclipse compiler settings cranked to the max in the IDE. -Nathan -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 12:49 AM To: Apache Harmony Dev List Subject: [classlib] Help wanted! I was looking at building (and testing) with Eclipse + IBM VME. I think this is really important since ecj has a much cleaner classpath when it compiles so it helps us find errors quicker. The logs come out at over 3MB! There are lots of warnings about less than ideal type checking - mostly as a result of our adoption of more generics. For example: [javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 44) [javac] relations.add(relation); [javac] ^^^ [javac] Type safety: The method add(Object) belongs to the raw type Vector. References to generic type VectorE should be parameterized [javac] -- [javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 88) [javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r elations.size()]); [javac] ^^ ^ [javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve ctor. References to generic type VectorE should be parameterized I think we should try to improve these, but there are rather too many for me to do on my own! What do others think? I think we could disable the warnings from Eclipse but I don't think that's really the right thing to do. The distribution of warnings is as follows: 4 accessibility 24 archive 90 auth 707 awt 61 beans 7 crypto 128 jndi 206 luni 10 luni-kernel 4 misc 8 nio 7 nio_char 32 prefs 17 regex 260 rmi 568 security 936 swing 26 text 14 x-net Regards, Mark. - 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] -- 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: [drlvm] Doing the minimum to support Java 5 classfiles
This sounds easy and fun. What's the first thing we do? geir Rana Dasgupta wrote: Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [classlib] Merging frameworks for testing serialization - first step
Hi,
I've updated framework for testing serialization page[1] - I added guidelines
for developing serialization tests. Also I've removed confusing 'TestCase'
parameter in SerializationTest.verifySelf() methods.
If there are no objections I'm going in next two days to move
SerializationTest.java from 'security' module to support folder. So new
location will be:
support/src/test/java/org/apache/harmony/testframework/serialization folder.
Class name won't change.
Thoughts?
Thanks,
Stepan.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
On 6/20/06, Stepan Mishura wrote:
Hi,
I'm going to start merging existing frameworks for testing serialization.
As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates requirement
to extend SerializationTest. Also to provide smooth frameworks merging I've
put stub to let the framework search resources in the 'old' way ( i.e. via
RESOURCE_DIR system property). The stub will be removed after completing
the merge.
The updated framework suggests the following way for testing
serialization:
a) Compatibility – 4 new static methods are introduced.
verifyGolden(TestCase, Object)
verifyGolden(TestCase, Object, SerializableAssert)
verifyGolden(TestCase, Object[])
verifyGolden(TestCase, Object[], SerializableAssert)
A test should invoke one of above methods, for example,
public void testCompatibility() throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass ());
}
b) Self-testing: the same as for compatibility – there are 4 new static
methods that should be invoked from a test:
verifySelf(TestCase, Object)
verifySelf(Object, SerializableAssert)
verifySelf(TestCase, Object[])
verifySelf(Object[], SerializableAssert)
For example,
public void testSelf() throws Exception {
SerializationTest.verifySelf(new SomeSerializableClass(), new
MyComparator());
}
To complete frameworks merging I'd like to suggest the next steps:
2) Reviewing the update and the suggested way for testing serialization by
the community. Please let me know if it is acceptable and what can be
improved.
3) Replace SerializationTester class with SerializationTest. I'm going to
add more stubs to let existing tests work in the 'old' way.
4) Adjusting existing serialization tests (moving and renaming resource
files, replacing stubs invocation with new methods)
5) Removing stubs.
Thanks,
Stepan Mishura
Intel Middleware Products Division
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416477 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni: ./ src/main/java/java/net/ src/test/java/tests/api/java/net/
Hi Stepan, Maybe it needs configure /etc/hosts ? I'm not sure. I configured the host file on windows, the test passes. :) Thanks! On 6/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, InetAddressTest and SocketPermissionTest still fails for me on Linux. For example, InetAddressTest.test_getAllByNameLjava_lang_String failed with: Incorrect number of aliases returned: 2 should be 1 junit.framework.AssertionFailedError: Incorrect number of aliases returned: 2 should be 1 at tests.api.java.net.InetAddressTest.test_getAllByNameLjava_lang_String ( InetAddressTest.java:165) at java.lang.reflect.AccessibleObject.invokeV( AccessibleObject.java:205) Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 4:36 AM To: [EMAIL PROTECTED] Subject: svn commit: r416477 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni: ./ src/main/java/java/net/ src/test/java/tests/api/java/net/ Author: gharley Date: Thu Jun 22 14:36:24 2006 New Revision: 416477 URL: http://svn.apache.org/viewvc?rev=416477view=rev Log: Liberate ServerSocketTest, InetAddressTest and SocketPermissionTest from the excludes list. Fix up a couple of bugs in InetAddressTest. Remove a couple of duplicate entries in tests.api.java.net.AllTests suite. Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/ServerSocket.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/net/AllTests.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/net/InetAddressTest.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/net/ServerSocketTest.java Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml?rev=416477r1=416476r2=416477view=diff == SNIP -- Thanks, Stepan Mishura 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] -- Andrew Zhang China Software Development Lab, IBM
Re: svn commit: r416477 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni: ./ src/main/java/java/net/ src/test/java/tests/api/java/net/
Tests failed for me (and the linux build machine) with: Incorrect host name returned: localhost.localdomain != localhost junit.framework.AssertionFailedError: Incorrect host name returned: localhost.localdomain != localhost at tests.api.java.net.InetAddressTest.test_getHostName(InetAddressTest.java:238) Because the standard Debian installation defines 127.0.0.1 to be localhost.localdomain. I think the tests need to be more accommodating people aren't going to want to have to mess about with these system configurations. -Mark. On 23 June 2006 at 13:14, Andrew Zhang [EMAIL PROTECTED] wrote: --=_Part_22520_3761084.1151039694395 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Stepan, Maybe it needs configure /etc/hosts ? I'm not sure. I configured the host file on windows, the test passes. :) Thanks! On 6/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, InetAddressTest and SocketPermissionTest still fails for me on Linux. For example, InetAddressTest.test_getAllByNameLjava_lang_String failed with: Incorrect number of aliases returned: 2 should be 1 junit.framework.AssertionFailedError: Incorrect number of aliases returned: 2 should be 1 at tests.api.java.net.InetAddressTest.test_getAllByNameLjava_lang_String ( InetAddressTest.java:165) at java.lang.reflect.AccessibleObject.invokeV( AccessibleObject.java:205) Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 4:36 AM To: [EMAIL PROTECTED] Subject: svn commit: r416477 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni: ./ src/main/java/java/net/ src/test/java/tests/api/java/net/ Author: gharley Date: Thu Jun 22 14:36:24 2006 New Revision: 416477 URL: http://svn.apache.org/viewvc?rev=416477view=rev Log: Liberate ServerSocketTest, InetAddressTest and SocketPermissionTest from the excludes list. Fix up a couple of bugs in InetAddressTest. Remove a couple of duplicate entries in tests.api.java.net.AllTests suite. Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n et/ServerSocket.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/ api/java/net/AllTests.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/ api/java/net/InetAddressTest.java incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/ api/java/net/ServerSocketTest.java Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modu les/luni/build.xml?rev=416477r1=416476r2=416477view=diff === === SNIP -- Thanks, Stepan Mishura 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] -- Andrew Zhang China Software Development Lab, IBM --=_Part_22520_3761084.1151039694395-- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
