Re: Location for API extensions
> I have an example. Security2 has implementation of ASN.1 that is internal > stuff but has its own value. And it has a document for developers > who might use that internal stuff jre-independent. Thank you, Mikhail. I wanted to give some example from sequrity module, but was not sure since I'm really not an expert in this area. Thank you for doing that. As I told initially, nobody said we are going to develop something specially to extend API, but if some functionality was created anyway (as part of API development) why not to share it with others? All these classes will be included into harmony anyway; the only question is how to locate them to clearly define what might have a value and what is internal implementation only. Talking about the structure of such 'utility libraries' (ok, I see nobody like the word 'extension' :-) ) I think (thanks to Tim) that eclipse approach looks promising... -- Anton Avtamonov, Intel Middleware Products Division
Re: Which applications run using Harmony classes?
That will be a good tool! > The next step would be to check how many of these exist in SVN already > - and maybe highlight the areas that we are missing? So far, the only > way I have found to get a list of files that exist in SVN is using > something like "svn list $repos_path -R", if anyone knows of a better > (faster) way I'd be happy to hear it. You can also use reflection for checking for class availability. IMHO it will be an easiest way if we will keep modularity in mind. -- Alexey A. Petrenko Intel Middleware Products Division
[jira] Commented: (HARMONY-83) java.net.URL(String, String, int port, String) throws MalformedURLException when port is > 65535
[
http://issues.apache.org/jira/browse/HARMONY-83?page=comments#action_12365854 ]
Svetlana Samoilenko commented on HARMONY-83:
Tim , thank you, I agree with your fix.
Verified on revision 376452.
> java.net.URL(String, String, int port, String) throws MalformedURLException
> when port is > 65535
>
>
> Key: HARMONY-83
> URL: http://issues.apache.org/jira/browse/HARMONY-83
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Priority: Minor
>
> According to the j2se 1.4 and 1.5 specification constructor
> java.net.URL(String, String, int port, String) throws
> MalformedURLException - if an unknown protocol is specified.
> Harmony throws the exception if protocol is correct but a port out of range
> that contradicts specification.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
>try {
>new URL("http", "google.com", 1093812784, "file" );
>System.out.println("Test passed");
>} catch (MalformedURLException e) {
>e.printStackTrace();
>}
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> Test passed
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.net.MalformedURLException: Port out of range: 1093812784
> at java.net.URL.(URL.java:382)
> at java.net.URL.(URL.java:356)
> at test2.main(test2.java:6)
> Suggested fix in attachment.
> Suggested junit test case:
> URLTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class URLTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLTest.class);
> }
> public void test_constructor () {
> try {
>new URL("http", "google.com", 1093812784, "file" );
>} catch (MalformedURLException e) {
> fail("unexpected MalformedURLException");
>}
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-86) java.util.zip.Inflater.needsDictionary() throws unspecified IllegalStateException
java.util.zip.Inflater.needsDictionary() throws unspecified
IllegalStateException
-
Key: HARMONY-86
URL: http://issues.apache.org/jira/browse/HARMONY-86
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to the j2se 1.4 and 1.5 specification java.util.zip.needsDictionary()
method must not throw any exception.
Harmony throws unspecified IllegalStateException that contradicts specification.
Code to reproduce:
import java.util.zip.*;
public class test2 {
public static void main(String args[]) {
Inflater inf = new Inflater();
System.out.println("Inflater.needsDictionary() =
"+inf.needsDictionary());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
> javac -d . test2.java
3. Run java using compatible VM (J9)
> java -showversion test2
Output:
C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
Inflater.needsDictionary() = true
C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IllegalStateException
at java.util.zip.Inflater.needsDictionary(Inflater.java:212)
at test2.main(test2.java:8)
Siggested fix: to remove the lines in needsDictionary() method in
archive/src/main/java/java/util/zip/Inflater.java :
211 if (inputBuffer == null)
212throw new IllegalStateException();
Suggested junit test case:
InflaterTest.java
-
import java.util.zip.*;
import junit.framework.*;
public class InflaterTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InflaterTest .class);
}
public void test_needsDictionary () {
Inflater inf = new Inflater();
assertFalse(inf.needsDictionary());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
>
> Stepan Mishura wrote:
> > Hi Geir,
> >
> >> For the record, I put the jvmarg line back - I did some test class
> >> renaming, and things broke! I put it back, and all is well. Dunno.
> >> Leaving there so it doesn't break anyone else. Will continue to chase
> >> down after dinner
> >>
> >
> > crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
> > make/build.xml) and they are absent in Harmony boot
> (deploy/jre/lib/boot)
> > directory. So the build script from 'security2' builds them and places
> > explicitly to the bootclasspath.
>
>
> Then this is wrong then, correct? We should put putting crypto.jar and
> x_net.jar into the bootclasspath?
As I understood you removed only jvmarg line but didn't update ant script to
copy generated jar files. So tests failed. Right?
The question was how to put required jars in jre/lib/boot directory. A fast
solution was to copy jars generated with local make file in security2/make.
And a right solution is to adjust 'security2' to common build structure (i.e.
make/build.xml) as you did for 'x-net' component. I reviewed your update for
x-net and I'm ok with it.
I think the similar can be done for 'security-x'. As there are no objections
for creating the new component I can create a JIRA task for extracting
'security-x' from 'security2'. And provide a patch for it by analogy with
extracting 'x-net'.
What do you think?
Thanks,
Stepan Mishura
Intel Middleware Products Division
>
> > If you remove jvmarg line then you need to update additionally
> > make/build.xml or the build script from 'security2' to put these jars to
> > Harmony boot directory.
>
> Yes - I think that is the sensical way to go as we do want them there,
> right?
>
> >
> > I think that we should work out some kind of 'transition procedure' for
> > substituting security with security2 to be sure that we don't miss
> anything
> > and we are consistent. The first step may be extracting x-net component
> > because it is quite independent.
>
> Don't mix the issues. Right now, no modules/security code is being built.
>
> So - first - any problem with crypto and x_net into bootclasspath?
>
> geir
>
> >
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
> >
> > On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >> For the record, I put the jvmarg line back - I did some test class
> >> renaming, and things broke! I put it back, and all is well. Dunno.
> >> Leaving there so it doesn't break anyone else. Will continue to chase
> >> down after dinner
> >>
> >>
> >> Geir Magnusson Jr wrote:
> >>> I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
> >>> issue.
> >>>
> >>> However, there was a small thing that bugged me. We were setting the
> >>> bootclasspath as follows :
> >>>
> >>> >>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator
> >> }${build.jars.path}/x_net.jar"/>
> >>>
> >>> which has 2 of the 3 artifacts generated by security2 coming from the
> >>> local modules/security2 tree, and the third, security.jar, coming from
> >>> deploy/jre/lib/boot. This isn't healthy.
> >>>
> >>> So I just removed the above line, and now we depend on all three jars
> >>> coming from the same place, namely the deploy boot classpath.
> >>>
> >>> I only feel strongly that we are consistent. We can change from
> deploy/
> >>> to modules/security2 if we need to.
> >>>
> >>> I suspect this will be fine, but it does mean that working in
> >>> modules/security2 means that you need to go to top level to re-run the
> >>> build to get the jars in the right place.
> >>>
> >>> I think I'll change the local make in modules/security2 to also copy
> the
> >>> generated jars to ../../deploy/jre/lib/boot/
> >>>
> >>>
> >>> That way, you can work locally and still do the proper testing w/o
> >>> having to out of the module you are working in. I suspect that this
> >>> will be a pattern we repeat in all modules.
> >>>
> >>> geir
> >>>
> >>>
> >
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: Location for API extensions
Agreed And if we have some internal classes that users could benefit from then we may provide usage examples or even tools that utilize those classes. I have an example. Security2 has implementation of ASN.1 that is internal stuff but has its own value. And it has a document for developers who might use that internal stuff jre-independent. Thanks, Mikhail Loenko Intel Middleware Products Division On 2/10/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Matt Benson wrote: > > --- Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > >> > >> Anton Avtamonov wrote: > >>> Besides, such approach ties them to Harmony if > >> they found such > >>> extensions (funtionality, included into packages > >> of 'public access') > >>> useful :-) > >> We actually don't want to tie anyone into Harmony > >> other than because > >> we're free, fast, stable, etc. > >> > >> This project *may* at some point offer packages that > >> are not part of > >> J2SE (for example, if we had built a nice logging > >> implementation that > >> was resuable), but that would clearly be separate > > > > AND JRE-INDEPENDENT > > Indeed. Right. Exactly. > > geir > > > > >> parts of the project, > >> and not to be confused with Harmony the J2SE > >> Implementation. > >> > > > > -$0.02 -Matt > > > >> geir > >> > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > >
Re: FYI missing mail
On 2/10/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
>
> Tim Ellison wrote:
> > George Harley wrote:
> >
> >> The post I want to refer to does not seem to be in the
> >> mailing list archive (!!??!)
> >
> > I don't remember you saying that (and I would have remembered such an
> > eloquent and considered post ;-) )
>
> I didn't get it either, and as he George said, it's not in the archive.
>
> If anyone got it, can you let us know here (and once someone says they
> got it, everyone else stop telling us - we just need to know if anyone
> got it...)
I got it. I thought it was done intentionally: George sent it directly to me
only ... so it is not in the list.
Returning back to the 'missing post'. I agreed with suggestion but currently
we don't have Harmony provider so we should define how we locate 'trusted
provides' to be secure.
Thanks,
Stepan Mishura
Intel Middleware Products Division
geir
>
> >
> > I still have mail that far back in my reader, and it looks like I didn't
> > get it either. Maybe it never hit the list.
> >
> > p.s. +1 to the comment BTW
> >
> > Regards,
> > Tim
> >
> >> so let me copy the relevant text in-line
> >> here as I believe that what it says is important :
> >>
> >> --- snip from dev-list append of 1st Feb 2006 by
> >> [EMAIL PROTECTED] ---
> >>
> >> Just to clarify your clarification of the question of current Harmony
> >> behaviour ...
> >>
> >> (A) With the current Harmony build it looks like there is *no attempt*
> >> to verify the signature of a signed jar file that has been placed on
> the
> >> bootclasspath. I know this because I took a signed BC provider jar (as
> >> downloaded from http://www.bouncycastle.org), deliberately tampered
> with
> >> the .SF file in the META-INF folder by removing a few lines, then added
> >> the modified jar to the bootclasspath of a simple program that listed
> >> the algorithms supported by the BC provider. Everything worked fine.
> >>
> >> (B) With the current Harmony build it looks like an attempt is made at
> >> verifying the signature of a signed jar in the jre/lib/ext directory.
> >> The attempt fails because it involves trying to use functionality
> >> exported by the jar currently being verified and so opens up a whole
> >> problem with cycles.
> >> To my mind, (B) is a definite bug that would be fixed by having a
> >> default Harmony provider. The result of my little bit of playing with
> >> (A) just reinforces the argument that relying on the bootclasspath to
> >> load your third party providers is not er ... secure.
> >>
> >>
> >> --- end of snip from dev-list append of 1st Feb 2006 by
> >> [EMAIL PROTECTED] ---
> >>
> >>
> >> Best regards,
> >> George
> >> IBM UK
> >>
> >>
> >> Geir Magnusson Jr wrote:
> >>>
> >>> Tim Ellison wrote:
> Arghhh!
>
> make it stop
>
> > From below:
> -Xbootclasspath/a:${build.path}/tests${path.separator}${
> env.CLASSPATH}
>
>
> putting the CLASSPATH onto the bootclasspath. What are you smokin'
> ?!
> >>> That was the patch :)
> >>>
> >>> All that really is supposed to do is get junit and bcprov there. I'll
> >>> move.
> >>>
> >>> geir
> >>>
>
> [ I know you are fixing this stuff, but I needed to vent ]
>
>
> Original Message
> Subject: svn commit: r376144 -
>
> /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>
> Date: Thu, 09 Feb 2006 01:44:21 -
> From: [EMAIL PROTECTED]
> Reply-To: harmony-dev@incubator.apache.org
> To: [EMAIL PROTECTED]
>
> Author: geirm
> Date: Wed Feb 8 17:44:19 2006
> New Revision: 376144
>
> URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
> Log:
> put the bootclasspath stuff back for classlib tests
> because as I'm renaming some tests, it appears that
> when things reordered, tests broke. On a lark, I put
> it back, and things work. Scary.
>
> Will investigate further, but wanted to fix so tests run
>
> Also, changed one of the exclusion lists due to renaming.
>
>
> Modified:
>
>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>
>
> Modified:
>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>
> URL:
>
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
>
>
> ==
>
> ---
>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>
> (original)
> +++
>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>
> Wed Feb 8 17:44:19 2006
> @@ -499,6 +499,8 @@
>
>
>
> + value="-Xbootc
Re: Location for API extensions
As it said before it is not a good idea to positioning any Harmony classes as "extension for the standard API". However we can think about creating some standalone utilities library. But there are a lot of questions. For example what structure and content should such library have. What classes used in Harmony modules we should include and what classes we should not include. It's obvious that library which simply consists of classes used by different developers in different places will look like trash can but not like useful library. From other hand if we are talking about using these useful classes only inside Harmony then it's probably a good idea. But we need some procedure for moving a class to utilities package and we need to notify developers about class capabilities. -- Alexey A. Petrenko Intel Middleware Products Division
[jira] Created: (HARMONY-85) java.util.jar.Attributes.Name(String name) does not throw IllegalArgumentException if name.length > 70
java.util.jar.Attributes.Name(String name) does not throw
IllegalArgumentException if name.length > 70
--
Key: HARMONY-85
URL: http://issues.apache.org/jira/browse/HARMONY-85
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to j2se 1.4.2 and 1.5 specification for Attributes.Name(String name)
a string length cannot exceed 70 characters.
Harmony does not throw IllegalArgumentException if name.length > 70.
Code to reproduce: import java.util.jar.*;
public class test2 {
public static void main(String args[]) throws Exception {
try {
//no more than 70 chars in attribute name allowed
new Attributes.Name(
"01234567890123456789012345678901234567890123456789012345678901234567890");
System.out.println("Failed. Should be IllegalArgumentException ");
} catch(IllegalArgumentException e) {
System.out.println("Expected IllegalArgumentException");
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
> javac -d . test2.java
3. Run java using compatible VM (J9)
> java -showversion test2
Output:
C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
Expected IllegalArgumentException
C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Failed. Should be IllegalArgumentException
Siggested fix:
@@ -84,7 +84,7 @@
public Name(String s) {
int i = s.length();
- if (i == 0)
+ if (i == 0 || i> 70)
throw new IllegalArgumentException();
for (; --i >= 0;) {
char ch = s.charAt(i);
Suggested junit test case:
AttributesTest.java
-
import java.util.jar.*;
import junit.framework.*;
public class AttributesTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(AttributesTest.class);
}
public void test_constructor () {
try {
new Attributes.Name(
"01234567890123456789012345678901234567890123456789012345678901234567890");
fail("Should be IllegalArgumentException");
} catch(IllegalArgumentException e) {
//expected
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (HARMONY-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
As I commented in the JIRA, further study shows some interesting facts,
first, my prior patch is redundant, the actual bug is
http://issues.apache.org/jira/browse/HARMONY-84.
second, there is another different behavior of getHostName() between RI
and Harmony, but I consider it as RI's bug:
The java spec of getHostName() says:
*
Returns: *the host name for this IP address, or if the operation is not
allowed by the security check, the textual representation of the IP address.
But the following test shows RI will return host name instead of IP
address if the host name can be got without reverse name lookup.
public class HostNameTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName("localhost");
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0,
0, 1});
SecurityManager sm = new Inet_SecurityManager();
System.setSecurityManager(sm);
System.out.println(addr.getHostName());
System.out.println(addr2.getHostName());
}
static class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
}
RI outputs:
localhost
127.0.0.1
Harmony outputs:
127.0.0.1
127.0.0.1
This time, Harmony win :-D .
Geir Magnusson Jr wrote:
isn't "localhost" actually something in the local hosts file? Don't
you want to look this up?
Paulex Yang (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-73?page=all ]
Paulex Yang updated HARMONY-73:
---
Attachment: InetAddress.patch
A suggested modification is to add these two lines before Ln. 296 of
java.net.InetAddress,
if(this == LOOPBACK){
return "localhost";
}
So that the getHostName() will return "localhost" instead of
"127.0.0.1".
The patch is attached.
java.net.InetAddress.getLocalHost() returns wrong host name for
loopback address
-
Key: HARMONY-73
URL: http://issues.apache.org/jira/browse/HARMONY-73
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Priority: Minor
Attachments: InetAddress.patch
J2se 1.4.2 and 5.0 specifications for
java.net.InetAddress.getLocalHost() read, that if there is a
security manager, its checkConnect method is called with the local
host name and -1 as its arguments to see if the operation is
allowed. If the operation is not allowed, an InetAddress
representing the loopback address is returned as
hostname/hostaddress (as followed from toString() specification).
The test listed below shows that the returned loopback address has
wrong hostname, "127.0.0.1" instead of "loopback".
Inet_SecurityManager class is called twice and therefore host name
is substituted with hostaddress address.
Code to reproduce: import java.net.*; public class test2 {
public static void main(String[] args) { try {
System.setSecurityManager(new Inet_SecurityManager());
System.out.println("Loopback address = " +
InetAddress.getLocalHost());
} catch (Exception e){
System.out.println("Unexpected exception = " + e); }; }
} class Inet_SecurityManager extends SecurityManager { public
void checkConnect(String host, int port) {
super.checkConnect(host,port); throw new SecurityException();
}
}
Steps to Reproduce: 1. Build Harmony (check-out on 2006-01-30) j2se
subset as described in README.txt. 2. Compile test2.java using BEA
1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output: C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion
test2 java version "1.4.2_04" Java(TM) 2 Runtime Environment,
Standard Edition (build 1.4.2_04-b05) BEA WebLogic JRockit(TM)
1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native
Threads, GC strategy: parallel) Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Loopback address = localhost/127.0.0.1
C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2 (c)
Copyright 1991, 2005 The Apache Software Foundation or its
licensors, as applicable. Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Inet_SecurityManager :host= localhost
Inet_SecurityManager :port= -1
Loopback address = 127.0.0.1/127.0.0.1
Suggested junit test case:
InetAddressTest.java
- import java.net.*;
import junit.framework.*; public class InetAddressTest extends
TestCase { public static void main(String[] args) {
junit.textui.TestRunner.run(InetAddress.class); } public
void test_getLocalHost() { try{
System.setSecurityManager(new Inet_SecurityManager());
String h
[jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
[
http://issues.apache.org/jira/browse/HARMONY-71?page=comments#action_12365851 ]
Svetlana Samoilenko commented on HARMONY-71:
Verified on revision 376014. Expected IllegalStateException exception is thrown.
Thanks.
> java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
> --
>
> Key: HARMONY-71
> URL: http://issues.apache.org/jira/browse/HARMONY-71
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
>
> According to j2se 1.4.2 specification method
> java.net.URLConnection.setUseCaches(boolean) throws IllegalStateException, if
> already connected. Harmony throws java.lang.IllegalAccessError instead, that
> contradicts the specification.
> Code to reproduce:
> import java.io.IOException;
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
> HttpURLConnection u=null;
> try {
> u=(HttpURLConnection)(new
> URL("http://intel.com";).openConnection());
> u.connect();
> } catch (MalformedURLException e) {
> System.out.println("unexpected MalformedURLException"+e);
>
> } catch (IOException f) {
> System.out.println("unexpected IOException"+f);
> }
> try {
>u.setUseCaches(true);
> } catch (IllegalStateException e) {
>System.out.println("OK. Expected IllegalStateException");
>e.printStackTrace();
> };
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> OK. Expected IllegalStateException
> java.lang.IllegalStateException: Already connected
> at java.net.URLConnection.setUseCaches(Z)V(URLConnection.java:828)
> at test2.main([Ljava.lang.String;)V(test2.java:17)
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.lang.IllegalAccessError: Connection already established
> at java.net.URLConnection.setUseCaches(URLConnection.java:923)
> at test2.main(test2.java:17)
> Suggested junit test case:
> URLConnectionTest.java
> -
> import java.io.IOException;
> import java.net.*;
> import junit.framework.*;
> public class URLConnectionTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLConnectionTest.class);
> }
> public void test_setUseCaches () {
> HttpURLConnection u=null;
> try {
> u=(HttpURLConnection)(new
> URL("http://intel.com";).openConnection());
> u.connect();
> } catch (MalformedURLException e) {
> fail("unexpected MalformedURLException"+e);
> } catch (IOException f) {
> fail("unexpected IOException"+f);
> }
> try {
>u.setUseCaches(true);
> } catch (IllegalStateException e) { //expected
> };
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-72) java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified SecurityException
[
http://issues.apache.org/jira/browse/HARMONY-72?page=comments#action_12365848 ]
Svetlana Samoilenko commented on HARMONY-72:
Verified on revision 376014. Expected IllegalStateException exception is thrown.
Thanks.
> java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified
> SecurityException
> ---
>
> Key: HARMONY-72
> URL: http://issues.apache.org/jira/browse/HARMONY-72
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
>
> According to j2se 1.4.2 spec
> java.net.URLConnection.setAllowUserInteraction(boolean) throws
> IllegalStateException - if already connected.
> Harmony throws java.lang.SecurityException instead.
> Code to reproduce:
> import java.io.IOException;
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
> HttpURLConnection u=null;
> try {
> u=(HttpURLConnection)(new
> URL("http://intel.com";).openConnection());
> u.connect();
> } catch (MalformedURLException e) {
> System.out.println("unexpected MalformedURLException"+e);
>
> } catch (IOException f) {
> System.out.println("unexpected IOException"+f);
> }
> try {
> u.setAllowUserInteraction(false);
> } catch (IllegalStateException e) {
> System.out.println("OK. Expected IllegalStateException");
> e.printStackTrace();
> };
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> OK. Expected IllegalStateException
> java.lang.IllegalStateException: Already connected
> at
> java.net.URLConnection.setAllowUserInteraction(Z)V(URLConnection.java:765)
> at test2.main([Ljava.lang.String;)V(test2.java:16)
> at test2.main([Ljava.lang.String;)V(test2.java:18)
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.lang.SecurityException: Connection already established
> at
> java.net.URLConnection.setAllowUserInteraction(URLConnection.java:736)
> at test2.main(test2.java:18)
> Suggested junit test case:
> URLConnectionTest.java
> -
> import java.io.IOException;
> import java.net.*;
> import junit.framework.*;
> public class URLConnectionTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLConnectionTest.class);
> }
> public void test_setUseCaches () {
> HttpURLConnection u=null;
> try {
> u=(HttpURLConnection)(new
> URL("http://intel.com";).openConnection());
> u.connect();
> } catch (MalformedURLException e) {
> fail("unexpected MalformedURLException"+e);
> } catch (IOException f) {
> fail("unexpected IOException"+f);
> }
> try {
> u.setAllowUserInteraction(false);
> } catch (IllegalStateException e) { //expected
> };
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-82) wrong signature for 2 constructors in java.net.DatagramPacket
[ http://issues.apache.org/jira/browse/HARMONY-82?page=comments#action_12365845 ] Svetlana Samoilenko commented on HARMONY-82: Verified on revision 376009. Two constrictors have correct sinhature. Thanks. > wrong signature for 2 constructors in java.net.DatagramPacket > - > > Key: HARMONY-82 > URL: http://issues.apache.org/jira/browse/HARMONY-82 > Project: Harmony > Type: Bug > Reporter: Svetlana Samoilenko > Assignee: Tim Ellison > Priority: Minor > > According to j2se 1.4.2 and 1.5 specification > java.net.DatagramPacket.(byte[], int, int, java.net.SocketAddress) and > java.net.DatagramPacket.(byte[], int, java.net.SocketAddress) must throw > SocketException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Because distributing software under the GPL is a non-starter for us. Anthony Green wrote: On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need "all the tooling"? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG
[jira] Commented: (HARMONY-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
[
http://issues.apache.org/jira/browse/HARMONY-73?page=comments#action_12365843 ]
Paulex Yang commented on HARMONY-73:
Further study shows that the prior patch is not needed, in fact, my proposed
fix for issue 84 (http://issues.apache.org/jira/browse/HARMONY-84) is enough to
fix this issue as by product.
> java.net.InetAddress.getLocalHost() returns wrong host name for loopback
> address
> -
>
> Key: HARMONY-73
> URL: http://issues.apache.org/jira/browse/HARMONY-73
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Priority: Minor
> Attachments: InetAddress.patch
>
> J2se 1.4.2 and 5.0 specifications for java.net.InetAddress.getLocalHost()
> read, that if there is a security manager, its checkConnect method is called
> with the local host name and -1 as its arguments to see if the operation is
> allowed.
> If the operation is not allowed, an InetAddress representing the loopback
> address is returned as hostname/hostaddress (as followed from toString()
> specification).
> The test listed below shows that the returned loopback address has wrong
> hostname, "127.0.0.1" instead of "loopback".
> Inet_SecurityManager class is called twice and therefore host name is
> substituted with hostaddress address.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
> try {
> System.setSecurityManager(new Inet_SecurityManager());
> System.out.println("Loopback address = " +
> InetAddress.getLocalHost());
> } catch (Exception e){
> System.out.println("Unexpected exception = " + e);
> };
> }
> }
> class Inet_SecurityManager extends SecurityManager {
> public void checkConnect(String host, int port) {
> super.checkConnect(host,port);
> throw new SecurityException();
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> Inet_SecurityManager :host= nswssamoil1
> Inet_SecurityManager :port= -1
> Loopback address = localhost/127.0.0.1
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> Inet_SecurityManager :host= nswssamoil1
> Inet_SecurityManager :port= -1
> Inet_SecurityManager :host= localhost
> Inet_SecurityManager :port= -1
> Loopback address = 127.0.0.1/127.0.0.1
> Suggested junit test case:
> InetAddressTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class InetAddressTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(InetAddress.class);
> }
> public void test_getLocalHost() {
> try{
> System.setSecurityManager(new Inet_SecurityManager());
> String hostname=InetAddress.getLocalHost().getHostName();
>
> assertEquals("localhost", hostname);
> } catch (Exception e){
> fail("Unexpected exception = " + e);
> };
>}
> }
> class Inet_SecurityManager extends SecurityManager {
> public void checkConnect(String host, int port) {
> super.checkConnect(host,port);
> throw new SecurityException();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
I was wondering about this myself. I went and slogged through the epl and had trouble gathering exactly what the license restrictions were. From what I could tell, most of it was just disclaimer. What is the official apache stance on epl code? Jeremy On 9-Feb-06, at 11:48 PM, Anthony Green wrote: On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need "all the tooling"? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG
[jira] Commented: (HARMONY-84) java.net.InetAddress() shouldn't perform reverse name lookup
[
http://issues.apache.org/jira/browse/HARMONY-84?page=comments#action_12365837 ]
Paulex Yang commented on HARMONY-84:
A suggested simple fix is rewrite the toString() as below:
public String toString() {
return (hostName==null?"":hostName)+"/"+getHostAddress();
}
> java.net.InetAddress() shouldn't perform reverse name lookup
>
>
> Key: HARMONY-84
> URL: http://issues.apache.org/jira/browse/HARMONY-84
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Paulex Yang
> Priority: Minor
>
> Currently, the java.net.InetAddress.toString() is as below:
>
> public String toString() {
> return getHostName() + "/" + getHostAddress();
> }
>
> But actually the toString() should behave differently with getHostName()!
> the Java spec for toString():
>
> Converts this IP address to a String. The string returned is of the
> form: hostname / literal IP address. If the host name is unresolved, no
> reverse name service loopup is performed. The hostname part will be
> represented by an empty string.
>
> and the spec for getHostName() says:
>
> If this InetAddress was created with a host name, this host name will be
> remembered and returned; otherwise, a reverse name lookup will be performed
> and the result will be returned based on the system configured name lookup
> service.
>
> Spec shows that toString() shouldn't perform reverse name lookup while
> getHostName() should!
> A simple test show this bug:
>
> public class ToStringTest{
> public static void main(String[] args) throws Exception{
> InetAddress addr = InetAddress.getByName("localhost");
> System.out.println(addr);
> InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0,
> 1});
> System.out.println(addr2);
> }
> }
>
> on RI, it outputs:
> localhost/127.0.0.1
> /127.0.0.1
> and on Harmony, it outputs:
> localhost/127.0.0.1
> localhost/127.0.0.1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-84) java.net.InetAddress() shouldn't perform reverse name lookup
java.net.InetAddress() shouldn't perform reverse name lookup
Key: HARMONY-84
URL: http://issues.apache.org/jira/browse/HARMONY-84
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Minor
Currently, the java.net.InetAddress.toString() is as below:
public String toString() {
return getHostName() + "/" + getHostAddress();
}
But actually the toString() should behave differently with getHostName()!
the Java spec for toString():
Converts this IP address to a String. The string returned is of the
form: hostname / literal IP address. If the host name is unresolved, no reverse
name service loopup is performed. The hostname part will be represented by an
empty string.
and the spec for getHostName() says:
If this InetAddress was created with a host name, this host name will be
remembered and returned; otherwise, a reverse name lookup will be performed and
the result will be returned based on the system configured name lookup service.
Spec shows that toString() shouldn't perform reverse name lookup while
getHostName() should!
A simple test show this bug:
public class ToStringTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName("localhost");
System.out.println(addr);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0, 1});
System.out.println(addr2);
}
}
on RI, it outputs:
localhost/127.0.0.1
/127.0.0.1
and on Harmony, it outputs:
localhost/127.0.0.1
localhost/127.0.0.1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: > We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need "all the tooling"? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Lovely, that's exactly the kind of pointers that'll help me :) Another thing occurred to me this evening, and that is that xdoclet must be extremely similar to javadoc. I will have a poke around with that too and see if it isn't doable. Jeremy On 9-Feb-06, at 6:03 PM, Tim Ellison wrote: You may find it useful to take a look at the Eclipse Java AST APIs, http://help.eclipse.org/help31/index.jsp?topic=/ org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/ AST.html http://www-128.ibm.com/developerworks/opensource/library/os-ast/? ca=dgr-lnxw97ASTParser http://eclipsecon.org/2005/presentations/EclipseCON2005_Tutorial29.pdf ... specifically the javadoc node Regards, Tim Jeremy Huiskamp wrote: First the disclaimer: I have zero experience with writing such tools and precious little with compilers. I'm just spewing what I think but if there are accepted ways of doing these things, it'd be great for anyone to step in and school me. I'm here to learn, hopefully by contributing :) What I'm thinking (and maybe this is dead obvious) is that there are lots of high level tasks that javac and javadoc will have in common: -understanding and parsing the syntax of the language itself -the relevant parts of that are anything that you can javadoc: types, fields, methods... -the relation of classes in a package hierarchy, like when a method takes an @arg of type java.lang.String, you've got to resolve that and produce a link to the String javadoc -essentially having the ability to take a target dir and produce a walkable data structure of all it's contents Of course, it's not a perfect match. Javadoc needs to treat javadoc comments as different from other comments (not toss them) and it doesn't need to understand things at a level finer than, say, methods (doesn't need to know about if statements, loops, etc). But there's enough there that the javadoc front end could essentially be the javac frontend with the addition of handling the actual javadoc contents. Then, of course, the back end of the compiler spits out .class files while javadoc spits out html or whatever other format you need, but that's the reason for the separation between front and back ends :) What I could do is take the eclipse compiler and see what parts of it can be reused. I don't know anything about it so I won't offer any speculation now. Also, obviously eclipse has it's own javadoc functionality. Is that something that can be borrowed? Assuming the easy case, that the tools are all there for poaching with minimal work, what would the proper action be? It could be stated that harmony will use the eclipse tools and you should go get them from eclipse if you want them (at least for the time being, until harmony gets to the point of being packaged up as a useable jdk). I gather that's the current status of the compiler. Or harmony could host the currently accepted binaries. Or the source code could be taken into svn, in which case there's the question of keeping in sync with the original tool. In all likelihood, it won't be that simple and harmony will have some of it's own modifications... Having asked so many questions, I'm now expecting to be told that whatever I feel like doing will be better than nothing :-p I'm off to see what I can find out about the eclipse toolset. Jeremy On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote: Jeremy Huiskamp wrote: What would be the suggested route for coming up with a javadoc tool? Open up an editor, and start typing! :) Is there something out there now that could be imported and shaped up? At the other extreme, I'm envisioning busting out jflex/cup and doing a from-scratch implementation. I'm thinking there would be a lot of overlapping functionality with the front end of a compiler so should the two tools be considered together? Harmony doesn't have a start on it's own compiler yet, correct? We were planning to just use the eclipse compiler. No reason to rewrite. I guess the best thing to do is do a quick write-up on how you might go about this. Someone here must have some ideas to share too... geir Jeremy On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: running eclipse on Harmony classlib
Vladimir Strigun wrote: I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse you need to make following steps: - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from xml.apache.org and put it to deploy/jre/lib/boot/ - add next line to jre/lib/boot/bootclasspath.properties : bootclasspath.38=serializer.jar - download and build Intel contribution of beans, math and regex packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar org.eclipse.core.launcher.Main I've tried to create simple Java project and Hello class inside. Everything works fine without any exception or problems. Tim, in your movie I have seen new type for installed JRE in Eclipse: "Apache Harmony VM". Do you have Eclipse plugin for Harmony already? Holy cow, this is awesome! Have you tried with our own VM? -- Stefano.
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
You may find it useful to take a look at the Eclipse Java AST APIs, http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/AST.html http://www-128.ibm.com/developerworks/opensource/library/os-ast/?ca=dgr-lnxw97ASTParser http://eclipsecon.org/2005/presentations/EclipseCON2005_Tutorial29.pdf ... specifically the javadoc node Regards, Tim Jeremy Huiskamp wrote: > First the disclaimer: I have zero experience with writing such tools and > precious little with compilers. I'm just spewing what I think but if > there are accepted ways of doing these things, it'd be great for anyone > to step in and school me. I'm here to learn, hopefully by contributing :) > > What I'm thinking (and maybe this is dead obvious) is that there are > lots of high level tasks that javac and javadoc will have in common: > -understanding and parsing the syntax of the language itself > -the relevant parts of that are anything that you can javadoc: types, > fields, methods... > -the relation of classes in a package hierarchy, like when a method > takes an @arg of type java.lang.String, you've got to resolve that and > produce a link to the String javadoc > -essentially having the ability to take a target dir and produce a > walkable data structure of all it's contents > > Of course, it's not a perfect match. Javadoc needs to treat javadoc > comments as different from other comments (not toss them) and it doesn't > need to understand things at a level finer than, say, methods (doesn't > need to know about if statements, loops, etc). But there's enough there > that the javadoc front end could essentially be the javac frontend with > the addition of handling the actual javadoc contents. Then, of course, > the back end of the compiler spits out .class files while javadoc spits > out html or whatever other format you need, but that's the reason for > the separation between front and back ends :) > > What I could do is take the eclipse compiler and see what parts of it > can be reused. I don't know anything about it so I won't offer any > speculation now. Also, obviously eclipse has it's own javadoc > functionality. Is that something that can be borrowed? > > Assuming the easy case, that the tools are all there for poaching with > minimal work, what would the proper action be? It could be stated that > harmony will use the eclipse tools and you should go get them from > eclipse if you want them (at least for the time being, until harmony > gets to the point of being packaged up as a useable jdk). I gather > that's the current status of the compiler. Or harmony could host the > currently accepted binaries. Or the source code could be taken into > svn, in which case there's the question of keeping in sync with the > original tool. In all likelihood, it won't be that simple and harmony > will have some of it's own modifications... > > Having asked so many questions, I'm now expecting to be told that > whatever I feel like doing will be better than nothing :-p I'm off to > see what I can find out about the eclipse toolset. > > Jeremy > > On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote: > >> >> >> Jeremy Huiskamp wrote: >>> What would be the suggested route for coming up with a javadoc tool? >> >> Open up an editor, and start typing! :) >> >> Is >>> there something out there now that could be imported and shaped up? >>> At the other extreme, I'm envisioning busting out jflex/cup and doing >>> a from-scratch implementation. I'm thinking there would be a lot of >>> overlapping functionality with the front end of a compiler so should >>> the two tools be considered together? Harmony doesn't have a start >>> on it's own compiler yet, correct? >> >> We were planning to just use the eclipse compiler. No reason to rewrite. >> >> I guess the best thing to do is do a quick write-up on how you might >> go about this. Someone here must have some ideas to share too... >> >> geir >> >>> Jeremy >>> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Assigned: (HARMONY-76) some clean-up after HARMONY-55 fix is desired
[ http://issues.apache.org/jira/browse/HARMONY-76?page=all ] Tim Ellison reassigned HARMONY-76: -- Assign To: Geir Magnusson Jr A gift > some clean-up after HARMONY-55 fix is desired > - > > Key: HARMONY-76 > URL: http://issues.apache.org/jira/browse/HARMONY-76 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mikhail Loenko > Assignee: Geir Magnusson Jr > Priority: Minor > Attachments: patch.txt > > There is some noise from Eclipse that reports in security2 code things like > unused local variables, etc most of which appeared after H-55 massive fix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-83) java.net.URL(String, String, int port, String) throws MalformedURLException when port is > 65535
[ http://issues.apache.org/jira/browse/HARMONY-83?page=all ]
Tim Ellison resolved HARMONY-83:
Resolution: Fixed
Svetlana,
Your proposed fix is incorrect because tests show that 1.4 and 1.5 do throw the
exception for ports < -1.
Fixed in LUNI java.net.URL at repo revision 376452.
Please check that this fully resolves your problem.
> java.net.URL(String, String, int port, String) throws MalformedURLException
> when port is > 65535
>
>
> Key: HARMONY-83
> URL: http://issues.apache.org/jira/browse/HARMONY-83
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Priority: Minor
>
> According to the j2se 1.4 and 1.5 specification constructor
> java.net.URL(String, String, int port, String) throws
> MalformedURLException - if an unknown protocol is specified.
> Harmony throws the exception if protocol is correct but a port out of range
> that contradicts specification.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
>try {
>new URL("http", "google.com", 1093812784, "file" );
>System.out.println("Test passed");
>} catch (MalformedURLException e) {
>e.printStackTrace();
>}
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> Test passed
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.net.MalformedURLException: Port out of range: 1093812784
> at java.net.URL.(URL.java:382)
> at java.net.URL.(URL.java:356)
> at test2.main(test2.java:6)
> Suggested fix in attachment.
> Suggested junit test case:
> URLTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class URLTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLTest.class);
> }
> public void test_constructor () {
> try {
>new URL("http", "google.com", 1093812784, "file" );
>} catch (MalformedURLException e) {
> fail("unexpected MalformedURLException");
>}
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-83) java.net.URL(String, String, int port, String) throws MalformedURLException when port is > 65535
[ http://issues.apache.org/jira/browse/HARMONY-83?page=all ]
Tim Ellison updated HARMONY-83:
---
Summary: java.net.URL(String, String, int port, String) throws
MalformedURLException when port is > 65535 (was: java.net.URL(String, String,
int port, String) throws MalformedURLException when protocol is known)
> java.net.URL(String, String, int port, String) throws MalformedURLException
> when port is > 65535
>
>
> Key: HARMONY-83
> URL: http://issues.apache.org/jira/browse/HARMONY-83
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Priority: Minor
>
> According to the j2se 1.4 and 1.5 specification constructor
> java.net.URL(String, String, int port, String) throws
> MalformedURLException - if an unknown protocol is specified.
> Harmony throws the exception if protocol is correct but a port out of range
> that contradicts specification.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
>try {
>new URL("http", "google.com", 1093812784, "file" );
>System.out.println("Test passed");
>} catch (MalformedURLException e) {
>e.printStackTrace();
>}
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> Test passed
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.net.MalformedURLException: Port out of range: 1093812784
> at java.net.URL.(URL.java:382)
> at java.net.URL.(URL.java:356)
> at test2.main(test2.java:6)
> Suggested fix in attachment.
> Suggested junit test case:
> URLTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class URLTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLTest.class);
> }
> public void test_constructor () {
> try {
>new URL("http", "google.com", 1093812784, "file" );
>} catch (MalformedURLException e) {
> fail("unexpected MalformedURLException");
>}
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-83) java.net.URL(String, String, int port, String) throws MalformedURLException when protocol is known
[ http://issues.apache.org/jira/browse/HARMONY-83?page=all ]
Tim Ellison reassigned HARMONY-83:
--
Assign To: Tim Ellison
> java.net.URL(String, String, int port, String) throws MalformedURLException
> when protocol is known
> --
>
> Key: HARMONY-83
> URL: http://issues.apache.org/jira/browse/HARMONY-83
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Priority: Minor
>
> According to the j2se 1.4 and 1.5 specification constructor
> java.net.URL(String, String, int port, String) throws
> MalformedURLException - if an unknown protocol is specified.
> Harmony throws the exception if protocol is correct but a port out of range
> that contradicts specification.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
>try {
>new URL("http", "google.com", 1093812784, "file" );
>System.out.println("Test passed");
>} catch (MalformedURLException e) {
>e.printStackTrace();
>}
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> Test passed
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.net.MalformedURLException: Port out of range: 1093812784
> at java.net.URL.(URL.java:382)
> at java.net.URL.(URL.java:356)
> at test2.main(test2.java:6)
> Suggested fix in attachment.
> Suggested junit test case:
> URLTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class URLTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(URLTest.class);
> }
> public void test_constructor () {
> try {
>new URL("http", "google.com", 1093812784, "file" );
>} catch (MalformedURLException e) {
> fail("unexpected MalformedURLException");
>}
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Jeremy Huiskamp wrote: [snip] What I could do is take the eclipse compiler and see what parts of it can be reused. I don't know anything about it so I won't offer any speculation now. Also, obviously eclipse has it's own javadoc functionality. Is that something that can be borrowed? That's what I was about to suggest. Eclipse clearly groks javadoc. Why not see how that does it? Assuming the easy case, that the tools are all there for poaching with minimal work, what would the proper action be? It could be stated that harmony will use the eclipse tools and you should go get them from eclipse if you want them (at least for the time being, until harmony gets to the point of being packaged up as a useable jdk). I gather that's the current status of the compiler. Or harmony could host the currently accepted binaries. Or the source code could be taken into svn, in which case there's the question of keeping in sync with the original tool. In all likelihood, it won't be that simple and harmony will have some of it's own modifications... Having asked so many questions, I'm now expecting to be told that whatever I feel like doing will be better than nothing :-p I'm off to see what I can find out about the eclipse toolset. Whatever you feel like doing is better than nothing. Thanks for volunteering :) geir
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Hi Jeremy, Whatever you feel like doing will be better than nothing. (Sorry, I couldn't resist it) George IBM UK Jeremy Huiskamp wrote: First the disclaimer: I have zero experience with writing such tools and precious little with compilers. I'm just spewing what I think but if there are accepted ways of doing these things, it'd be great for anyone to step in and school me. I'm here to learn, hopefully by contributing :) What I'm thinking (and maybe this is dead obvious) is that there are lots of high level tasks that javac and javadoc will have in common: -understanding and parsing the syntax of the language itself -the relevant parts of that are anything that you can javadoc: types, fields, methods... -the relation of classes in a package hierarchy, like when a method takes an @arg of type java.lang.String, you've got to resolve that and produce a link to the String javadoc -essentially having the ability to take a target dir and produce a walkable data structure of all it's contents Of course, it's not a perfect match. Javadoc needs to treat javadoc comments as different from other comments (not toss them) and it doesn't need to understand things at a level finer than, say, methods (doesn't need to know about if statements, loops, etc). But there's enough there that the javadoc front end could essentially be the javac frontend with the addition of handling the actual javadoc contents. Then, of course, the back end of the compiler spits out .class files while javadoc spits out html or whatever other format you need, but that's the reason for the separation between front and back ends :) What I could do is take the eclipse compiler and see what parts of it can be reused. I don't know anything about it so I won't offer any speculation now. Also, obviously eclipse has it's own javadoc functionality. Is that something that can be borrowed? Assuming the easy case, that the tools are all there for poaching with minimal work, what would the proper action be? It could be stated that harmony will use the eclipse tools and you should go get them from eclipse if you want them (at least for the time being, until harmony gets to the point of being packaged up as a useable jdk). I gather that's the current status of the compiler. Or harmony could host the currently accepted binaries. Or the source code could be taken into svn, in which case there's the question of keeping in sync with the original tool. In all likelihood, it won't be that simple and harmony will have some of it's own modifications... Having asked so many questions, I'm now expecting to be told that whatever I feel like doing will be better than nothing :-p I'm off to see what I can find out about the eclipse toolset. Jeremy On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote: Jeremy Huiskamp wrote: What would be the suggested route for coming up with a javadoc tool? Open up an editor, and start typing! :) Is there something out there now that could be imported and shaped up? At the other extreme, I'm envisioning busting out jflex/cup and doing a from-scratch implementation. I'm thinking there would be a lot of overlapping functionality with the front end of a compiler so should the two tools be considered together? Harmony doesn't have a start on it's own compiler yet, correct? We were planning to just use the eclipse compiler. No reason to rewrite. I guess the best thing to do is do a quick write-up on how you might go about this. Someone here must have some ideas to share too... geir Jeremy On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir -- IBM UK
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
First the disclaimer: I have zero experience with writing such tools and precious little with compilers. I'm just spewing what I think but if there are accepted ways of doing these things, it'd be great for anyone to step in and school me. I'm here to learn, hopefully by contributing :) What I'm thinking (and maybe this is dead obvious) is that there are lots of high level tasks that javac and javadoc will have in common: -understanding and parsing the syntax of the language itself -the relevant parts of that are anything that you can javadoc: types, fields, methods... -the relation of classes in a package hierarchy, like when a method takes an @arg of type java.lang.String, you've got to resolve that and produce a link to the String javadoc -essentially having the ability to take a target dir and produce a walkable data structure of all it's contents Of course, it's not a perfect match. Javadoc needs to treat javadoc comments as different from other comments (not toss them) and it doesn't need to understand things at a level finer than, say, methods (doesn't need to know about if statements, loops, etc). But there's enough there that the javadoc front end could essentially be the javac frontend with the addition of handling the actual javadoc contents. Then, of course, the back end of the compiler spits out .class files while javadoc spits out html or whatever other format you need, but that's the reason for the separation between front and back ends :) What I could do is take the eclipse compiler and see what parts of it can be reused. I don't know anything about it so I won't offer any speculation now. Also, obviously eclipse has it's own javadoc functionality. Is that something that can be borrowed? Assuming the easy case, that the tools are all there for poaching with minimal work, what would the proper action be? It could be stated that harmony will use the eclipse tools and you should go get them from eclipse if you want them (at least for the time being, until harmony gets to the point of being packaged up as a useable jdk). I gather that's the current status of the compiler. Or harmony could host the currently accepted binaries. Or the source code could be taken into svn, in which case there's the question of keeping in sync with the original tool. In all likelihood, it won't be that simple and harmony will have some of it's own modifications... Having asked so many questions, I'm now expecting to be told that whatever I feel like doing will be better than nothing :-p I'm off to see what I can find out about the eclipse toolset. Jeremy On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote: Jeremy Huiskamp wrote: What would be the suggested route for coming up with a javadoc tool? Open up an editor, and start typing! :) Is there something out there now that could be imported and shaped up? At the other extreme, I'm envisioning busting out jflex/cup and doing a from-scratch implementation. I'm thinking there would be a lot of overlapping functionality with the front end of a compiler so should the two tools be considered together? Harmony doesn't have a start on it's own compiler yet, correct? We were planning to just use the eclipse compiler. No reason to rewrite. I guess the best thing to do is do a quick write-up on how you might go about this. Someone here must have some ideas to share too... geir Jeremy On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir
Re: FYI missing mail
Tim Ellison wrote:
George Harley wrote:
The post I want to refer to does not seem to be in the
mailing list archive (!!??!)
I don't remember you saying that (and I would have remembered such an
eloquent and considered post ;-) )
I didn't get it either, and as he George said, it's not in the archive.
If anyone got it, can you let us know here (and once someone says they
got it, everyone else stop telling us - we just need to know if anyone
got it...)
geir
I still have mail that far back in my reader, and it looks like I didn't
get it either. Maybe it never hit the list.
p.s. +1 to the comment BTW
Regards,
Tim
so let me copy the relevant text in-line
here as I believe that what it says is important :
--- snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Just to clarify your clarification of the question of current Harmony
behaviour ...
(A) With the current Harmony build it looks like there is *no attempt*
to verify the signature of a signed jar file that has been placed on the
bootclasspath. I know this because I took a signed BC provider jar (as
downloaded from http://www.bouncycastle.org), deliberately tampered with
the .SF file in the META-INF folder by removing a few lines, then added
the modified jar to the bootclasspath of a simple program that listed
the algorithms supported by the BC provider. Everything worked fine.
(B) With the current Harmony build it looks like an attempt is made at
verifying the signature of a signed jar in the jre/lib/ext directory.
The attempt fails because it involves trying to use functionality
exported by the jar currently being verified and so opens up a whole
problem with cycles.
To my mind, (B) is a definite bug that would be fixed by having a
default Harmony provider. The result of my little bit of playing with
(A) just reinforces the argument that relying on the bootclasspath to
load your third party providers is not er ... secure.
--- end of snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Best regards,
George
IBM UK
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Arghhh!
make it stop
From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
That was the patch :)
All that really is supposed to do is get junit and bcprov there. I'll
move.
geir
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+
+
@@ -518,7 +520,7 @@
-
+
Re: Location for API extensions
Matt Benson wrote: --- Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Anton Avtamonov wrote: Besides, such approach ties them to Harmony if they found such extensions (funtionality, included into packages of 'public access') useful :-) We actually don't want to tie anyone into Harmony other than because we're free, fast, stable, etc. This project *may* at some point offer packages that are not part of J2SE (for example, if we had built a nice logging implementation that was resuable), but that would clearly be separate AND JRE-INDEPENDENT Indeed. Right. Exactly. geir parts of the project, and not to be confused with Harmony the J2SE Implementation. -$0.02 -Matt geir __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Jeremy Huiskamp wrote: What would be the suggested route for coming up with a javadoc tool? Open up an editor, and start typing! :) Is there something out there now that could be imported and shaped up? At the other extreme, I'm envisioning busting out jflex/cup and doing a from-scratch implementation. I'm thinking there would be a lot of overlapping functionality with the front end of a compiler so should the two tools be considered together? Harmony doesn't have a start on it's own compiler yet, correct? We were planning to just use the eclipse compiler. No reason to rewrite. I guess the best thing to do is do a quick write-up on how you might go about this. Someone here must have some ideas to share too... geir Jeremy On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir
Harmony JRE plug-in for Eclipse (was: Re: running eclipse on Harmony classlib)
Vladimir Strigun wrote: > Just interesing: do you used standard eclipse VM runner and VM > debugger (I mean classes > org.eclipse.jdt.internal.launching.StandardVMRunner and > org.eclipse.jdt.internal.launching.StandardVMDebugger) in your plugin > ? gasp -- no. No internal stuff, just subclassing the AbstractVMRunner. > What types of VM's your plugin is supported? The plug-in doesn't much care about the VM, it's dealings are with the Harmony launcher and JRE layout. I did try to create a config that recognizes the -vmdir option of the launcher so I can switch kernel.jar but Eclipse JDT doesn't give me enough info to do that successfully. > Looks like that IBM VM > works well with standard runner and debugger, but if we want to > support other Harmony VM's then I think it will be necessary to make > own implementation of mentioned classes inside plugin. In this case, > runner and debugger can apply VM-specific options, for instance for > IBM VM and Jchevm. What VM-specific options did you have in mind? If they are options that are *always* set when creating a VM then they should be in JNI_CreateJavaVM so they are set in embedded VMs. If they are used when launching the VM, or you can't modify that code, you can put them in your VM properties file which is read by the launcher (e.g. for the IBM VM look in jre/bin/default/clearvm.properties). The launcher passes these through to the VM (see createVMArgs function in launcher/main.c code [1]). [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/launcher/main.c?view=markup Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
What would be the suggested route for coming up with a javadoc tool? Is there something out there now that could be imported and shaped up? At the other extreme, I'm envisioning busting out jflex/cup and doing a from-scratch implementation. I'm thinking there would be a lot of overlapping functionality with the front end of a compiler so should the two tools be considered together? Harmony doesn't have a start on it's own compiler yet, correct? Jeremy On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote: Ok - this isn't about the finer points of confusion surrounding documentation We need a javadoc tool for Harmony. The current conversation is a diversion from this, which I recall was the original motivation behind the current generation of this discussion. So, anyone interested? We need all the tooling actually... geir
FYI missing mail (was: Re: [Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml])
George Harley wrote:
> The post I want to refer to does not seem to be in the
> mailing list archive (!!??!)
I don't remember you saying that (and I would have remembered such an
eloquent and considered post ;-) )
I still have mail that far back in my reader, and it looks like I didn't
get it either. Maybe it never hit the list.
p.s. +1 to the comment BTW
Regards,
Tim
> so let me copy the relevant text in-line
> here as I believe that what it says is important :
>
> --- snip from dev-list append of 1st Feb 2006 by
> [EMAIL PROTECTED] ---
>
> Just to clarify your clarification of the question of current Harmony
> behaviour ...
>
> (A) With the current Harmony build it looks like there is *no attempt*
> to verify the signature of a signed jar file that has been placed on the
> bootclasspath. I know this because I took a signed BC provider jar (as
> downloaded from http://www.bouncycastle.org), deliberately tampered with
> the .SF file in the META-INF folder by removing a few lines, then added
> the modified jar to the bootclasspath of a simple program that listed
> the algorithms supported by the BC provider. Everything worked fine.
>
> (B) With the current Harmony build it looks like an attempt is made at
> verifying the signature of a signed jar in the jre/lib/ext directory.
> The attempt fails because it involves trying to use functionality
> exported by the jar currently being verified and so opens up a whole
> problem with cycles.
> To my mind, (B) is a definite bug that would be fixed by having a
> default Harmony provider. The result of my little bit of playing with
> (A) just reinforces the argument that relying on the bootclasspath to
> load your third party providers is not er ... secure.
>
>
> --- end of snip from dev-list append of 1st Feb 2006 by
> [EMAIL PROTECTED] ---
>
>
> Best regards,
> George
> IBM UK
>
>
> Geir Magnusson Jr wrote:
>>
>>
>> Tim Ellison wrote:
>>> Arghhh!
>>>
>>> make it stop
>>>
From below:
>>> -Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
>>>
>>>
>>> putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
>>
>> That was the patch :)
>>
>> All that really is supposed to do is get junit and bcprov there. I'll
>> move.
>>
>> geir
>>
>>>
>>>
>>> [ I know you are fixing this stuff, but I needed to vent ]
>>>
>>>
>>> Original Message
>>> Subject: svn commit: r376144 -
>>> /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>
>>> Date: Thu, 09 Feb 2006 01:44:21 -
>>> From: [EMAIL PROTECTED]
>>> Reply-To: harmony-dev@incubator.apache.org
>>> To: [EMAIL PROTECTED]
>>>
>>> Author: geirm
>>> Date: Wed Feb 8 17:44:19 2006
>>> New Revision: 376144
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
>>> Log:
>>> put the bootclasspath stuff back for classlib tests
>>> because as I'm renaming some tests, it appears that
>>> when things reordered, tests broke. On a lark, I put
>>> it back, and things work. Scary.
>>>
>>> Will investigate further, but wanted to fix so tests run
>>>
>>> Also, changed one of the exclusion lists due to renaming.
>>>
>>>
>>> Modified:
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>
>>>
>>> Modified:
>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>
>>> URL:
>>> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
>>>
>>> ==
>>>
>>> ---
>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>
>>> (original)
>>> +++
>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>
>>> Wed Feb 8 17:44:19 2006
>>> @@ -499,6 +499,8 @@
>>>
>>>
>>>
>>> +>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
>>>
>>> +
>>> >> value="-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}"/>
>>>
>>>
>>> >> value="-Djava.security.properties==${build.lib.path}/security/java.security"/>
>>>
>>> @@ -518,7 +520,7 @@
>>> >> name="org/apache/harmony/security/test/**"/>
>>>
>>> ->> name="java/security/AlgorithmParameterGeneratorTest1.java"/>
>>> +>> name="java/security/AlgorithmParameterGenerator1Test.java"/>
>>>
>>> >> name="java/security/KeyPairGeneratorTest1.java"/>
>>> >> name="java/security/KeyPairGeneratorTest3.java"/>
>>>
>>>
>>>
>>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: Location for API extensions
--- Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Anton Avtamonov wrote: > > Besides, such approach ties them to Harmony if > they found such > > extensions (funtionality, included into packages > of 'public access') > > useful :-) > > We actually don't want to tie anyone into Harmony > other than because > we're free, fast, stable, etc. > > This project *may* at some point offer packages that > are not part of > J2SE (for example, if we had built a nice logging > implementation that > was resuable), but that would clearly be separate AND JRE-INDEPENDENT > parts of the project, > and not to be confused with Harmony the J2SE > Implementation. > -$0.02 -Matt > geir > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jchevm] building jchevm on Cygwin
Archie Cobbs wrote:
What does this program print?
/*
* Compile me from the top jchevm directory like this:
*
* cc -I libjc -I include -I libjc/native -I libjc/arch -o xx xx.c
*/
#include "libjc.h"
int
main(int ac, char **av)
{
printf("_JC_FULL_ALIGNMENT=%u\n", _JC_FULL_ALIGNMENT);
return 0;
}
-Archie
Hi Archie,
here are the messages and the value of ALIGNMENT.
As far as the Classpath problem is concerned, I posted a thread on
the Classpath mailing list.
Keep in mind that I haven't yet merged your latest pacth (replacement
of the ucontext functions with setjmp() - longjmp). with my source tree.
assertion failure 1
-
vm.c - line 46
message = "assertion failure: _JC_FULL_ALIGNMENT <= (sizeof(_jc_word))"
When I add the following:
printf("_JC_FULL_ALIGNMENT=%u\n", _JC_FULL_ALIGNMENT);
jchevm prints: 8
assertion failure 2
-
vm.c - line 176
message = "assertion failure: vm->threads.pro_min <= assertion
failure:vm->threads.pro_max"
assertion failure 3
-
heap.c - line 238
message = "assertion failure: bs->hint == NULL || (((_jc_word) bs->hint
& (_JC_PAGE_SIZE - 1) %
bs->size) == _JC_HEAP_BLCOK_OFFSET)
assertion failure 4
-
thread.c - line 1023
/* _JC_COND_SIGNAL(vm->vm_destruction);*/
message = "assertion failure: _r == 0"
Your comments are welcome :-)
Enrico
[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
[
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12365756 ]
Vladimir Strigun commented on HARMONY-67:
-
Looks like duplicate of Harmony-33
> java.nio.charset.Charset.decode(ByteBuffer) throws unexpected
> BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
> ---
>
> Key: HARMONY-67
> URL: http://issues.apache.org/jira/browse/HARMONY-67
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
>
> According to j2se 1.4.2 specification for Charset.decode(ByteBuffer b) the
> method must not throw any exceptions.
> The test listed below shows that there is unexpected BufferOverflowException
> thrown if charset name is one in the following: UTF-16BE, UTF-16LE, UTF-16.
> BEA does not throw any exceptions.
> Code to reproduce:
> import java.nio.charset.Charset;
> import java.nio.ByteBuffer;
> import java.nio.CharBuffer;
> public class test2 {
> public static void main(String[] args) throws Exception {
> byte[] b = new byte[] {(byte)1};
> ByteBuffer buf= ByteBuffer.wrap(b);
> CharBuffer charbuf=Charset.forName("UTF-16").decode(buf);
> System.out.println("CharBuffer.length()="+ charbuf.length());
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> java version "1.4.2_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
> ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
> CharBuffer.length()=0
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.nio.BufferOverflowException
> at java.nio.CharBuffer.put(CharBuffer.java:662)
> at java.nio.CharBuffer.put(CharBuffer.java:629)
> at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406)
> at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243)
> at java.nio.charset.Charset.decode(Charset.java:630)
> at test2.main(test2.java:8)
> Suggested junit test case:
> CharsetTest.java
> -
> import java.nio.charset.Charset;
> import java.nio.ByteBuffer;
> import java.nio.CharBuffer;
> import junit.framework.*;
> public class CharsetTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(CharsetTest.class);
> }
> public void test_decode() {
> byte[] b = new byte[] {(byte)1};
> ByteBuffer buf= ByteBuffer.wrap(b);
> CharBuffer charbuf=Charset.forName("UTF-16").decode(buf);
> assertEquals("Assert 0: charset UTF-16",0,charbuf.length());
>
> charbuf=Charset.forName("UTF-16BE").decode(buf);
> assertEquals("Assert 1: charset UTF-16BE",0, charbuf.length());
>
>
> charbuf=Charset.forName("UTF-16LE").decode(buf);
> assertEquals("Assert 2: charset UTF16LE",0, charbuf.length());
>
>}
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: running eclipse on Harmony classlib
On 2/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Vladimir Strigun wrote: > > I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse > > you need to make following steps: > > > > - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar > > from xml.apache.org and put it to deploy/jre/lib/boot/ > > > > - add next line to jre/lib/boot/bootclasspath.properties : > > bootclasspath.38=serializer.jar > > > > - download and build Intel contribution of beans, math and regex > > packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) > > > > - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder > > > > - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar > > org.eclipse.core.launcher.Main > > > > I've tried to create simple Java project and Hello class inside. > > Everything works fine without any exception or problems. > > That is excellent! > > > Tim, in your movie I have seen new type for installed JRE in Eclipse: > > "Apache Harmony VM". Do you have Eclipse plugin for Harmony already? > > Yes, I just need to get the appropriate "ok"'s from IBM and then > (assuming I do get them) I shall bring it to the project. Just interesing: do you used standard eclipse VM runner and VM debugger (I mean classes org.eclipse.jdt.internal.launching.StandardVMRunner and org.eclipse.jdt.internal.launching.StandardVMDebugger) in your plugin ? What types of VM's your plugin is supported? Looks like that IBM VM works well with standard runner and debugger, but if we want to support other Harmony VM's then I think it will be necessary to make own implementation of mentioned classes inside plugin. In this case, runner and debugger can apply VM-specific options, for instance for IBM VM and Jchevm. Thanks, Vladimir Strigun, Intel Middleware Products Division > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. >
Re: [Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml]
Hi Geir,
Excellent !
Best regards,
George
IBM UK
Geir Magnusson Jr wrote:
George Harley wrote:
Hi,
Is it really the case that the BC provider jar needs to be on the
boot classpath ?
Probably not.
There was some discussion on this a little over a week ago
on this thread about the contribution of the beans, math and regex
libraries. The post I want to refer to does not seem to be in the
mailing list archive (!!??!) so let me copy the relevant text in-line
here as I believe that what it says is important :
--- snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Just to clarify your clarification of the question of current Harmony
behaviour ...
(A) With the current Harmony build it looks like there is *no
attempt* to verify the signature of a signed jar file that has been
placed on the bootclasspath. I know this because I took a signed BC
provider jar (as downloaded from http://www.bouncycastle.org),
deliberately tampered with the .SF file in the META-INF folder by
removing a few lines, then added the modified jar to the
bootclasspath of a simple program that listed the algorithms
supported by the BC provider. Everything worked fine.
(B) With the current Harmony build it looks like an attempt is made
at verifying the signature of a signed jar in the jre/lib/ext
directory. The attempt fails because it involves trying to use
functionality exported by the jar currently being verified and so
opens up a whole problem with cycles.
To my mind, (B) is a definite bug that would be fixed by having a
default Harmony provider. The result of my little bit of playing with
(A) just reinforces the argument that relying on the bootclasspath to
load your third party providers is not er ... secure.
That's obvious. We just have to fix it.
--- end of snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Best regards,
George
IBM UK
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Arghhh!
make it stop
From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
That was the patch :)
All that really is supposed to do is get junit and bcprov there.
I'll move.
geir
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
+
value="-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}"/>
value="-Djava.security.properties==${build.lib.path}/security/java.security"/>
@@ -518,7 +520,7 @@
name="org/apache/harmony/security/test/**"/>
-
+
name="java/security/KSBuilderTest.java"/>
name="java/security/KeyPairGeneratorTest1.java"/>
name="java/security/KeyPairGeneratorTest3.java"/>
Re: [Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml]
George Harley wrote:
Hi,
Is it really the case that the BC provider jar needs to be on the boot
classpath ?
Probably not.
There was some discussion on this a little over a week ago
on this thread about the contribution of the beans, math and regex
libraries. The post I want to refer to does not seem to be in the
mailing list archive (!!??!) so let me copy the relevant text in-line
here as I believe that what it says is important :
--- snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Just to clarify your clarification of the question of current Harmony
behaviour ...
(A) With the current Harmony build it looks like there is *no attempt*
to verify the signature of a signed jar file that has been placed on the
bootclasspath. I know this because I took a signed BC provider jar (as
downloaded from http://www.bouncycastle.org), deliberately tampered with
the .SF file in the META-INF folder by removing a few lines, then added
the modified jar to the bootclasspath of a simple program that listed
the algorithms supported by the BC provider. Everything worked fine.
(B) With the current Harmony build it looks like an attempt is made at
verifying the signature of a signed jar in the jre/lib/ext directory.
The attempt fails because it involves trying to use functionality
exported by the jar currently being verified and so opens up a whole
problem with cycles.
To my mind, (B) is a definite bug that would be fixed by having a
default Harmony provider. The result of my little bit of playing with
(A) just reinforces the argument that relying on the bootclasspath to
load your third party providers is not er ... secure.
That's obvious. We just have to fix it.
--- end of snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Best regards,
George
IBM UK
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Arghhh!
make it stop
From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
That was the patch :)
All that really is supposed to do is get junit and bcprov there. I'll
move.
geir
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
+
value="-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}"/>
value="-Djava.security.properties==${build.lib.path}/security/java.security"/>
@@ -518,7 +520,7 @@
name="org/apache/harmony/security/test/**"/>
-
+
name="java/security/KeyPairGeneratorTest1.java"/>
name="java/security/KeyPairGeneratorTest3.java"/>
Re: [Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml]
Hi,
Is it really the case that the BC provider jar needs to be on the boot
classpath ? There was some discussion on this a little over a week ago
on this thread about the contribution of the beans, math and regex
libraries. The post I want to refer to does not seem to be in the
mailing list archive (!!??!) so let me copy the relevant text in-line
here as I believe that what it says is important :
--- snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Just to clarify your clarification of the question of current Harmony
behaviour ...
(A) With the current Harmony build it looks like there is *no attempt*
to verify the signature of a signed jar file that has been placed on the
bootclasspath. I know this because I took a signed BC provider jar (as
downloaded from http://www.bouncycastle.org), deliberately tampered with
the .SF file in the META-INF folder by removing a few lines, then added
the modified jar to the bootclasspath of a simple program that listed
the algorithms supported by the BC provider. Everything worked fine.
(B) With the current Harmony build it looks like an attempt is made at
verifying the signature of a signed jar in the jre/lib/ext directory.
The attempt fails because it involves trying to use functionality
exported by the jar currently being verified and so opens up a whole
problem with cycles.
To my mind, (B) is a definite bug that would be fixed by having a
default Harmony provider. The result of my little bit of playing with
(A) just reinforces the argument that relying on the bootclasspath to
load your third party providers is not er ... secure.
--- end of snip from dev-list append of 1st Feb 2006 by
[EMAIL PROTECTED] ---
Best regards,
George
IBM UK
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Arghhh!
make it stop
From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
That was the patch :)
All that really is supposed to do is get junit and bcprov there. I'll
move.
geir
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
+
value="-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}"/>
value="-Djava.security.properties==${build.lib.path}/security/java.security"/>
@@ -518,7 +520,7 @@
name="org/apache/harmony/security/test/**"/>
-
+
name="java/security/KeyPairGeneratorTest1.java"/>
name="java/security/KeyPairGeneratorTest3.java"/>
--
IBM UK
Re: Location for API extensions
Anton Avtamonov wrote: Besides, such approach ties them to Harmony if they found such extensions (funtionality, included into packages of 'public access') useful :-) We actually don't want to tie anyone into Harmony other than because we're free, fast, stable, etc. This project *may* at some point offer packages that are not part of J2SE (for example, if we had built a nice logging implementation that was resuable), but that would clearly be separate parts of the project, and not to be confused with Harmony the J2SE Implementation. geir
Re: [classlib] security2 -> security
I'm going to walk method by method, compare and present results starting with the easiest cases. I've already taken some look at security so I think it would not be very difficult - it has 50+ classes, ~20 of them are exceptions, there are some interfaces... Thanks, Mikhail On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Tim Ellison wrote: > > +1 to consolidating on a single security module. > > I'm also interested to hear what merging Mikhail has in mind. > > > > I was led to believe that security2 was a proper superset of security, > > so we should be able to do a 'big bang' switch. The security_orig won't > > be too far away if we need to pull something in. (Perhaps move it out > > of trunk/modules/ to avoid confusion?) > > Right - it will live forever in SVN, and of course we always can "copy > forward" in time if we need to - i.e. copy from some past rev into > "now", whenever that is. > > I just don't want to lose anything useful that may be in security... > > geir > > > > > Regards, > > Tim > > > > Geir Magnusson Jr wrote: > >> Before you do that... > >> > >> What are you thinking as your approach? > >> > >> geir > >> > >> Mikhail Loenko wrote: > >>> I suggest merging these two bundles. I can do this and provide a patch... > >>> > >>> Thanks, > >>> Mikhail > >>> > >>> On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > security classes are a subset of security2 classes. > > security2 is 1.5-ready while security has javadocs. What do you mean > by 'better'? > Are there any original approaches or efficient algorithms used in > security? > > Thanks, > Mikhail > > > On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Hm. I thought security was stubs, but it isn't. > > > > Is there anything in security/ that we don't have in security2/ or is > > better? > > > > geir > > > > Geir Magnusson Jr wrote: > >> Unless I hear massive bellowing in opposition, I'm going to move > >> security -> security_orig and security2 -> security sometime tomorrow. > >> Please register protests now... > >> > >> geir > >> > >> > >>> > > >
Re: [Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml]
Tim Ellison wrote:
Arghhh!
make it stop
From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
That was the patch :)
All that really is supposed to do is get junit and bcprov there. I'll move.
geir
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+
+
@@ -518,7 +520,7 @@
-
+
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Stepan Mishura wrote:
Hi Geir,
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
make/build.xml) and they are absent in Harmony boot (deploy/jre/lib/boot)
directory. So the build script from 'security2' builds them and places
explicitly to the bootclasspath.
Then this is wrong then, correct? We should put putting crypto.jar and
x_net.jar into the bootclasspath?
s/bootclasspath/jre\/lib\/boot directory/ ?
yes, of course. sorry
If you remove jvmarg line then you need to update additionally
make/build.xml or the build script from 'security2' to put these jars to
Harmony boot directory.
Yes - I think that is the sensical way to go as we do want them there,
right?
yep
I think that we should work out some kind of 'transition procedure' for
substituting security with security2 to be sure that we don't miss
anything
and we are consistent. The first step may be extracting x-net component
because it is quite independent.
Don't mix the issues. Right now, no modules/security code is being built.
So - first - any problem with crypto and x_net into bootclasspath?
erm, 'yes' -- I mean 'no', erm -- what's the question?
the JARs should be on the bootclasspath by being built into jre/lib/boot.
Please remember to include the manifest too, the current security.jar
does not have one and breaks my Eclipse development (I can raise a JIRA
to say that if you want).
Heh. Ok. I'll do now. If I forget, then drop in a JIRA...
Regards,
Tim
On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
Geir Magnusson Jr wrote:
I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
issue.
However, there was a small thing that bugged me. We were setting the
bootclasspath as follows :
}${build.jars.path}/x_net.jar"/>
which has 2 of the 3 artifacts generated by security2 coming from the
local modules/security2 tree, and the third, security.jar, coming from
deploy/jre/lib/boot. This isn't healthy.
So I just removed the above line, and now we depend on all three jars
coming from the same place, namely the deploy boot classpath.
I only feel strongly that we are consistent. We can change from
deploy/
to modules/security2 if we need to.
I suspect this will be fine, but it does mean that working in
modules/security2 means that you need to go to top level to re-run the
build to get the jars in the right place.
I think I'll change the local make in modules/security2 to also copy
the
generated jars to ../../deploy/jre/lib/boot/
That way, you can work locally and still do the proper testing w/o
having to out of the module you are working in. I suspect that this
will be a pattern we repeat in all modules.
geir
Re: Location for API extensions
> > org.apache.harmony > > root of all package names > > > > org.apache.harmony. > > separates module namespaces > > > > org.apache.harmony.. > > types whose API will be carefully managed. Other modules > > can use these types in their impl. > > > > org.apache.harmony..internal > > types reserved for use only within the module impl. Other > > modules should not use these types as they may change. > > > > org.apache.harmony..tests > > module's tests > > Ugh :) > > > > > org.apache.harmony..examples > > module's examples (if we have any!) > > Yes! That it very similar (at least conceptually) to what I meant. The idea is to distinguish what others (I mean not only harmony developers of course, but our users who will write their java applications basing on harmony classes) can and what shouldn't use. Besides, such approach ties them to Harmony if they found such extensions (funtionality, included into packages of 'public access') useful :-) Talking about naming convension eclipse approach sounds very atrractive since lots of people are familiar with and get used it... -- Anton Avtamonov, Intel Middleware Products Division
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Tim Ellison wrote: A while ago I took the old security2 build script and rewrote it to do a LUNI build this way (also factoring out the platform-specific parts to make it extensible). Now I'm using Eclipse and got lazy ;-) I was really trying to use Eclipse, but last night it couldn't do the simplest bit of refactoring. I was doing class renaming (to get rid of the random test naming in security2) and it just had some problem, and told me to look at the log. What log? A log? So I started IDEA and kept going I'll try to go back once I cool down. While I'm here though I'll see about getting IDEA to use Harmony... geir
[Fwd: svn commit: r376144 - /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml]
Arghhh!
make it stop
>From below:
-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
[ I know you are fixing this stuff, but I needed to vent ]
Original Message
Subject: svn commit: r376144 -
/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Date: Thu, 09 Feb 2006 01:44:21 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]
Author: geirm
Date: Wed Feb 8 17:44:19 2006
New Revision: 376144
URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
Log:
put the bootclasspath stuff back for classlib tests
because as I'm renaming some tests, it appears that
when things reordered, tests broke. On a lark, I put
it back, and things work. Scary.
Will investigate further, but wanted to fix so tests run
Also, changed one of the exclusion lists due to renaming.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
Wed Feb 8 17:44:19 2006
@@ -499,6 +499,8 @@
+
+
@@ -518,7 +520,7 @@
-
+
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib] security2 -> security
Tim Ellison wrote: +1 to consolidating on a single security module. I'm also interested to hear what merging Mikhail has in mind. I was led to believe that security2 was a proper superset of security, so we should be able to do a 'big bang' switch. The security_orig won't be too far away if we need to pull something in. (Perhaps move it out of trunk/modules/ to avoid confusion?) Right - it will live forever in SVN, and of course we always can "copy forward" in time if we need to - i.e. copy from some past rev into "now", whenever that is. I just don't want to lose anything useful that may be in security... geir Regards, Tim Geir Magnusson Jr wrote: Before you do that... What are you thinking as your approach? geir Mikhail Loenko wrote: I suggest merging these two bundles. I can do this and provide a patch... Thanks, Mikhail On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: security classes are a subset of security2 classes. security2 is 1.5-ready while security has javadocs. What do you mean by 'better'? Are there any original approaches or efficient algorithms used in security? Thanks, Mikhail On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: Unless I hear massive bellowing in opposition, I'm going to move security -> security_orig and security2 -> security sometime tomorrow. Please register protests now... geir
Re: Location for API extensions
Tim Ellison wrote: Anton Avtamonov wrote: We have agreed on org.apache.harmony package as a root package for private implementation stuff. As I understand the major part of the functionality located there is some kind of utility stuff used from different places (packages) and therefore moved out from the API tree. Besides, it also can contain some 'default' implementations when public API represents interfaces only. yes. It looks for me that in general we can divide all such stuff into 2 categories: - utility methods appeared due to package visibility or other reasons, 'default' implementations, etc. This category (in general) is not likely to be interesting for the users of harmony platform Yes, as you say, these are typically impl classes behind public API. - classes, which are referenced from API, but have stand-alone value, which is not accessible from public API. Such classes, in fact, extend the standard API and may be useful for the harmony users. I believe such functionality exists in almost any module; their authors know what is valuable. Yes, I would call these 'internal' APIs. There are a few sub-systems that are generally useful to class library implementers. What I propose is to identify such functionlity and separate it from the 'hidden' utility stuff. Let's have some additinal root (harmony.extensions say) specially intended to keep 'java-harmony' improvements. What do you think? I think having a package naming convention for it is good, it gives a clear indication of the expected 'scope' of API users which is necessary to understand when you migrate internal APIs. (I'm not keen on the name 'extensions' tho') Eclipse has quite a simple and intuitive package naming convention: http://dev.eclipse.org/naming.html If we do a similar thing that would produce: org.apache.harmony root of all package names org.apache.harmony. separates module namespaces org.apache.harmony.. types whose API will be carefully managed. Other modules can use these types in their impl. org.apache.harmony..internal types reserved for use only within the module impl. Other modules should not use these types as they may change. org.apache.harmony..tests module's tests Ugh :) org.apache.harmony..examples module's examples (if we have any!) The componentization runtime can enforce the package visibility rules through the JAR manifest, even allowing 'friend' relationships etc. See an example of this in the NIO manifest, who only allows LUNI to see the com.ibm.io.nio package [1]. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/nio/META-INF/MANIFEST.MF?view=markup Regards, Tim
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Geir Magnusson Jr wrote:
>
>
> Stepan Mishura wrote:
>> Hi Geir,
>>
>>> For the record, I put the jvmarg line back - I did some test class
>>> renaming, and things broke! I put it back, and all is well. Dunno.
>>> Leaving there so it doesn't break anyone else. Will continue to chase
>>> down after dinner
>>>
>>
>> crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
>> make/build.xml) and they are absent in Harmony boot (deploy/jre/lib/boot)
>> directory. So the build script from 'security2' builds them and places
>> explicitly to the bootclasspath.
>
>
> Then this is wrong then, correct? We should put putting crypto.jar and
> x_net.jar into the bootclasspath?
s/bootclasspath/jre\/lib\/boot directory/ ?
>> If you remove jvmarg line then you need to update additionally
>> make/build.xml or the build script from 'security2' to put these jars to
>> Harmony boot directory.
>
> Yes - I think that is the sensical way to go as we do want them there,
> right?
yep
>> I think that we should work out some kind of 'transition procedure' for
>> substituting security with security2 to be sure that we don't miss
>> anything
>> and we are consistent. The first step may be extracting x-net component
>> because it is quite independent.
>
> Don't mix the issues. Right now, no modules/security code is being built.
>
> So - first - any problem with crypto and x_net into bootclasspath?
erm, 'yes' -- I mean 'no', erm -- what's the question?
the JARs should be on the bootclasspath by being built into jre/lib/boot.
Please remember to include the manifest too, the current security.jar
does not have one and breaks my Eclipse development (I can raise a JIRA
to say that if you want).
Regards,
Tim
>> On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>>> For the record, I put the jvmarg line back - I did some test class
>>> renaming, and things broke! I put it back, and all is well. Dunno.
>>> Leaving there so it doesn't break anyone else. Will continue to chase
>>> down after dinner
>>>
>>>
>>> Geir Magnusson Jr wrote:
I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
issue.
However, there was a small thing that bugged me. We were setting the
bootclasspath as follows :
>>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator
>>> }${build.jars.path}/x_net.jar"/>
which has 2 of the 3 artifacts generated by security2 coming from the
local modules/security2 tree, and the third, security.jar, coming from
deploy/jre/lib/boot. This isn't healthy.
So I just removed the above line, and now we depend on all three jars
coming from the same place, namely the deploy boot classpath.
I only feel strongly that we are consistent. We can change from
deploy/
to modules/security2 if we need to.
I suspect this will be fine, but it does mean that working in
modules/security2 means that you need to go to top level to re-run the
build to get the jars in the right place.
I think I'll change the local make in modules/security2 to also copy
the
generated jars to ../../deploy/jre/lib/boot/
That way, you can work locally and still do the proper testing w/o
having to out of the module you are working in. I suspect that this
will be a pattern we repeat in all modules.
geir
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Geir Magnusson Jr wrote:
> I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
> issue.
>
> However, there was a small thing that bugged me. We were setting the
> bootclasspath as follows :
>
> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
>
>
> which has 2 of the 3 artifacts generated by security2 coming from the
> local modules/security2 tree, and the third, security.jar, coming from
> deploy/jre/lib/boot. This isn't healthy.
>
> So I just removed the above line, and now we depend on all three jars
> coming from the same place, namely the deploy boot classpath.
>
> I only feel strongly that we are consistent. We can change from deploy/
> to modules/security2 if we need to.
>
> I suspect this will be fine, but it does mean that working in
> modules/security2 means that you need to go to top level to re-run the
> build to get the jars in the right place.
>
> I think I'll change the local make in modules/security2 to also copy the
> generated jars to ../../deploy/jre/lib/boot/
>
>
> That way, you can work locally and still do the proper testing w/o
> having to out of the module you are working in. I suspect that this
> will be a pattern we repeat in all modules.
This is the right approach.
A while ago I took the old security2 build script and rewrote it to do a
LUNI build this way (also factoring out the platform-specific parts to
make it extensible). Now I'm using Eclipse and got lazy ;-)
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib] security2 -> security
+1 to consolidating on a single security module. I'm also interested to hear what merging Mikhail has in mind. I was led to believe that security2 was a proper superset of security, so we should be able to do a 'big bang' switch. The security_orig won't be too far away if we need to pull something in. (Perhaps move it out of trunk/modules/ to avoid confusion?) Regards, Tim Geir Magnusson Jr wrote: > Before you do that... > > What are you thinking as your approach? > > geir > > Mikhail Loenko wrote: >> I suggest merging these two bundles. I can do this and provide a patch... >> >> Thanks, >> Mikhail >> >> On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >>> security classes are a subset of security2 classes. >>> >>> security2 is 1.5-ready while security has javadocs. What do you mean >>> by 'better'? >>> Are there any original approaches or efficient algorithms used in >>> security? >>> >>> Thanks, >>> Mikhail >>> >>> >>> On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: > Unless I hear massive bellowing in opposition, I'm going to move > security -> security_orig and security2 -> security sometime tomorrow. > Please register protests now... > > geir > > >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Which applications run using Harmony classes?
Would be good to get Japitools reports going on the Harmony codebase too. Regards, Tim Geir Magnusson Jr wrote: > > > zoe slattery wrote: >> I've tried to post this a couple of times from another mail account - >> but it seems to go into a black hole - apologies if another two copies >> turn up later :-( >> >> I had some thoughts about running applications using Harmony classes. >> Rather than just getting various applications and trying them with >> Harmony I've been trying to see what classes they need. >> >> For example, I downloaded and installed Derby then ran this: >> >> java –verbose:class org.apache.derby.drda.NetworkServerControl start > >> dbc.txt >> >> This generates a file (dbc.txt) showing all of the classes that get >> loaded when Derby starts up. The format of the output is something >> like this: >> >> ... >> class load: java/io/BufferedOutputStream >> class load: java/io/BufferedReader >> class load: java/io/BufferedWriter >> class load: java/io/ByteArrayInputStream >> class load: java/io/ByteArrayOutputStream >> class load: java/io/CharConversionException >> class load: java/io/DataInput >> class load: java/io/DataInputStream >> ... >> >> using an IBM JRE - the format would likely be different using another >> JRE. I ran a few more similar things to look at what classes get >> loaded when you create tables, add rows etc. and then cat'd the class >> load output into a single file. A more extensive test could be run by >> using Derby unit tests. >> >> I wrote a small perl script that extracts the names of all of the java >> classes and then compares these against the API spec to generate a >> final list of API classes that are used by an application. I'd be >> happy to supply the perl, although it needs a bit of tidying up. > > This is cool. > >> >> The next step would be to check how many of these exist in SVN already >> - and maybe highlight the areas that we are missing? > > Yes! > >> So far, the only >> way I have found to get a list of files that exist in SVN is using >> something like "svn list $repos_path -R", if anyone knows of a better >> (faster) way I'd be happy to hear it. > > Try to find a way to do it on a local checkout. We don't want to be > banging the SVN repo like this. (We've been having problems lately w/ > people walking through the SVN repo, file after file, version after > version, via the viewCVS interface. Not a good use of resources. > > This would be cool - I'd love to post these on the website, to let > people know what they could do to help get their favorite app up and going. > > I wonder too if this could be combined with Gump somehow, so we can > automatically test a large swatch of the "popular java app" world. > > geir > >> >> Thoughts? >> >> -- >> Zoe Slattery >> IBM >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: running eclipse on Harmony classlib
Vladimir Strigun wrote: > I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse > you need to make following steps: > > - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar > from xml.apache.org and put it to deploy/jre/lib/boot/ > > - add next line to jre/lib/boot/bootclasspath.properties : > bootclasspath.38=serializer.jar > > - download and build Intel contribution of beans, math and regex > packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) > > - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder > > - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar > org.eclipse.core.launcher.Main > > I've tried to create simple Java project and Hello class inside. > Everything works fine without any exception or problems. That is excellent! > Tim, in your movie I have seen new type for installed JRE in Eclipse: > "Apache Harmony VM". Do you have Eclipse plugin for Harmony already? Yes, I just need to get the appropriate "ok"'s from IBM and then (assuming I do get them) I shall bring it to the project. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location for API extensions
Anton Avtamonov wrote: > We have agreed on org.apache.harmony package as a root package for > private implementation stuff. As I understand the major part of the > functionality located there is some kind of utility stuff used from > different places (packages) and therefore moved out from the API tree. > Besides, it also can contain some 'default' implementations when > public API represents interfaces only. yes. > It looks for me that in general we can divide all such stuff into 2 > categories: > - utility methods appeared due to package visibility or other > reasons, 'default' implementations, etc. This category (in general) is > not likely to be interesting for the users of harmony platform Yes, as you say, these are typically impl classes behind public API. > - classes, which are referenced from API, but have stand-alone value, > which is not accessible from public API. Such classes, in fact, extend > the standard API and may be useful for the harmony users. I believe > such functionality exists in almost any module; their authors know > what is valuable. Yes, I would call these 'internal' APIs. There are a few sub-systems that are generally useful to class library implementers. > What I propose is to identify such functionlity and separate it from > the 'hidden' utility stuff. Let's have some additinal root > (harmony.extensions say) specially intended to keep 'java-harmony' > improvements. What do you think? I think having a package naming convention for it is good, it gives a clear indication of the expected 'scope' of API users which is necessary to understand when you migrate internal APIs. (I'm not keen on the name 'extensions' tho') Eclipse has quite a simple and intuitive package naming convention: http://dev.eclipse.org/naming.html If we do a similar thing that would produce: org.apache.harmony root of all package names org.apache.harmony. separates module namespaces org.apache.harmony.. types whose API will be carefully managed. Other modules can use these types in their impl. org.apache.harmony..internal types reserved for use only within the module impl. Other modules should not use these types as they may change. org.apache.harmony..tests module's tests org.apache.harmony..examples module's examples (if we have any!) The componentization runtime can enforce the package visibility rules through the JAR manifest, even allowing 'friend' relationships etc. See an example of this in the NIO manifest, who only allows LUNI to see the com.ibm.io.nio package [1]. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/nio/META-INF/MANIFEST.MF?view=markup Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Which applications run using Harmony classes?
zoe slattery wrote: I've tried to post this a couple of times from another mail account - but it seems to go into a black hole - apologies if another two copies turn up later :-( I had some thoughts about running applications using Harmony classes. Rather than just getting various applications and trying them with Harmony I've been trying to see what classes they need. For example, I downloaded and installed Derby then ran this: java –verbose:class org.apache.derby.drda.NetworkServerControl start > dbc.txt This generates a file (dbc.txt) showing all of the classes that get loaded when Derby starts up. The format of the output is something like this: ... class load: java/io/BufferedOutputStream class load: java/io/BufferedReader class load: java/io/BufferedWriter class load: java/io/ByteArrayInputStream class load: java/io/ByteArrayOutputStream class load: java/io/CharConversionException class load: java/io/DataInput class load: java/io/DataInputStream ... using an IBM JRE - the format would likely be different using another JRE. I ran a few more similar things to look at what classes get loaded when you create tables, add rows etc. and then cat'd the class load output into a single file. A more extensive test could be run by using Derby unit tests. I wrote a small perl script that extracts the names of all of the java classes and then compares these against the API spec to generate a final list of API classes that are used by an application. I'd be happy to supply the perl, although it needs a bit of tidying up. This is cool. The next step would be to check how many of these exist in SVN already - and maybe highlight the areas that we are missing? Yes! So far, the only way I have found to get a list of files that exist in SVN is using something like "svn list $repos_path -R", if anyone knows of a better (faster) way I'd be happy to hear it. Try to find a way to do it on a local checkout. We don't want to be banging the SVN repo like this. (We've been having problems lately w/ people walking through the SVN repo, file after file, version after version, via the viewCVS interface. Not a good use of resources. This would be cool - I'd love to post these on the website, to let people know what they could do to help get their favorite app up and going. I wonder too if this could be combined with Gump somehow, so we can automatically test a large swatch of the "popular java app" world. geir Thoughts? -- Zoe Slattery IBM
Re: Location for API extensions
Anton Avtamonov wrote: We have agreed on org.apache.harmony package as a root package for private implementation stuff. Only because we're the Apache Harmony project :) As I understand the major part of the functionality located there is some kind of utility stuff used from different places (packages) and therefore moved out from the API tree. Besides, it also can contain some 'default' implementations when public API represents interfaces only. It looks for me that in general we can divide all such stuff into 2 categories: - utility methods appeared due to package visibility or other reasons, 'default' implementations, etc. This category (in general) is not likely to be interesting for the users of harmony platform - classes, which are referenced from API, but have stand-alone value, which is not accessible from public API. Such classes, in fact, extend the standard API and may be useful for the harmony users. I believe such functionality exists in almost any module; their authors know what is valuable. Be careful how you put that. What do you mean by "extend the standard API"? What I propose is to identify such functionlity and separate it from the 'hidden' utility stuff. Let's have some additinal root (harmony.extensions say) specially intended to keep 'java-harmony' improvements. What do you think? Can you give an example of what you have in mind? geir
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Stepan Mishura wrote:
Hi Geir,
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
make/build.xml) and they are absent in Harmony boot (deploy/jre/lib/boot)
directory. So the build script from 'security2' builds them and places
explicitly to the bootclasspath.
Then this is wrong then, correct? We should put putting crypto.jar and
x_net.jar into the bootclasspath?
If you remove jvmarg line then you need to update additionally
make/build.xml or the build script from 'security2' to put these jars to
Harmony boot directory.
Yes - I think that is the sensical way to go as we do want them there,
right?
I think that we should work out some kind of 'transition procedure' for
substituting security with security2 to be sure that we don't miss anything
and we are consistent. The first step may be extracting x-net component
because it is quite independent.
Don't mix the issues. Right now, no modules/security code is being built.
So - first - any problem with crypto and x_net into bootclasspath?
geir
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
Geir Magnusson Jr wrote:
I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
issue.
However, there was a small thing that bugged me. We were setting the
bootclasspath as follows :
}${build.jars.path}/x_net.jar"/>
which has 2 of the 3 artifacts generated by security2 coming from the
local modules/security2 tree, and the third, security.jar, coming from
deploy/jre/lib/boot. This isn't healthy.
So I just removed the above line, and now we depend on all three jars
coming from the same place, namely the deploy boot classpath.
I only feel strongly that we are consistent. We can change from deploy/
to modules/security2 if we need to.
I suspect this will be fine, but it does mean that working in
modules/security2 means that you need to go to top level to re-run the
build to get the jars in the right place.
I think I'll change the local make in modules/security2 to also copy the
generated jars to ../../deploy/jre/lib/boot/
That way, you can work locally and still do the proper testing w/o
having to out of the module you are working in. I suspect that this
will be a pattern we repeat in all modules.
geir
Re: [classlib] security2 -> security
Before you do that... What are you thinking as your approach? geir Mikhail Loenko wrote: I suggest merging these two bundles. I can do this and provide a patch... Thanks, Mikhail On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: security classes are a subset of security2 classes. security2 is 1.5-ready while security has javadocs. What do you mean by 'better'? Are there any original approaches or efficient algorithms used in security? Thanks, Mikhail On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: Unless I hear massive bellowing in opposition, I'm going to move security -> security_orig and security2 -> security sometime tomorrow. Please register protests now... geir
running eclipse on Harmony classlib
I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse you need to make following steps: - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from xml.apache.org and put it to deploy/jre/lib/boot/ - add next line to jre/lib/boot/bootclasspath.properties : bootclasspath.38=serializer.jar - download and build Intel contribution of beans, math and regex packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar org.eclipse.core.launcher.Main I've tried to create simple Java project and Hello class inside. Everything works fine without any exception or problems. Tim, in your movie I have seen new type for installed JRE in Eclipse: "Apache Harmony VM". Do you have Eclipse plugin for Harmony already?
Which applications run using Harmony classes?
I've tried to post this a couple of times from another mail account - but it seems to go into a black hole - apologies if another two copies turn up later :-( I had some thoughts about running applications using Harmony classes. Rather than just getting various applications and trying them with Harmony I've been trying to see what classes they need. For example, I downloaded and installed Derby then ran this: java –verbose:class org.apache.derby.drda.NetworkServerControl start > dbc.txt This generates a file (dbc.txt) showing all of the classes that get loaded when Derby starts up. The format of the output is something like this: ... class load: java/io/BufferedOutputStream class load: java/io/BufferedReader class load: java/io/BufferedWriter class load: java/io/ByteArrayInputStream class load: java/io/ByteArrayOutputStream class load: java/io/CharConversionException class load: java/io/DataInput class load: java/io/DataInputStream ... using an IBM JRE - the format would likely be different using another JRE. I ran a few more similar things to look at what classes get loaded when you create tables, add rows etc. and then cat'd the class load output into a single file. A more extensive test could be run by using Derby unit tests. I wrote a small perl script that extracts the names of all of the java classes and then compares these against the API spec to generate a final list of API classes that are used by an application. I'd be happy to supply the perl, although it needs a bit of tidying up. The next step would be to check how many of these exist in SVN already - and maybe highlight the areas that we are missing? So far, the only way I have found to get a list of files that exist in SVN is using something like "svn list $repos_path -R", if anyone knows of a better (faster) way I'd be happy to hear it. Thoughts? -- Zoe Slattery IBM
