RE: [general] compatibility packages
Dalibor Topic wrote: First part of the problem was the JavaScript bridge, which allowed access to sun.* code, and the second part was sun.misc.Unsafe, which allows kicking the legs under the Java security mechanism in three lines of pure Java code, once you get access to it. I respectfully disagree. The fact that the access controls around sun.misc.Unsafe failed was the problem, not the functionality it provides. You can clear the security manager with reflection too, but we rely on the access controls in reflection to protect us against that, if they fail, do you want to remove reflection as well? I am not aware of any other potentially useful code that uses sun.misc.Unsafe, but I'd appreciate pointers. I've seen code that had their own implementation of Object[In|Out]putStream, you cannot do that in pure Java (which is lame), but they managed to do it by using sun.reflect.* classes I believe. Regards, Jeroen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Helper inlining in JIT
Rana, good arguments. :-) Based on my experience in developing JIT and
GC in Java, I think there are two issues, or two levels of issues.
1. Runtime services inlining.
The word helper is not a widely-used term. I think the idea is to
enable JIT to inline the frequently accessed routines of JVM into Java
application jitted code. These routines are runtime services provided
by the components of JVM, including GC, threading, etc. In a C-written
JVM, they are native methods accessed by jitted code through JNI or
fast JNI or raw native interface, hence the performance could be a
problem, because a) the generated code sequence depends on the
compiler that compiled the JVM, b) the call/ret instructions and
parameter passing etc. have negative performance impact.
DRLVM is using and used manually-written machine code sequence or
specially-defined IR to solve this problem, so that the runtime
runtines code sequences are guaranteed or can be inlined. In order to
reduce the labor work and maintenance efforts, only the fast path of
the runtime service routines are manually written in machine code or
low-level IR.
This kind of code sequences are called helpers in DRLVM because they
are provided by the VM core to help JIT compilation. This design has a
problem that some of the runtime services actually are provided by
other components than VM core, such as GC. If GC changes, the code
sequence may be required to change accordingly. But the design goes
this way to pursue the JVM modularity: JIT only needs to query the VM
core for all the fast path services, and its VM core's role to
coordinate JIT compilation and other components.
It's desirable for respective components to provide their own services
and they are inlined by the JIT. We can let GC to provide the object
allocation fast-path code sequence or low-level IR. Then we need an
additional set of interfaces to talk about IR inlining besides current
simple C functions. For example, we can write the routine fast-path in
Java, so that the JIT compiler can inline them naturally, and what we
need is to define the Java interfaces for those services.
For example, the object allocation sequence can be written in Java in
a way like:
in Class GC_X,
Reference object_alloc(int size, Address vtable )
{
Reference result = ThreadLocalBlock().alloc(size);
if( ! free.isNull() ){
result.setAddressAtOffset(vtable, VTABLE_OFFSET_IN_OBJECT);
return result;
}
//native slow path
return object_alloc_slowpath(size, vtable);
}
This function is preformance critical. Its inlining can be achieved
automatically if a) the gc_alloc interface is known to JIT and b) the
JIT optimization inlines small size methods. (If JIT doesn't inline
it, annotation can be used to give instruction.)
These are obvious, and no special tricks are needed if all the methods
in the fast path are written in Java. It is not necessary for all the
methods in runtime service routines' fast-path to be written in Java.
They still can be supported by the idea of helper if that's
desirable. (For engineering purpose, native methods can be used as
well.) But how about if we still want to use Java to write them? Then
it comes to the second issue, a lower level issue.
2. Inlining of unsafe or low-level operations.
Java is not enough to write all runtime service routines. Because of
its safety property and platform independence, Java has no direct
memory access, no address arithmetics, and no direct platform-specific
operations. For example, Reference.setAddressAtOffset() is to store a
memory address into an offset position of a reference.
ThreadLocalBlock() is to retrieve thread local allocation block for
non-contended bump-pointer allocation, which needs OS specific
thread-local-storage access. The alloc() invocation on
ThreadLocalBlock needs to do address arithmetic and memory access as
well.
These routines are not able to be written in direct Java. We need to
tweak the Java language if we want to inline them. The tweaked Java
language is actually just to borrow Java syntax as the IR to denote
the unsafe or low-level operations. The advantage is we don't need any
other compiler, the JIT compiler understands JVM bytecode.
For example, the Reference class can be defined in this way:
Class Reference {
int address;
void setIntValueAtOffset(int value, int offset){
//empty
// JIT to generate code of: *((int *)(address + offset) = value;
}
// other methods
}
The method body is left empty intentionally for JIT to generate
whatever proper code sequence for its execution platform, which
requires the JIT understand the method as compiler intrinsics.
Annotations can be used to instruct the JIT compiler.
This kind of unsafe/lowlevel operations are not many, can be
categorized and well-defined. Any JIT that wants to inline the Java
fast-path has to understand them. (btw, this kind of tweaks is called
VMMagic in JikesRVM as I know. )
RE: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Sorry, this one's me. I'm fixing it right away. -Nathan -Original Message- From: Apache Harmony Build [mailto:[EMAIL PROTECTED] Sent: Sunday, August 13, 2006 2:11 PM To: [EMAIL PROTECTED] Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/targ et/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/5030 Build statistics: State: Failed Previous State: Ok Started at: Sun, 13 Aug 2006 20:02:11 +0100 Finished at: Sun, 13 Aug 2006 20:11:17 +0100 Total time: 9m 5s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Total time: 9 minutes 4 seconds ** ** - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Their build system is reporting svn failure so we don't know if you fixed it... did you? geir Nathan Beyer wrote: Sorry, this one's me. I'm fixing it right away. -Nathan -Original Message- From: Apache Harmony Build [mailto:[EMAIL PROTECTED] Sent: Sunday, August 13, 2006 2:11 PM To: [EMAIL PROTECTED] Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/targ et/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/5030 Build statistics: State: Failed Previous State: Ok Started at: Sun, 13 Aug 2006 20:02:11 +0100 Finished at: Sun, 13 Aug 2006 20:11:17 +0100 Total time: 9m 5s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Total time: 9 minutes 4 seconds ** ** - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Dalibor Topic wrote: First part of the problem was the JavaScript bridge, which allowed access to sun.* code, and the second part was sun.misc.Unsafe, which allows kicking the legs under the Java security mechanism in three lines of pure Java code, once you get access to it. The exploit only works on VMs with a sun.misc.Unsafe class, obviously. Microsoft's JVM is not affected. Are you suggesting that by the very nature of being named 'sun.misc.Unsafe' there's a problem or might it simply be a bug in the implementation? If we took the j.u.c code and renamed the package, we'd be ok? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Dalibor Topic wrote: On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, but you should trust us anyway on our other claims)' is not a very compelling tag line either. But this isn't what we're trying to say, so please don't put words in our mouth. The issue is removing speedbumps (no matter who put them there) on the road to users working with Harmony. People are busy, and don't generally have a lot of free time to tinker. Time is a very valuable and scarce thing. If someone chooses to *invest* some of their time trying out Harmony, lets make it as smooth as possible, and be as appreciative as possible. Sure, they may be doing the Wrong Thing by using software that makes the common mistake of using an internal Sun class, but that's really a secondary concern. I believe you've largely misunderstood what I said, unfortunately. There is no them vs. us here, and I am not trying to put words in mouths, or playing wiesel wording and framing games. Ok - sorry. Look, I agree with pretty much with all you say, my point is that we can't compete with Sun on the ability to run 100% of code written for their VM, suncompat.jar or not. As Stefano said (he got the meaning of what I tried to get accross), that's not a game we can win. But we've got other qualities, as you've mentioned, and which matter to our users. Noone is using our VMs for their sun.* classes. And we're not doing this to be able to compete with Sun on their implementation of sun.*. We're doing it simply to make it easy for people to *try* Harmony *right now*. The only interaction we've had with users so far on this issue has shown that the user was able to spot a problem in his code, improve it, and contributed useful feedback. The first two things would not have happened if we had a suncompat.jar, and everyone seems to be better off with the current outcome. Was it a speedump? Maybe. It helped the user, though, and we should be as appreciative as possible about having such helpful speedbumps, IMHO, that make people aware of potential migration issues with their code, and make users come to us to give us their appreciatd feedback in the first place, rather than speeding through without a ... (and here I lack a suitable driving analogy, but I hope you catch my drift anyway) What if the problem was in Weblogic? What if the user couldn't get it fixed? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Marketing Harmony [was Re: [general] compatibility packages]
Martin Cordova wrote: To make the long story short, all we need here is a free JVM + JIT that can run popular server-side webapps and Eclipse, and if possible as fast as the IBM JVM does ;) -- leaving other interpreted options as perl, php and ruby eating the dust... +1 Please Harmony commandos, hurry up! just joking :) We're hurrying! And if you want to help, please do! We need it. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Alex Blewitt wrote: On 12/08/06, Jeroen Frijters [EMAIL PROTECTED] wrote: However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. I don't agree because we'll be clear about why we have sun.* classes - they are a crutch to help people switch to Harmony. Sun can't avoid having sun.* classes :) I don't think we'll ship with suncompat.jar forever. I'd probably say it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in bootclasspath by default...). And at all times, we are going to make big noises about why it's there and how people should use it... (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) Yah, but there's a difference between deprecated and what we're doing here. You deprecate when something that was part of the API contract needs to go away. We're never saying that suncompat is part of our API contract. Maybe it's simply semantics, but I see that these are important semantics. I asked him if they would be documenting these classes when they do this, but he said they wouldn't. So they seem to live in a dream world where on the one hand they want to discourage usage of sun.* and on the other hand continue to support it. Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. Users will make or break us. If we include it by default *now*, we include it by default *for ever*. If we don't include it by default, but have a FAQ up that tells people about the workarounds, then those people for whom it's a problem can fix it, and the rest of the world can get on without it quite happily. But adding it by default is a one-way street that can never be reversed. I don't agree at all. Like compatibility in general this is a hard problem and we need to take a pragmatic approach and I really like the current plan of having an optional suncompat module. There seems to be three options we can go forwards with: 1) Neither have suncompat.jar nor make it default (i.e. where we were before last week) 2) Have suncompat.jar, but don't make it default (instead, provide FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) 3) Have suncompat.jar, and make it default. I vote for #3, because at this stage of the project, we want to get rid of the speedbumps, switching to #2 at some point. As for #1, this is open source... we can't dictate that. (Actually, that would be a howler wouldn't it... to become the RI for sun.*...) The transition from 1-2-3 is irreversible, and the decision to go down that path should be considered carefully for both immediate short-term (My app doesn't run on Harmony!) and medium- and long-term goals (non-Sun VMs shouldn't have/need sun. classes) I absolutely don't agree that the transition is irreversible. I'd have *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle because at all times, we're going to make it clear what the situation is and why we're doing it. I strongly disagree with the suggestion that we must do 3 to support a tiny proportion of apps that may go against Sun's FAQ (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed, they go as far as saying that: The sun.* packages are not part of the supported, public interface. A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform. In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported. Why should we support them when Sun don't even claim to? You know why we're doing this. If Sun wanted to, I assume they could fix the problem in the VM. Furthermore, by taking a stance of 1) or 2), we are actively helping push Sun's advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a strong stand against these packages. Because I want a user population the size of Sun's or IBM's, not GNU Classpath's. Harmony will be great, regardless of whether the sun.* packages are there. There will be at least one program that doesn't work because of this (but that's been fixed already) -- there will be others in the future. The adoption of Harmony as an open-source JVM will happen regardless of the sun.* packages. Some people will complain, some will vociferously declare
RE: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
That seems to be just on the windows box. This was a failure from the linux box. I cut out most of the original email, just to trim down the size. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Sunday, August 13, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Their build system is reporting svn failure so we don't know if you fixed it... did you? geir Nathan Beyer wrote: Sorry, this one's me. I'm fixing it right away. -Nathan -Original Message- From: Apache Harmony Build [mailto:[EMAIL PROTECTED] Sent: Sunday, August 13, 2006 2:11 PM To: [EMAIL PROTECTED] Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/targ et/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/5030 Build statistics: State: Failed Previous State: Ok Started at: Sun, 13 Aug 2006 20:02:11 +0100 Finished at: Sun, 13 Aug 2006 20:11:17 +0100 Total time: 9m 5s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Total time: 9 minutes 4 seconds ** ** - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
On Sun, Aug 13, 2006 at 06:34:47PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: First part of the problem was the JavaScript bridge, which allowed access to sun.* code, and the second part was sun.misc.Unsafe, which allows kicking the legs under the Java security mechanism in three lines of pure Java code, once you get access to it. The exploit only works on VMs with a sun.misc.Unsafe class, obviously. Microsoft's JVM is not affected. Are you suggesting that by the very nature of being named 'sun.misc.Unsafe' there's a problem or might it simply be a bug in the implementation? the way sun.misc.Unsafe works is that if you get access to it, you've rooted the JVM, effectively, as you can perform 'unsafe' operations on objects, basically a bit like having a good old raw C pointer to crack your way through objects in memory. It's rather trivial: Decompiled exploit code is at http://www.opensecnet.com/omfg.jad , details are at http://www.idefense.com/intelligence/vulnerabilities/display.php?id=158 and a few further sites. It's been patched by Sun a while ago, too, fortunately, but no details on the fix are available. ;) If we took the j.u.c code and renamed the package, we'd be ok? We'd not share an actively used vulnerability vector with Sun's VM, at least. There was a CERT warning about the bug being exploited in the wild just a few months ago, which makes me uncomfortable having the class around in our VMs. Sun's design in this case appears to be sub-optimal, as by having a public class that is accessible accross packages and can be used to perform unsafe operations, they are adding another line of defense, which must not fail, in order for the JVM to remain uncompromised. A better design for such unsafe operations seems to be to put them in package-private classes and to not expose them to arbitrary code in other packages. That's essentially what I suggested a few mails ago regarding j.u.c. code: factoring the VM-specific, unsafe operating into their own package-private classes, hopefully with APIs that make sense to us, and using that instead of emulating the interna of Sun's VM. cheers, dalibor topic geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [general] compatibility packages
On 13/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Alex Blewitt wrote: On 12/08/06, Jeroen Frijters [EMAIL PROTECTED] wrote: However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. I don't think we'll ship with suncompat.jar forever. I'd probably say it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in bootclasspath by default...). The problem (that I see) is that once you have something in a release, it's almost impossible to remove it at a later stage without running the risk of breaking something. I don't think it's reasonable to expect a reversal in decision at any point on this issue ... (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) Yah, but there's a difference between deprecated and what we're doing here. You deprecate when something that was part of the API contract needs to go away. We're never saying that suncompat is part of our API contract. The point being that once something is there, it's almost impossible to remove it. It doesn't matter whether it's called 'deprecated' or 'suncompat'; it's either there, or it isn't. Once it is there, it's very difficult to stop it being there without breaking something. The point of those links was to help emphasise that regardless of warnings, terminology, or semantics applied to those elements, removing them is almost impossible. Maybe it's simply semantics, but I see that these are important semantics. I believe the fundamental difference is that you see it is possible to go from a 'enabled by default' to 'not enabled by default' -- my experience suggests otherwise. The semantics of the label attached to the library is irrelivant; it's whether you can go backwards or not. I do not believe you can. Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. Users will make or break us. Yes, and they'll break us when, after some time shipping suncompat.jar by default, we disable it by default. Far better to train them to do the right thing from the beginning (enable it if they need it) than to throw them at a much later stage. If we include it by default *now*, we include it by default *for ever*. If we don't include it by default, but have a FAQ up that tells people about the workarounds, then those people for whom it's a problem can fix it, and the rest of the world can get on without it quite happily. But adding it by default is a one-way street that can never be reversed. I don't agree at all. Yes, this is the fundamental objection I have, and you disagree with it. There seems to be three options we can go forwards with: 1) Neither have suncompat.jar nor make it default (i.e. where we were before last week) 2) Have suncompat.jar, but don't make it default (instead, provide FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) 3) Have suncompat.jar, and make it default. I vote for #3, because at this stage of the project, we want to get rid of the speedbumps, switching to #2 at some point. As for #1, this is open source... we can't dictate that. And what if it were impossible to move from 3-2? Your decision would have locked us into shipping the sun.* packages for ever. Is that what you want? (Actually, that would be a howler wouldn't it... to become the RI for sun.*...) :-) The transition from 1-2-3 is irreversible, and the decision to go down that path should be considered carefully for both immediate short-term (My app doesn't run on Harmony!) and medium- and long-term goals (non-Sun VMs shouldn't have/need sun. classes) I absolutely don't agree that the transition is irreversible. I'd have *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle because at all times, we're going to make it clear what the situation is and why we're doing it. Let me get this straight: You're happy to argue strongly enough *for* the suncompat.jar, that you think it should be the default (so that any application, no matter how badly written, will run without any changes). Yet you're happy for us to pull the rug out under the feet of those very same users at some point in the future? Possibly with just an entry in a README.TXT (and we know how much users want to read those)? Tell me -- what's so special about the user *now* that you're willing to inflict pain on the same user *later*? Why not inflict pain from the get-go? What is so important in the period between now and later that makes it essential that we must
Re: [general] compatibility packages
On Sun, Aug 13, 2006 at 06:38:13PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, but you should trust us anyway on our other claims)' is not a very compelling tag line either. But this isn't what we're trying to say, so please don't put words in our mouth. The issue is removing speedbumps (no matter who put them there) on the road to users working with Harmony. People are busy, and don't generally have a lot of free time to tinker. Time is a very valuable and scarce thing. If someone chooses to *invest* some of their time trying out Harmony, lets make it as smooth as possible, and be as appreciative as possible. Sure, they may be doing the Wrong Thing by using software that makes the common mistake of using an internal Sun class, but that's really a secondary concern. I believe you've largely misunderstood what I said, unfortunately. There is no them vs. us here, and I am not trying to put words in mouths, or playing wiesel wording and framing games. Ok - sorry. My apologies as well, for not being clear enough. Look, I agree with pretty much with all you say, my point is that we can't compete with Sun on the ability to run 100% of code written for their VM, suncompat.jar or not. As Stefano said (he got the meaning of what I tried to get accross), that's not a game we can win. But we've got other qualities, as you've mentioned, and which matter to our users. Noone is using our VMs for their sun.* classes. And we're not doing this to be able to compete with Sun on their implementation of sun.*. We're doing it simply to make it easy for people to *try* Harmony *right now*. I agree, I just don't think not having sun.* (on a case by case basis) makes a negative difference. It doesn't stop people from trying our code right now easily. It only stops them from using functionality we haven't implemented yet, but then the user experience is not going to be particularly different from them trying out other code where we haven't got an implementation for. Given that we're all working on works in progress, a few rough edges along the way should be expected by the kind tester, and that our target audience is very intelligent and realizes that, I don't see a particularly burning issue wrt to sun.* classes specifically. See, what makes me very uncomfortable about it is the sort of maintenance issues that Sun and IBM and whoever else needs to maintain sun.* classes in their VMs, have to go through, as Jeroen described it: backing out changes in order to keep broken code around since some customer may need it. That's not a good thing. I'd rather carefully consider if there is no better way to avoid such problems from the start on a case by case basis, than copying Sun's implementation's internals without weighing the merits and disadvantages of their designs. As Alex said, it's a one way road that we can't go back from, once we start including proprietary class library extensions, and have users relying on them. The only interaction we've had with users so far on this issue has shown that the user was able to spot a problem in his code, improve it, and contributed useful feedback. The first two things would not have happened if we had a suncompat.jar, and everyone seems to be better off with the current outcome. Was it a speedump? Maybe. It helped the user, though, and we should be as appreciative as possible about having such helpful speedbumps, IMHO, that make people aware of potential migration issues with their code, and make users come to us to give us their appreciatd feedback in the first place, rather than speeding through without a ... (and here I lack a suitable driving analogy, but I hope you catch my drift anyway) What if the problem was in Weblogic? What if the user couldn't get it fixed? I don't know. We could simply wait and see what happens when someone tries to run Weblogic on our VMs. That hasn't happened so far, at least not that I heard of it, so we could adopt the YAGNI approach for now. I mean, if we are lucky, by the time our users start doing that, Weblogic may no longer be relevant for them, because they all switched to Geronimo, for example, right? ;) cheers, dalibor topic geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr wrote: Alex Blewitt wrote: On 12/08/06, Jeroen Frijters [EMAIL PROTECTED] wrote: However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. I don't agree because we'll be clear about why we have sun.* classes - they are a crutch to help people switch to Harmony. Sun can't avoid having sun.* classes :) I don't think we'll ship with suncompat.jar forever. I'd probably say it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in bootclasspath by default...). And at all times, we are going to make big noises about why it's there and how people should use it... (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) Yah, but there's a difference between deprecated and what we're doing here. You deprecate when something that was part of the API contract needs to go away. We're never saying that suncompat is part of our API contract. Maybe it's simply semantics, but I see that these are important semantics. I asked him if they would be documenting these classes when they do this, but he said they wouldn't. So they seem to live in a dream world where on the one hand they want to discourage usage of sun.* and on the other hand continue to support it. Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. Users will make or break us. If we include it by default *now*, we include it by default *for ever*. If we don't include it by default, but have a FAQ up that tells people about the workarounds, then those people for whom it's a problem can fix it, and the rest of the world can get on without it quite happily. But adding it by default is a one-way street that can never be reversed. I don't agree at all. Like compatibility in general this is a hard problem and we need to take a pragmatic approach and I really like the current plan of having an optional suncompat module. There seems to be three options we can go forwards with: 1) Neither have suncompat.jar nor make it default (i.e. where we were before last week) 2) Have suncompat.jar, but don't make it default (instead, provide FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) 3) Have suncompat.jar, and make it default. I vote for #3, because at this stage of the project, we want to get rid of the speedbumps, switching to #2 at some point. As for #1, this is open source... we can't dictate that. (Actually, that would be a howler wouldn't it... to become the RI for sun.*...) The transition from 1-2-3 is irreversible, and the decision to go down that path should be considered carefully for both immediate short-term (My app doesn't run on Harmony!) and medium- and long-term goals (non-Sun VMs shouldn't have/need sun. classes) I absolutely don't agree that the transition is irreversible. I'd have *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle because at all times, we're going to make it clear what the situation is and why we're doing it. I strongly disagree with the suggestion that we must do 3 to support a tiny proportion of apps that may go against Sun's FAQ (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed, they go as far as saying that: The sun.* packages are not part of the supported, public interface. A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform. In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported. Why should we support them when Sun don't even claim to? You know why we're doing this. If Sun wanted to, I assume they could fix the problem in the VM. Furthermore, by taking a stance of 1) or 2), we are actively helping push Sun's advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a strong stand against these packages. Because I want a user population the size of Sun's or IBM's, not GNU Classpath's. If you've got credible numbers, I'd appreciate seeing them. The numbers I've got show that more people are using GNU Classpath through Kaffe gcj than Sun's or IBM's VM on Debian by a large
Re: [general] compatibility packages
This is getting long :) I'll respond inline because you've put so much thought into this, but I want to try to start summarizing : 0) Lets keep things in perspective - we're in the 'snapshot' phase of the project, and doing a release is a whole other story. Also, we're talking about a few simple utility classes. 1) We are talking about a selected few classes in sun.*, not all of Sun's code. 2) We are in the really-early-adopter phase of things, and therefore every single new user is incredibly valuable to the project. 3) Clearly there's value in providing these, as other implementations (BEA, IBM, Apple) include them. 4) I'm very supportive of making it clear that we're not promising these will always be here. In fact, I'd be happy to make the statement that they *won't* be included in any reasonably mature release (say, after v0.5 or something) because that's an easy promise to break :) I do believe that the probability of losing a old Harmony user when we make suncompat.jar optional is nearly 0, whereas the probability of losing a new Harmony user - someone just trying Harmony for the first time, say at night after work - if suncompat.jar isn't there is very high. Inline... Alex Blewitt wrote: On 13/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Alex Blewitt wrote: On 12/08/06, Jeroen Frijters [EMAIL PROTECTED] wrote: However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. I don't think we'll ship with suncompat.jar forever. I'd probably say it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in bootclasspath by default...). The problem (that I see) is that once you have something in a release, it's almost impossible to remove it at a later stage without running the risk of breaking something. I don't think it's reasonable to expect a reversal in decision at any point on this issue ... Well, we aren't doing releases now. Snapshots aren't releases. I understand your argument and agree with it in general. However, our deliverable is Java SE 5. Sun.* is just a 'marketing tool'. (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) Yah, but there's a difference between deprecated and what we're doing here. You deprecate when something that was part of the API contract needs to go away. We're never saying that suncompat is part of our API contract. The point being that once something is there, it's almost impossible to remove it. It doesn't matter whether it's called 'deprecated' or 'suncompat'; it's either there, or it isn't. Once it is there, it's very difficult to stop it being there without breaking something. The point of those links was to help emphasise that regardless of warnings, terminology, or semantics applied to those elements, removing them is almost impossible. We're already breaking things from the perspective of the user. If you argue that it's not broken because people shouldn't be using sun.*, then you can't have it both ways :) Maybe it's simply semantics, but I see that these are important semantics. I believe the fundamental difference is that you see it is possible to go from a 'enabled by default' to 'not enabled by default' -- my experience suggests otherwise. The semantics of the label attached to the library is irrelivant; it's whether you can go backwards or not. I do not believe you can. We're just producing snapshots... Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. Users will make or break us. Yes, and they'll break us when, after some time shipping suncompat.jar by default, we disable it by default. Far better to train them to do the right thing from the beginning (enable it if they need it) than to throw them at a much later stage. This makes sense on the surface, but when I think about it a little more, I still don't agree. Why? Because we are trying to get people to use Harmony. and rightly or wrongly, they are coming into this with the expectation that when they run their programs, they will work. Yes, it's horrible that Sun let it get to this point, and yes, I would prefer if we didn't have to deal with this, but the fact is that we're trying to cover the same functional ground that Sun's impl does, and like it or not, this is a factor. How about this - what if it was labeled Harmony + suncompat so it's clear to people that we're adding this extra 'crutch' for them (with appropos documentation) Then it's clear that it's something more. If we
Re: [general] compatibility packages
Dalibor Topic wrote: On Sun, Aug 13, 2006 at 06:38:13PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, but you should trust us anyway on our other claims)' is not a very compelling tag line either. But this isn't what we're trying to say, so please don't put words in our mouth. The issue is removing speedbumps (no matter who put them there) on the road to users working with Harmony. People are busy, and don't generally have a lot of free time to tinker. Time is a very valuable and scarce thing. If someone chooses to *invest* some of their time trying out Harmony, lets make it as smooth as possible, and be as appreciative as possible. Sure, they may be doing the Wrong Thing by using software that makes the common mistake of using an internal Sun class, but that's really a secondary concern. I believe you've largely misunderstood what I said, unfortunately. There is no them vs. us here, and I am not trying to put words in mouths, or playing wiesel wording and framing games. Ok - sorry. My apologies as well, for not being clear enough. Look, I agree with pretty much with all you say, my point is that we can't compete with Sun on the ability to run 100% of code written for their VM, suncompat.jar or not. As Stefano said (he got the meaning of what I tried to get accross), that's not a game we can win. But we've got other qualities, as you've mentioned, and which matter to our users. Noone is using our VMs for their sun.* classes. And we're not doing this to be able to compete with Sun on their implementation of sun.*. We're doing it simply to make it easy for people to *try* Harmony *right now*. I agree, I just don't think not having sun.* (on a case by case basis) makes a negative difference. It doesn't stop people from trying our code right now easily. It only stops them from using functionality we haven't implemented yet, but then the user experience is not going to be particularly different from them trying out other code where we haven't got an implementation for. Given that we're all working on works in progress, a few rough edges along the way should be expected by the kind tester, and that our target audience is very intelligent and realizes that, I don't see a particularly burning issue wrt to sun.* classes specifically. See, what makes me very uncomfortable about it is the sort of maintenance issues that Sun and IBM and whoever else needs to maintain sun.* classes in their VMs, have to go through, as Jeroen described it: backing out changes in order to keep broken code around since some customer may need it. That's not a good thing. I'd rather carefully consider if there is no better way to avoid such problems from the start on a case by case basis, than copying Sun's implementation's internals without weighing the merits and disadvantages of their designs. As Alex said, it's a one way road that we can't go back from, once we start including proprietary class library extensions, and have users relying on them. sigh I don't agree that weaning people off is impossible. And even if it is, right now we're talking about one base 64 encoding class The only interaction we've had with users so far on this issue has shown that the user was able to spot a problem in his code, improve it, and contributed useful feedback. The first two things would not have happened if we had a suncompat.jar, and everyone seems to be better off with the current outcome. Was it a speedump? Maybe. It helped the user, though, and we should be as appreciative as possible about having such helpful speedbumps, IMHO, that make people aware of potential migration issues with their code, and make users come to us to give us their appreciatd feedback in the first place, rather than speeding through without a ... (and here I lack a suitable driving analogy, but I hope you catch my drift anyway) What if the problem was in Weblogic? What if the user couldn't get it fixed? I don't know. We could simply wait and see what happens when someone tries to run Weblogic on our VMs. That hasn't happened so far, at least not that I heard of it, so we could adopt the YAGNI approach for now. You're missing the point. I don't want to play fetch me a rock here - for all the Martin's of the world that send us a mail, look into the problem, decide to take action, etc. there are probably at least 100 who just say eh. it's broken. figures. open source crap... and move on. Right now, we need to engage those 100 people. Even if we never can stop supporting that base64 encoder class, I don't think it's a high price to pay. After all, we know Sun isn't going to change it :) I mean, if we are lucky, by the time our users start doing that, Weblogic may no longer be
Re: [general] compatibility packages
Dalibor Topic wrote: On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr wrote: Because I want a user population the size of Sun's or IBM's, not GNU Classpath's. If you've got credible numbers, I'd appreciate seeing them. The numbers I've got show that more people are using GNU Classpath through Kaffe gcj than Sun's or IBM's VM on Debian by a large margin (~ 100%). I don't have numbers, but Sun, BEA, IBM have millions of users that depend on those codebases for the life of their business. I've never heard of anyone using kaffe+classpath for the life of their business. Now, that's not intended to disparage Kaffe or Classpath, as I realize that like Harmony, they aren't done, but I was simply responding to the comparison of the approach to this issue that Sun, IBM and BEA take vs Kaffe/GNUCLasspath. While the point was simply that there may be things to learn from the successful commercial vendors on this, I realize now that it would have been prudent to just keep my mouth shut :) See http://people.debian.org/~igloo/popcon-graphs/index.php?packages=sun-java5-jre%2Ckaffe%2Cjava-gcj-compatshow_installed=onshow_vote=onwant_percent=onwant_legend=onbeenhere=1 What exactly are we looking at here? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Geir Magnusson Jr wrote:
Never worry if there will be an objection to you raising a JIRA and
providing a patch.Just Do It!
Thanks a lot, Geir.
HARMONY-1157 was raised. And Tim had applied my patch.
Best regards,
Richard
:)
geir
Richard Liang wrote:
Hello All,
The constructor String(byte[] bytes, int offset, int length, String
charsetName) has the same bug as Harmony-487[1]. When the charsetName
is , RI throws UnsupportedEncodingException, but Harmony throws
IllegalCharsetNameException.
If there is no objection, I will raise a JIRA and provide a patch for
this issue. Thanks a lot.
The following test passes on RI, but fails on Harmony:
try {
String str = new String(new byte[] {0x41, 0x42}, 0, 2, );
fail(Should throw UnsupportedEncodingException);
} catch (UnsupportedEncodingException e) {
//expected
}
[1]http://issues.apache.org/jira/browse/HARMONY-487
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
Re: [classlib][instrument]Method to terminate VM.
Hi, all
The case is we need to load an implementation class during VM init and
should terminate it if the class cannot be found.
Here is the code.
inst_class =
(*env)-FindClass(env,
org/apache/harmony/instrument/internal/InstrumentationImpl);
if(NULL == inst_class){
//VM exits abnormally.
(*env)-FatalError(env,class cannot find:
org/apache/harmony/instrument/internal/InstrumentationImpl);
}
Thank you.
On 8/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
How far along is this code? Any chance you want to toss up a snapshot
of it so people can look and comment and ... maybe even help?
geir
Jimmy, Jing Lv wrote:
Leo Li wrote:
Hi, all
During the implementaion of instrument, I encounter the choice
about
how to terminate the VM when some abnormal event occurs, for example,
the
expected jar file does not exist or the implementation class of
Instrumentation cannot be found. The most simple and direct way is
just to
call exit(), and then the whole process will terminate. Hence OS will
treat
with all the release of resources. However, I propose to use
FatalError of
JNI instead, which notifies the VM to suicide, because it gives right
to the
implementation of VM to take charge of its own funeral affairs, which
might
include, for example, logging the cause of its crash.
Any suggestion from VM guys?
Thanks :)
Hi,
I agree that use VM FatalError is better than system exit(). If no
objections, I will make code that way.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Leo Li
China Software Development Lab, IBM
Re: [tools] Re: Keytool is done, JarSigner is next.
Hi Anton, I'm trying to run Jigsaw https server. I used Harmony keytool to generate keystore according to Jigsaw mans: keytool -genkey -alias troi.example.com -keypass example -keystore troi.keystore -keyalg RSA so far works OK keytool -selfcert -alias troi.example.com -keystore troi.keystore -keyalg RSA prints this error message: Enter keystore password: example java.security.NoSuchAlgorithmException: The algorithm MD5WithRSAEncryption is not found in the environment. at org.apache.harmony.tools.keytool.KeyCertGenerator.genX509CertImpl(Key CertGenerator.java:40) at org.apache.harmony.tools.keytool.KeyCertGenerator.selfCert(KeyCertGen erator.java:335) at org.apache.harmony.tools.keytool.Main.doWork(Main.java:78) at org.apache.harmony.tools.keytool.Main.run(Main.java:125) at org.apache.harmony.tools.keytool.Main.main(Main.java:141) Any idea how to solve this? Do we miss some functionality in Harmony? Thanks, Mikhail 2006/8/11, Geir Magnusson Jr [EMAIL PROTECTED]: 1) YAY! 2) No objections for jarsigner, but rather thanks and encouragement! 3) You may have been doing the following and I simply missed it, but I'd suggest that you keep a stream of patches coming on things like this so that people can see and get involved and also discuss more of your experience doing this on the list as it happens. 4) Can you add [tools] to your subject lines? :) geir Anton Rusanov wrote: I'm happy to write this - Keytool is done and operative now. :) It has the same functionality as the one from RI with some improvements. In addition to what RI can do the Harmony Keytool is able to * generate X.509 certificates v2, v3. * sign a certificate with another key from the keystore * generate and manage secret keys * convert a keystore to another format * check certificate revocation status * verify a certificate chain * use specific providers for various purposes. There is still a little problem with making an executable of the tool in the build. So you can follow the steps to make it on your own: 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ 3. run keytool.exe I want to thank Mikhail for applying my patches. I'm going to start work on JarSigner tool. Does anyone have objections to me doing this? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] Re: Keytool is done, JarSigner is next.
Side note : Can you keep notes so that when you get things working, we can post to website as docs? geir Mikhail Loenko wrote: Hi Anton, I'm trying to run Jigsaw https server. I used Harmony keytool to generate keystore according to Jigsaw mans: keytool -genkey -alias troi.example.com -keypass example -keystore troi.keystore -keyalg RSA so far works OK keytool -selfcert -alias troi.example.com -keystore troi.keystore -keyalg RSA prints this error message: Enter keystore password: example java.security.NoSuchAlgorithmException: The algorithm MD5WithRSAEncryption is not found in the environment. at org.apache.harmony.tools.keytool.KeyCertGenerator.genX509CertImpl(Key CertGenerator.java:40) at org.apache.harmony.tools.keytool.KeyCertGenerator.selfCert(KeyCertGen erator.java:335) at org.apache.harmony.tools.keytool.Main.doWork(Main.java:78) at org.apache.harmony.tools.keytool.Main.run(Main.java:125) at org.apache.harmony.tools.keytool.Main.main(Main.java:141) Any idea how to solve this? Do we miss some functionality in Harmony? Thanks, Mikhail 2006/8/11, Geir Magnusson Jr [EMAIL PROTECTED]: 1) YAY! 2) No objections for jarsigner, but rather thanks and encouragement! 3) You may have been doing the following and I simply missed it, but I'd suggest that you keep a stream of patches coming on things like this so that people can see and get involved and also discuss more of your experience doing this on the list as it happens. 4) Can you add [tools] to your subject lines? :) geir Anton Rusanov wrote: I'm happy to write this - Keytool is done and operative now. :) It has the same functionality as the one from RI with some improvements. In addition to what RI can do the Harmony Keytool is able to * generate X.509 certificates v2, v3. * sign a certificate with another key from the keystore * generate and manage secret keys * convert a keystore to another format * check certificate revocation status * verify a certificate chain * use specific providers for various purposes. There is still a little problem with making an executable of the tool in the build. So you can follow the steps to make it on your own: 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ 3. run keytool.exe I want to thank Mikhail for applying my patches. I'm going to start work on JarSigner tool. Does anyone have objections to me doing this? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] Re: Keytool is done, JarSigner is next.
Ok, sure.
One thing that IMHO worth discussion is:
By default the server tries to go to Sun's ssl provider:
com.sun.net.ssl.internal.ssl.Provider
Though it seems to be possibe to specify a custom provider by defining
a property
org.w3c.jigsaw.ssl.security.provider
But to figure that out I had to grep Jigsaw sources
The question is should we provide our own com.sun...Provider?
It would look like this way:
package com.sun.net.ssl.internal.ssl;
import org.apache.harmony.xnet.provider.jsse.JSSEProvider;
public class Provider extends JSSEProvider {
}
Thanks,
Mikhail
P.S. I was able to easily start Jigsaw HTTP server and navigate a bit.
I used IBM VM+Harmony classlib
2006/8/14, Geir Magnusson Jr [EMAIL PROTECTED]:
Side note :
Can you keep notes so that when you get things working, we can post to
website as docs?
geir
Mikhail Loenko wrote:
Hi Anton,
I'm trying to run Jigsaw https server. I used Harmony keytool to generate
keystore according to Jigsaw mans:
keytool -genkey -alias troi.example.com -keypass example -keystore
troi.keystore -keyalg RSA
so far works OK
keytool -selfcert -alias troi.example.com -keystore troi.keystore
-keyalg RSA
prints this error message:
Enter keystore password: example
java.security.NoSuchAlgorithmException: The algorithm
MD5WithRSAEncryption is not found in the environment.
at
org.apache.harmony.tools.keytool.KeyCertGenerator.genX509CertImpl(Key
CertGenerator.java:40)
at
org.apache.harmony.tools.keytool.KeyCertGenerator.selfCert(KeyCertGen
erator.java:335)
at org.apache.harmony.tools.keytool.Main.doWork(Main.java:78)
at org.apache.harmony.tools.keytool.Main.run(Main.java:125)
at org.apache.harmony.tools.keytool.Main.main(Main.java:141)
Any idea how to solve this? Do we miss some functionality in Harmony?
Thanks,
Mikhail
2006/8/11, Geir Magnusson Jr [EMAIL PROTECTED]:
1) YAY!
2) No objections for jarsigner, but rather thanks and encouragement!
3) You may have been doing the following and I simply missed it, but I'd
suggest that you keep a stream of patches coming on things like this so
that people can see and get involved and also discuss more of your
experience doing this on the list as it happens.
4) Can you add [tools] to your subject lines? :)
geir
Anton Rusanov wrote:
I'm happy to write this - Keytool is done and operative now. :)
It has the same functionality as the one from RI with some
improvements.
In addition to what RI can do the Harmony Keytool is able to
* generate X.509 certificates v2, v3.
* sign a certificate with another key from the keystore
* generate and manage secret keys
* convert a keystore to another format
* check certificate revocation status
* verify a certificate chain
* use specific providers for various purposes.
There is still a little problem with making an executable of the tool
in the build. So you can follow the steps to make it on your own:
1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe
2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\
3. run keytool.exe
I want to thank Mikhail for applying my patches.
I'm going to start work on JarSigner tool. Does anyone have objections
to me doing this?
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
