You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2007/02/09 12:25:17 UTC
Re: [contribution] Implementation of extcheck tool
Kalpak Gadre wrote:
> Hi all,
>
> I am trying to implement the extcheck JDK tool.
Cool, thanks.
> As i read in the specification
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/extcheck.html,
> extcheck tool
> compares versions as in java.lang.Package.isCompatibleWith()
>
> isCompatibleWith assumes that the version is '.' separated numeric
> values. But many of
> the jar files have alpha-numeric Specification-version attribute. How do
> you compare
> alpa-numeric versions? Do I assume versions to be numeric only?
The j.l.Package spec has a requirement that the specification version
contains only dot-separated numbers [1], and the method
#isCompatibleWith() will throw a NumberFormatException if that is not
the case.
If you get such an exception I think the only safe option is for the
tool to print a warning and assume the packages are incompatible.
[1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html
Regards,
Tim
> As I can see, Sun's implementation of extcheck is very rough. Try
> extcheck -verbose
> It throws ArrayIndexOutOfBounds :)
>
> Thanks,
>
> Kalpak
>
Re: [contribution] Implementation of extcheck tool
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 13, 2007, at 8:36 AM, Kalpak Gadre wrote:
>
>> To make the process manageable the ACQ breaks down the Harmony
>> project
>> into different components, so even if you are not in a position to
>> contribute code for tools it is likely that you can contribute to
>> Harmony in other areas. Your responses to the questionnaire will
>> determine that.
> That was the first time I ever tried to *understand* RI code!
> So you mean to say I *cant* contribute for *any* jdk tools now?
yes, I think we have the tools bundled together. I don't remember.
>
> As far as I can see, my exposure to RI code limits only to extcheck.
Good.
>
> Now when I fill up the ACQ, do I mention this?
Yes. You'll need to state where your exposure was. We carefully
created partitions so that if you were exposed to one area, you can
participate in any other area where you weren't exposed :)
Note that this may all be mooted when Sun delivers the remaining
source for OpenJDK, because we have no problems with exposure to code
under an open source license.
This is the subject of a separate thread.
geir
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
> To make the process manageable the ACQ breaks down the Harmony project
> into different components, so even if you are not in a position to
> contribute code for tools it is likely that you can contribute to
> Harmony in other areas. Your responses to the questionnaire will
> determine that.
That was the first time I ever tried to *understand* RI code!
So you mean to say I *cant* contribute for *any* jdk tools now?
As far as I can see, my exposure to RI code limits only to extcheck.
Now when I fill up the ACQ, do I mention this?
- Kalpak
Re: [contribution] Implementation of extcheck tool
Posted by Tim Ellison <t....@gmail.com>.
Kalpak Gadre wrote:
> I was just trying identify if it was not as straight forward as I thought,
> and I was stupid enough to miss it.
Understood -- there are a few places where the spec is ambiguous or
incomplete, and in those cases we would create tests against the API to
figure out the RI behavior.
> Having read ACQ I have a question, does it mean that I cannot further
> continue my work on extcheck? Considering I tried to understand the code?
> Even if I make sure that I implement it purely as per my understanding?
Take a look at the ACQ [1], since it is hard to summarise all the
possible scenarios here. In general, it is best to avoid studying
implementations that are not made available under a recognized open
source license.
To make the process manageable the ACQ breaks down the Harmony project
into different components, so even if you are not in a position to
contribute code for tools it is likely that you can contribute to
Harmony in other areas. Your responses to the questionnaire will
determine that.
Regards,
Tim
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
I was just trying identify if it was not as straight forward as I thought,
and I was stupid enough to miss it.
Having read ACQ I have a question, does it mean that I cannot further
continue my work on extcheck? Considering I tried to understand the code?
Even if I make sure that I implement it purely as per my understanding?
Thanks,
Kalpak
> For your work to be acceptable for use in Harmony, we need to ensure
> that it was written 'independently'. The precise definition is in the
> ACQ, which you can reach from this page:
> http://harmony.apache.org/contribution_policy.html
>
> Please take a look through it, and feel free to come back with any
> questions.
>
> Regards,
> Tim
Re: [contribution] Implementation of extcheck tool
Posted by Tim Ellison <t....@gmail.com>.
Kalpak Gadre wrote:
>> When you say "I checked the RI code..." I hope you don't mean that you
>> went to study the RI source. Please write it yourself from the spec.
>> If you need any help just shout there are plenty here who can help.
> Just checked it to see if I wasnt missing anything. I noticed a few
> things from source.
>
> 1. Conflict check is done for all the dependency jars which are
> specified by Classpath attribute
> in the manifest file. This is not mentioned in the spec.
>
> 2. All the jars are used as JarURLConnection. Is that necessary? Can you
> have dependency
> which is a HTTP URL location?
>
> Both these things are not mentioned in the spec. Am I missing anything
> here?
For your work to be acceptable for use in Harmony, we need to ensure
that it was written 'independently'. The precise definition is in the
ACQ, which you can reach from this page:
http://harmony.apache.org/contribution_policy.html
Please take a look through it, and feel free to come back with any
questions.
Regards,
Tim
Re: [contribution] Implementation of extcheck tool
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
You can't actually look at the RI code, because it's under a non-open
source license.
Please read :
http://harmony.apache.org/contribution_policy.html
geir
On Feb 12, 2007, at 10:54 AM, Kalpak Gadre wrote:
>
>> When you say "I checked the RI code..." I hope you don't mean that
>> you
>> went to study the RI source. Please write it yourself from the spec.
>> If you need any help just shout there are plenty here who can help.
> Just checked it to see if I wasnt missing anything. I noticed a few
> things from source.
>
> 1. Conflict check is done for all the dependency jars which are
> specified by Classpath attribute
> in the manifest file. This is not mentioned in the spec.
>
> 2. All the jars are used as JarURLConnection. Is that necessary?
> Can you have dependency
> which is a HTTP URL location?
>
> Both these things are not mentioned in the spec. Am I missing
> anything here?
>
> Kalpak
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
> When you say "I checked the RI code..." I hope you don't mean that you
> went to study the RI source. Please write it yourself from the spec.
> If you need any help just shout there are plenty here who can help.
Just checked it to see if I wasnt missing anything. I noticed a few
things from source.
1. Conflict check is done for all the dependency jars which are
specified by Classpath attribute
in the manifest file. This is not mentioned in the spec.
2. All the jars are used as JarURLConnection. Is that necessary? Can you
have dependency
which is a HTTP URL location?
Both these things are not mentioned in the spec. Am I missing anything here?
Kalpak
Re: [contribution] Implementation of extcheck tool
Posted by Tim Ellison <t....@gmail.com>.
Kalpak Gadre wrote:
> Sorry for following late on this Tim. My issues are as follows,
No problem, I was just throwing it in in case you were blocked. Keep up
the good work.
> 1. With -verbose option, I need to display the name of jar file which
> is currently checked.
> But Package instance does not have jar file info from which it is
> read from.
>
> 2. I can obtain package instance manually using manifest file's
> attribute "Name"
> But most of the jars seem to be missing it and still have
> "Specification-Title" and
> "Specification-version" attributes present. (Which are good enough to
> do the comparison)
>
> Here are my suggestions,
>
> 1. I use manual jar manifest parsing for extcheck instead of Package.
>
> 2. Let me copy the isCompatible() code for right now.
Sure, it is not a large block of code anyway.
> 3. We can move isCompatible as static method somewhere at kernel classes
> level.
>
> 4. Reuse this method wherever needed then.
>
> I checked the RI code and it also seems to be parsing jar files manually.
When you say "I checked the RI code..." I hope you don't mean that you
went to study the RI source. Please write it yourself from the spec.
If you need any help just shout there are plenty here who can help.
Regards,
Tim
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
> You have to ask a ClassLoader for them...
>
>
> class MyClassLoader extends ClassLoader {
> public MyClassLoader() {
> }
> public Package[] getPackages() {
> return super.getPackages();
> }
> }
>
> for (Package pkg : new MyClassLoader().getPackages()) {
> System.out.println(pkg);
> }
>
Sorry for following late on this Tim. My issues are as follows,
1. With -verbose option, I need to display the name of jar file which
is currently checked.
But Package instance does not have jar file info from which it is
read from.
2. I can obtain package instance manually using manifest file's
attribute "Name"
But most of the jars seem to be missing it and still have
"Specification-Title" and
"Specification-version" attributes present. (Which are good enough
to do the comparison)
Here are my suggestions,
1. I use manual jar manifest parsing for extcheck instead of Package.
2. Let me copy the isCompatible() code for right now.
3. We can move isCompatible as static method somewhere at kernel classes
level.
4. Reuse this method wherever needed then.
I checked the RI code and it also seems to be parsing jar files manually.
---------
Kalpak
Re: [contribution] Implementation of extcheck tool
Posted by Tim Ellison <t....@gmail.com>.
Kalpak Gadre wrote:
> Just had some trouble getting Package instance. But sure, will do the same.
You have to ask a ClassLoader for them...
class MyClassLoader extends ClassLoader {
public MyClassLoader() {
}
public Package[] getPackages() {
return super.getPackages();
}
}
for (Package pkg : new MyClassLoader().getPackages()) {
System.out.println(pkg);
}
Regards,
Tim
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
> 'reused' = copied?
>
Yes!
> Why not just call it from your tool? You have the whole JSE API at your
> disposal.
>
> Regards,
> Tim
Just had some trouble getting Package instance. But sure, will do the same.
Kalpak
Re: [contribution] Implementation of extcheck tool
Posted by Tim Ellison <t....@gmail.com>.
Kalpak Gadre wrote:
>> The j.l.Package spec has a requirement that the specification version
>> contains only dot-separated numbers [1], and the method
>> #isCompatibleWith() will throw a NumberFormatException if that is not
>> the case.
>>
>> If you get such an exception I think the only safe option is for the
>> tool to print a warning and assume the packages are incompatible.
>>
>> [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html
>>
> I have reused the code of Package::isCompatibleWith() from harmony
> codebase, I hope this is not an issue.
'reused' = copied?
Why not just call it from your tool? You have the whole JSE API at your
disposal.
Regards,
Tim
Re: [contribution] Implementation of extcheck tool
Posted by Kalpak Gadre <ka...@gmail.com>.
> The j.l.Package spec has a requirement that the specification version
> contains only dot-separated numbers [1], and the method
> #isCompatibleWith() will throw a NumberFormatException if that is not
> the case.
>
> If you get such an exception I think the only safe option is for the
> tool to print a warning and assume the packages are incompatible.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html
>
I have reused the code of Package::isCompatibleWith() from harmony
codebase, I hope this is not an issue.
Kal