Re: [general] compatibility packages
I might have chosen to phrase it slightly differently, but yes IBM licenses the Sun code, so the sun.* packages in an IBM JRE come from the same original source (modulo any IBM applied changes). Regards, Tim Alex Blewitt wrote: > On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> 3) Clearly there's value in providing these [sun.* classes], as other >> implementations >> (BEA, IBM, Apple) include them. > > Possibly true, but for different reasons. They license the source code > bulk from Sun, not re-implement their own. (They have patches etc. > that sit on top of them, of course.) As a result, there's a bunch of > internal stuff that is exactly the same as Sun's, and so depends on > the sun.* classes. > > The value (to them) is that they don't have to spend time re-writing > the sun.* classes instead of something else. There's no value > necessarily to the end user; it's a selfish decision on their part, > nothing more. > > Alex. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Think Different! :) geir Alex Blewitt wrote: > Bear in mind that this isn't standard across all VMs. For example, Mac > VMs use JAVA_HOME/../Classes/classes.jar, instead of rt.jar. > > Alex. > > On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> I assume for #1 we'll offer a patch :) >> >> Or just create an rt.jar if someone needs that. There is no reason not >> to... >> >> geir >> >> >> Anton Luht wrote: >> > Hello, >> > >> > There's another issues on compatibility: some applications rely on the >> > existence of "/lib/rt.jar" - the example is [1]. Some >> > require tools.jar [2]. Harmony doesn't have these jars now so >> > applications can fail on it just because they're bound to the >> > implementation specifics. >> > >> > [1] >> > >> http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar >> >> > >> > [2] >> > >> http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar >> >> > >> > >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - 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
Bear in mind that this isn't standard across all VMs. For example, Mac VMs use JAVA_HOME/../Classes/classes.jar, instead of rt.jar. Alex. On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: I assume for #1 we'll offer a patch :) Or just create an rt.jar if someone needs that. There is no reason not to... geir Anton Luht wrote: > Hello, > > There's another issues on compatibility: some applications rely on the > existence of "/lib/rt.jar" - the example is [1]. Some > require tools.jar [2]. Harmony doesn't have these jars now so > applications can fail on it just because they're bound to the > implementation specifics. > > [1] > http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar > > [2] > http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
I assume for #1 we'll offer a patch :) Or just create an rt.jar if someone needs that. There is no reason not to... geir Anton Luht wrote: > Hello, > > There's another issues on compatibility: some applications rely on the > existence of "/lib/rt.jar" - the example is [1]. Some > require tools.jar [2]. Harmony doesn't have these jars now so > applications can fail on it just because they're bound to the > implementation specifics. > > [1] > http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar > > [2] > http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Hello, There's another issues on compatibility: some applications rely on the existence of "/lib/rt.jar" - the example is [1]. Some require tools.jar [2]. Harmony doesn't have these jars now so applications can fail on it just because they're bound to the implementation specifics. [1] http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar [2] http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Alex Blewitt wrote: > On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> 3) Clearly there's value in providing these [sun.* classes], as other >> implementations >> (BEA, IBM, Apple) include them. > > Possibly true, but for different reasons. They license the source code > bulk from Sun, not re-implement their own. (They have patches etc. > that sit on top of them, of course.) As a result, there's a bunch of > internal stuff that is exactly the same as Sun's, and so depends on > the sun.* classes. Depending on their license choice, we'll be able to do that soon :) If they'd just hurry up... > > The value (to them) is that they don't have to spend time re-writing > the sun.* classes instead of something else. There's no value > necessarily to the end user; it's a selfish decision on their part, > nothing more. I agree with sentence 1 and 3 above, with s/selfish/pragmatic applied to 3. I'd also bet that IBM wouldn't do it if they could avoid it - I can't imagine they would ship sun.* unless there was customer demand. 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: Re: [general] compatibility packages
On 14/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: 3) Clearly there's value in providing these [sun.* classes], as other implementations (BEA, IBM, Apple) include them. Possibly true, but for different reasons. They license the source code bulk from Sun, not re-implement their own. (They have patches etc. that sit on top of them, of course.) As a result, there's a bunch of internal stuff that is exactly the same as Sun's, and so depends on the sun.* classes. The value (to them) is that they don't have to spend time re-writing the sun.* classes instead of something else. There's no value necessarily to the end user; it's a selfish decision on their part, nothing more. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [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-compat&show_installed=on&show_vote=on&want_percent=on&want_legend=on&beenhere=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: [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. 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,
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
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
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 unsubscri
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
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: [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 > reg
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
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: [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: > 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: Marketing Harmony [was Re: [general] compatibility packages]
On Sat, Aug 12, 2006 at 08:19:33PM -0400, Martin Cordova wrote: > I think that Stefano points to the right direction. To be more > specific, Harmony will gain market share if it can run the most > popular java applications, mostly open source (tomcat, resin, jetty, > eclipse, hsql, mckoi, etc), and providing an efficient implementation > of the basic libraries. > > To add an additional factor, in some countries like Venezuela, > governments started a policy about adopting free/open software (in the > GNU sense) for all its activities, whenever/wherever possible. In the > particular case of Venezuela, it has been very aggressive, affecting > the way of doing IT business with the public sector, and there was a > lobby group that has put strong pressure trying to forbid the usage of > Java as a technology based on the false statement that this is > propietary technology, not compatible with the principles of free and > open source software. Yeah, I've been aware of that. > > There has been a lot of discussion and lobby around the subject, and > of course the subject of the forthcomming great Harmony JVM has been > at the center of the debate. I was told that even the Kaffe people > visited Venezuela and shared some time with the Ministry of Science > and Technology, explaining the current state of free Java - I cannot > confirm this. Interesting. I recall seeing slides about setting up Kaffe+Tomcat from Venezuela, but don't know who from us Kaffe folks went there. If you have more information on the usage of Kaffe in Venezuela, please send it my way. Thanks for bringing this up! cheers, dalibor topic > My company has invested some resources on this > public-relations too, protecting our current and future position, as > well as our investment on our Java framework > > 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... > > Please Harmony commandos, hurry up! > just joking :) > > Regards, > Martin > > > On 8/12/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > >Dalibor Topic wrote: > > > >>> 'Harmony - runs fewer apps than the leading brand' is hardly a > >>> compelling tag line. > >> > >> '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. > >> > >> The 100% like Sun tag line has shown time over time to be false for IBM's > >> VM for example, since IBM does not ship some of the classes Sun does, so > >> vm-specific code using them fails in funny ways on it. > >> > >> But that's how it is, 100% maching semantics is practially only possible > >by > >> using the exact same sources. And we're deliberately not doing that, and > >> making our own decisions on quirks of the spec. > >> > >> Harmony is *always* going to run fewer apps than the leading brand, > >> unless it uses the exact same set of sources, no matter what sort of > >> outlandish marketing claims we chose to use as tag lines. > > > >Let me try to be creative for a second, marketing wise. > > > >If we enter a pissing contest with Sun over who runs more apps, we lose. > >This is not what it's all about. > > > >Look at HTTPD, they never had to claim that they were faster or more > >secure or more useful than other web servers, they "just" needed to do > >follow the protocols precisely and work under all circumstances and all > >kinds of attack and respond quickly to vulnerabilities and to feature > >requests. > > > >Just like HTTPD, we can't change the "protocol", but we can talk to > >those who do, channeling ours and our users' feedback. > > > >Just like HTTPD, we don't win if we are faster, or if we have better > >marketing brochures... we win if we can make our users happy. > > > >Harmony's first goal is to pass certification to be able to enter the > >ball park (being legally admitted to play, that is). > > > >But the real game is to run the apps that our users care for. > > > >What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK... > >and at comparable speeds. And guess what? it's open source: if you can > >make it even faster, hook it up to your favorite profiler/debugger, or > >whatever you feel you need to implement that won't ruin compatibility > >with the spec, we'll love to incorporate your patches. > > > >It might take a while before "user innovation" really starts to kick in, > >after that, but sure enough, we'll have our "tab browsing"-like or > >"apache module"-like user-suggested feature that Sun's VM won't have but > >will still allow us to pass certification. > > > >And *then* is when the real fun begins. > > > >-- > >Stefano. > > > > > >- > >Terms of use : http://incubator.apache.org/harmony/mailing.html > >To
Re: [general] compatibility packages
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. 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. 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) cheers, dalibor topic > > > > > The 100% like Sun tag line has shown time over time to be false for IBM's > > VM for example, since IBM does not ship some of the classes Sun does, so > > vm-specific code using them fails in funny ways on it. > > > > But that's how it is, 100% maching semantics is practially only possible by > > using the exact same sources. And we're deliberately not doing that, and > > making our own decisions on quirks of the spec. > > And we're making decisions to behave like the RI. > > Our goal - yours and ours - is to get people onto open source and > free-as-in-Stallman implementations of Java. > > Given that we're trying to be an alternative to proprietary > implementations that are a) free-as-in-beer and b) technically excellent > and that licensing is mostly irrelevant to a vast number of users, > taking down the roadblocks is prudent. We need to make the switching > cost as low as possible. > > > > > Harmony is *always* going to run fewer apps than the leading brand, > > unless it uses the exact same set of sources, no matter what sort of > > outlandish marketing claims we chose to use as tag lines. > > We never chose any of those marketing claims. You did. Our goals are > compatibility with the spec, high quality, portability, modularity and > transparent, open community. One of the tactics to achieve that is to > hold our nose and implement necessary sun.* to help users switch. > > At the same time, we can call attention to the problem, and we actually > have a very good story for people - "bring apps over using our sun > compatibility library, and assuming we do something like have it > optionally log usages etc, and then let those logging/whatever features > help you find and remove these problems..." > > > > >> I believe that everyone wants to reduce dependencies on the non-API > >> types. It is a millstone for IBM and Sun and BEA etc if they cannot > >> modify their implementations without customers coming down on them. But > >> at this point we cannot call the shots from Harmony. > > > > We can't call the shots on IBM's, Sun's and BEA's implementation anyway, > > unless they switch to Harmony ;) What we can do is to help people improve > > their application code by helping them notice that they are using buggy, > > implementation-dependant software. > > Right. And the only way they are going to do that is if they use > Harmony, so we can tell them. And they aren't going to use Harmony - at > least right now - if we're in their face telling them that they are > wrong, and therefore we won't let their programs run. > > geir > > > > > - > Terms of use : http://incubator.ap
Re: [general] compatibility packages
On Sat, Aug 12, 2006 at 08:50:42PM +0200, Jeroen Frijters wrote: > Dalibor Topic wrote: > > So if I can't run the sun.misc.Unsafe remote exploit on > > Harmony it is a failure? ;) > > You keep referring to this, but IMO this is a mischaracterization of the > exploit. The exploit used a bug in JavaScript that allowed access to the > sun.* package, that was the real problem not the sun.misc.Unsafe class. > sun.misc.Unsafe was used to replace the SecurityManager's security field with null, which allowed the code to download a payload and Runtime.exec it. It's a nifty little exploit, if you google around you should be able to find the disassembled code. 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. I keep bringing it up because it is a nice example for what I am saying: copying Sun-specific classes without need is a liability, rather than an advantage. > You also keep hammering on CharToByteConverter as an example of bad code > that should trivially be fixed (and it obviously should, if possible, > but it's not always that easy), but there is also code out there that > uses sun.* classes to do things that are impossible to do with the > documented APIs. How would you fix those? If someone deliberately writes VM-specific code, you can't always fix it. There may be a good reason to do so, for example if you are doing research on Sun's implementation and hook into their VM using their internal interfaces. There is nothing to fix in such a case, the code works as designed. We'll never be able to perfectly run all those intertwined RMI extensions that work by hooking themselves deep into the interna of Sun's implementation, but that's so by deliberate design of the code: the authors wanted to take advantage of the interna of Sun's implementation. Is that a problem for anyone? I don't think it is. But there is no good reason in 2006 to use a Sun-internal Base64 implementation, or the sun.io APIs, afaik. The only reason why we care about sun.misc.Unsafe is Doug Lea's code, which seems like it can be refactored to offer a cleaner interface to the underlying VM, as I explained. I am not aware of any other potentially useful code that uses sun.misc.Unsafe, but I'd appreciate pointers. > BTW, that was a retorical question, because I already know your answer: > that's rubbish software that won't work reliably on Sun's JRE anyway, so > why should we support it? That's by far not the whole story. My apologies if it came accross as that simplistic. I'd say there are three categories: a) Simple mistakes people make by copying mistakes other people make. Base64, sun.io, etc. b) Choices of convenience: Base64, sun.io, etc were here as long as there were no better choices to get the job done. For most things, there are now, afaict. c) VM-implementation specific code: a lot of extensions to VMs and class libraries fall into this category by design. Can we accurately support c? I seriously doubt it. Can we accurately support b? Maybe, but code in b) tends to rather quickly move into a) as more interfaces are standardized over time, which means duplicate code to maintain for less benefit. Can we suport a? Maybe, but do the benefits outweigh the negative sides? cheers, dalibor topic > 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. 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. > > 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. > > 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] > - 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]
I think that Stefano points to the right direction. To be more specific, Harmony will gain market share if it can run the most popular java applications, mostly open source (tomcat, resin, jetty, eclipse, hsql, mckoi, etc), and providing an efficient implementation of the basic libraries. To add an additional factor, in some countries like Venezuela, governments started a policy about adopting free/open software (in the GNU sense) for all its activities, whenever/wherever possible. In the particular case of Venezuela, it has been very aggressive, affecting the way of doing IT business with the public sector, and there was a lobby group that has put strong pressure trying to forbid the usage of Java as a technology based on the false statement that this is propietary technology, not compatible with the principles of free and open source software. There has been a lot of discussion and lobby around the subject, and of course the subject of the forthcomming great Harmony JVM has been at the center of the debate. I was told that even the Kaffe people visited Venezuela and shared some time with the Ministry of Science and Technology, explaining the current state of free Java - I cannot confirm this. My company has invested some resources on this public-relations too, protecting our current and future position, as well as our investment on our Java framework 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... Please Harmony commandos, hurry up! just joking :) Regards, Martin On 8/12/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: Dalibor Topic wrote: >> 'Harmony - runs fewer apps than the leading brand' is hardly a >> compelling tag line. > > '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. > > The 100% like Sun tag line has shown time over time to be false for IBM's > VM for example, since IBM does not ship some of the classes Sun does, so > vm-specific code using them fails in funny ways on it. > > But that's how it is, 100% maching semantics is practially only possible by > using the exact same sources. And we're deliberately not doing that, and > making our own decisions on quirks of the spec. > > Harmony is *always* going to run fewer apps than the leading brand, > unless it uses the exact same set of sources, no matter what sort of > outlandish marketing claims we chose to use as tag lines. Let me try to be creative for a second, marketing wise. If we enter a pissing contest with Sun over who runs more apps, we lose. This is not what it's all about. Look at HTTPD, they never had to claim that they were faster or more secure or more useful than other web servers, they "just" needed to do follow the protocols precisely and work under all circumstances and all kinds of attack and respond quickly to vulnerabilities and to feature requests. Just like HTTPD, we can't change the "protocol", but we can talk to those who do, channeling ours and our users' feedback. Just like HTTPD, we don't win if we are faster, or if we have better marketing brochures... we win if we can make our users happy. Harmony's first goal is to pass certification to be able to enter the ball park (being legally admitted to play, that is). But the real game is to run the apps that our users care for. What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK... and at comparable speeds. And guess what? it's open source: if you can make it even faster, hook it up to your favorite profiler/debugger, or whatever you feel you need to implement that won't ruin compatibility with the spec, we'll love to incorporate your patches. It might take a while before "user innovation" really starts to kick in, after that, but sure enough, we'll have our "tab browsing"-like or "apache module"-like user-suggested feature that Sun's VM won't have but will still allow us to pass certification. And *then* is when the real fun begins. -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [general] compatibility packages
On 12/08/06, Jeroen Frijters <[EMAIL PROTECTED]> wrote: You also keep hammering on CharToByteConverter as an example of bad code that should trivially be fixed (and it obviously should, if possible, but it's not always that easy), but there is also code out there that uses sun.* classes to do things that are impossible to do with the documented APIs. How would you fix those? You can't trivially fix such problems; in each case, someone has to debug and find out where the dependency is. And let's face it, if someone refers to sun.foo.Bar (and it's not in suncompat.jar in the first instance) they're going to be in exactly the same situation. It's only really for the benefit of people who aren't the first to fall over (e.g. the BASE64 encoder). However, I've spoken with Mark Reinhold about this issue and he told me that Sun sometimes reverts changes to sun.* classes because a customer complains that it broke their code. And with this statement, you've highlighed precisely why we shouldn't include suncompat.jar by default. Because once we do, there's no going back -- ever. If we do, we risk the wrath of some user down in the future. (Very good related material can be found at http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and http://www.xom.nu/designprinciples.xhtml) I asked him if they would be documenting these classes when they do this, but he said they wouldn't. So they seem to live in a dream world where on the one hand they want to discourage usage of sun.* and on the other hand continue to support it. Surely we should be working towards that aim as well? I fail to see how this helps anyone in the medium or long term. If we include it by default *now*, we include it by default *for ever*. If we don't include it by default, but have a FAQ up that tells people about the workarounds, then those people for whom it's a problem can fix it, and the rest of the world can get on without it quite happily. But adding it by default is a one-way street that can never be reversed. Like compatibility in general this is a hard problem and we need to take a pragmatic approach and I really like the current plan of having an optional suncompat module. There seems to be three options we can go forwards with: 1) Neither have suncompat.jar nor make it default (i.e. where we were before last week) 2) Have suncompat.jar, but don't make it default (instead, provide FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm) 3) Have suncompat.jar, and make it default. The transition from 1->2->3 is irreversible, and the decision to go down that path should be considered carefully for both immediate short-term (My app doesn't run on Harmony!) and medium- and long-term goals (non-Sun VMs shouldn't have/need sun. classes) I strongly disagree with the suggestion that we must do 3 to support a tiny proportion of apps that may go against Sun's FAQ (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed, they go as far as saying that: "The sun.* packages are not part of the supported, public interface. A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform. "In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported." Why should we support them when Sun don't even claim to? Furthermore, by taking a stance of 1) or 2), we are actively helping push Sun's advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a strong stand against these packages. Harmony will be great, regardless of whether the sun.* packages are there. There will be at least one program that doesn't work because of this (but that's been fixed already) -- there will be others in the future. The adoption of Harmony as an open-source JVM will happen regardless of the sun.* packages. Some people will complain, some will vociferously declare that the suncompat module should be there by default. Some programs won't work. If we go with option 2), they can be made to work or to raise the issue that the program is not a portable Java application (or both). I strongly urge everyone to vote against the suncompat module being on the classpath by default. In two years time, we will be able to look back to this post and either congratulate ourselves on a wise decision made now, or rue the day that we gave up the chance to allow a strong stand on the restriction of sun.* packages for any running code. Alex. PS The whole 'on the classpath for runtime but not for compile time' is completely bogus. If it's on the classpath, then an IDE such as Eclipse that provides its own compiler will still be able to compile against the class, as will e.g. references in JSPs for application servers that suppy their own compi
RE: [general] compatibility packages
Dalibor Topic wrote: > So if I can't run the sun.misc.Unsafe remote exploit on > Harmony it is a failure? ;) You keep referring to this, but IMO this is a mischaracterization of the exploit. The exploit used a bug in JavaScript that allowed access to the sun.* package, that was the real problem not the sun.misc.Unsafe class. You also keep hammering on CharToByteConverter as an example of bad code that should trivially be fixed (and it obviously should, if possible, but it's not always that easy), but there is also code out there that uses sun.* classes to do things that are impossible to do with the documented APIs. How would you fix those? BTW, that was a retorical question, because I already know your answer: that's rubbish software that won't work reliably on Sun's JRE anyway, so why should we support it? 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. 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. 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. 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: [general] compatibility packages
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. > > The 100% like Sun tag line has shown time over time to be false for IBM's > VM for example, since IBM does not ship some of the classes Sun does, so > vm-specific code using them fails in funny ways on it. > > But that's how it is, 100% maching semantics is practially only possible by > using the exact same sources. And we're deliberately not doing that, and > making our own decisions on quirks of the spec. And we're making decisions to behave like the RI. Our goal - yours and ours - is to get people onto open source and free-as-in-Stallman implementations of Java. Given that we're trying to be an alternative to proprietary implementations that are a) free-as-in-beer and b) technically excellent and that licensing is mostly irrelevant to a vast number of users, taking down the roadblocks is prudent. We need to make the switching cost as low as possible. > > Harmony is *always* going to run fewer apps than the leading brand, > unless it uses the exact same set of sources, no matter what sort of > outlandish marketing claims we chose to use as tag lines. We never chose any of those marketing claims. You did. Our goals are compatibility with the spec, high quality, portability, modularity and transparent, open community. One of the tactics to achieve that is to hold our nose and implement necessary sun.* to help users switch. At the same time, we can call attention to the problem, and we actually have a very good story for people - "bring apps over using our sun compatibility library, and assuming we do something like have it optionally log usages etc, and then let those logging/whatever features help you find and remove these problems..." > >> I believe that everyone wants to reduce dependencies on the non-API >> types. It is a millstone for IBM and Sun and BEA etc if they cannot >> modify their implementations without customers coming down on them. But >> at this point we cannot call the shots from Harmony. > > We can't call the shots on IBM's, Sun's and BEA's implementation anyway, > unless they switch to Harmony ;) What we can do is to help people improve > their application code by helping them notice that they are using buggy, > implementation-dependant software. Right. And the only way they are going to do that is if they use Harmony, so we can tell them. And they aren't going to use Harmony - at least right now - if we're in their face telling them that they are wrong, and therefore we won't let their programs run. geir > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Marketing Harmony [was Re: [general] compatibility packages]
Dalibor Topic wrote: >> 'Harmony - runs fewer apps than the leading brand' is hardly a >> compelling tag line. > > '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. > > The 100% like Sun tag line has shown time over time to be false for IBM's > VM for example, since IBM does not ship some of the classes Sun does, so > vm-specific code using them fails in funny ways on it. > > But that's how it is, 100% maching semantics is practially only possible by > using the exact same sources. And we're deliberately not doing that, and > making our own decisions on quirks of the spec. > > Harmony is *always* going to run fewer apps than the leading brand, > unless it uses the exact same set of sources, no matter what sort of > outlandish marketing claims we chose to use as tag lines. Let me try to be creative for a second, marketing wise. If we enter a pissing contest with Sun over who runs more apps, we lose. This is not what it's all about. Look at HTTPD, they never had to claim that they were faster or more secure or more useful than other web servers, they "just" needed to do follow the protocols precisely and work under all circumstances and all kinds of attack and respond quickly to vulnerabilities and to feature requests. Just like HTTPD, we can't change the "protocol", but we can talk to those who do, channeling ours and our users' feedback. Just like HTTPD, we don't win if we are faster, or if we have better marketing brochures... we win if we can make our users happy. Harmony's first goal is to pass certification to be able to enter the ball park (being legally admitted to play, that is). But the real game is to run the apps that our users care for. What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK... and at comparable speeds. And guess what? it's open source: if you can make it even faster, hook it up to your favorite profiler/debugger, or whatever you feel you need to implement that won't ruin compatibility with the spec, we'll love to incorporate your patches. It might take a while before "user innovation" really starts to kick in, after that, but sure enough, we'll have our "tab browsing"-like or "apache module"-like user-suggested feature that Sun's VM won't have but will still allow us to pass certification. And *then* is when the real fun begins. -- Stefano. - 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 Fri, Aug 11, 2006 at 03:11:48PM +0100, Tim Ellison wrote: > Dalibor Topic wrote: > > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: > >> Dalibor Topic wrote: > >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: > Mikhail Loenko wrote: > > The problem is Base64 functionality is unavailable through the > > standard API, so people have a choice either use unportable sun.*, > > o.a.h.*, etc or create the coder from scratch > Understood, I think people are 'driven' to using the non-API types > though necessity rather than doing so by mistake. > >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath > >>> recommends using Apache Commons Codec for projects compatible with the > >>> Apache license. > >>> > >>> Amateur developers use non-standard classes because they are too lazy > >>> to think for themselves, and accordingly copy broken code around > >>> projects. > >>> Alas, a language designed to appeal to the masses naturally attracts a > >>> lot of people who'd have trouble producing portable code in any > >>> programming > >>> language. :) > >> I was being charitable. For sure many such usages can be easily > >> avoided, but in other cases no so easily; like CharToByteConverter would > >> require duplicating a wad of data, and I don't know of any third-party > >> impl. of Unsafe. > > > > Is there something that CharToByteConverter does that > > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen > > code using CharToByteConverter in years. > > If you want to duplicate the char conversion data then sure, but taking > a multi-MB hit isn't palatable to many apps when sun.io is sitting there > smiling at them. > java.nio.charset.CharsetEncoder is right there, a standard API, and does not add a multi-MB hit. ICU does, but when the choice is between maintainable applications or software slapped together in hope that it works, it's clear to me what to chose. > I saw a few uses when testing apps, but maybe I was unlucky. For > example, Xalan was using it until it was pointed it out last year > (http://issues.apache.org/jira/browse/XALANJ-2087). It kind of proves the point that there is no good reason to use sun.io classes today. > > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks > > to the JVM JSR not being ahead thinking enough to specify an API for > > low-level > > operations. It may or may not work depedending on how a VM interprets > > the non-existent spec for that class, so it is practically useless, > > unless it is running on the VM it was written on, i.e. Sun's. It may or > > may not work by chance, rather than by virtue. > > > > That holds in general for any code using implementation-specific > > interfaces. > > Exactly. > > >> We should appeal to app developers to change implementation dependent > >> code (even provide a recipe book of recommended solutions), but be > >> pragmatic about the need to run the current version. In many cases it > >> may be beyond the apps immediate sphere of influence (i.e. dependent > >> libraries). If everyone responded as quickly and effectively as Martin > >> we would have no worries. > > > > We've been doing that for years. See the GNU Classpath migration page in > > the Wiki that describes how to fix such broken code in many cases. > > Ack -- I see it here (just so others can find it too). > http://developer.classpath.org/mediation/ClasspathMigration > > > Being 'pragmatic' solves nothing, it just encourages people to > > continue behaving in dumb ways, because their code still may run, > > somehow, even if there is no way for Harmony to ensure that it will > > behave as they expect from whatever buggy Sun JDK they are using to > > run it usually in the corner cases, because there is no spec, and > > there are no tests. > > It's pragmatic because as I said, sometimes it is beyond the immediate > control of the application, and sometimes you won't get a second chance > to demonstrate your wares. So if I can't run the sun.misc.Unsafe remote exploit on Harmony it is a failure? ;) > 'Harmony - runs fewer apps than the leading brand' is hardly a > compelling tag line. '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. The 100% like Sun tag line has shown time over time to be false for IBM's VM for example, since IBM does not ship some of the classes Sun does, so vm-specific code using them fails in funny ways on it. But that's how it is, 100% maching semantics is practially only possible by using the exact same sources. And we're deliberately not doing that, and making our own decisions on quirks of the spec. Harmony is *always* going to run fewer apps than the leading brand, unless it uses the exact same set of sources, no matter what sort of outlandish marketing claims we chose to use as tag line
Re: [general] compatibility packages
Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: >> Dalibor Topic wrote: >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: > The problem is Base64 functionality is unavailable through the > standard API, so people have a choice either use unportable sun.*, > o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath >>> recommends using Apache Commons Codec for projects compatible with the >>> Apache license. >>> >>> Amateur developers use non-standard classes because they are too lazy >>> to think for themselves, and accordingly copy broken code around projects. >>> Alas, a language designed to appeal to the masses naturally attracts a >>> lot of people who'd have trouble producing portable code in any programming >>> language. :) >> I was being charitable. For sure many such usages can be easily >> avoided, but in other cases no so easily; like CharToByteConverter would >> require duplicating a wad of data, and I don't know of any third-party >> impl. of Unsafe. > > Is there something that CharToByteConverter does that > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen > code using CharToByteConverter in years. If you want to duplicate the char conversion data then sure, but taking a multi-MB hit isn't palatable to many apps when sun.io is sitting there smiling at them. I saw a few uses when testing apps, but maybe I was unlucky. For example, Xalan was using it until it was pointed it out last year (http://issues.apache.org/jira/browse/XALANJ-2087). > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks > to the JVM JSR not being ahead thinking enough to specify an API for > low-level > operations. It may or may not work depedending on how a VM interprets > the non-existent spec for that class, so it is practically useless, > unless it is running on the VM it was written on, i.e. Sun's. It may or > may not work by chance, rather than by virtue. > > That holds in general for any code using implementation-specific > interfaces. Exactly. >> We should appeal to app developers to change implementation dependent >> code (even provide a recipe book of recommended solutions), but be >> pragmatic about the need to run the current version. In many cases it >> may be beyond the apps immediate sphere of influence (i.e. dependent >> libraries). If everyone responded as quickly and effectively as Martin >> we would have no worries. > > We've been doing that for years. See the GNU Classpath migration page in > the Wiki that describes how to fix such broken code in many cases. Ack -- I see it here (just so others can find it too). http://developer.classpath.org/mediation/ClasspathMigration > Being 'pragmatic' solves nothing, it just encourages people to > continue behaving in dumb ways, because their code still may run, > somehow, even if there is no way for Harmony to ensure that it will > behave as they expect from whatever buggy Sun JDK they are using to > run it usually in the corner cases, because there is no spec, and > there are no tests. It's pragmatic because as I said, sometimes it is beyond the immediate control of the application, and sometimes you won't get a second chance to demonstrate your wares. 'Harmony - runs fewer apps than the leading brand' is hardly a compelling tag line. I believe that everyone wants to reduce dependencies on the non-API types. It is a millstone for IBM and Sun and BEA etc if they cannot modify their implementations without customers coming down on them. But at this point we cannot call the shots from Harmony. > Awarding incompetence doesn't solve the problem. That being said, kudos > to Martin for fixing the bug in his code. Had we had a Base64 class, > that bug wouldn't have showed up, and his code would have failed > elsewhere, or behaved differently on another VM. With the fix, his code > is portable, behaves in the same way on any VM, and may even be faster > than a vm-specific 'just for compatibility' implementation. > > There is no downside to simply fixing the buggy code. I agree, of course. >>> On a side note, I seem to recall reading on Sun's javac engineer's blog >>> that javac won't allow access to sun internal classes sooner or later, >>> so idiot-proofing class libraries may not be very useful, anyway, >>> as people will have to rewrite such code, or preferrably, throw it away. >> It will be interesting to see what havoc is unleashed by attempts to >> reduce the visibility of sun internal packages by the compiler and at >> runtime. > > I assume it will just cause unmaintained libraries to be substituted by > maintained ones, as people trade up to higher quality implementations of > functionality they need. Code that uses
Re: [general] compatibility packages
Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote: >> >> Dalibor Topic wrote: >>> >>> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks >>> to the JVM JSR not being ahead thinking enough to specify an API for >>> low-level >>> operations. It may or may not work depedending on how a VM interprets >>> the non-existent spec for that class, so it is practically useless, >>> unless it is running on the VM it was written on, i.e. Sun's. It may or >>> may not work by chance, rather than by virtue. >> I think you are being too harsh here, but that notwithstanding, one of >> the things we can do as open implementations is petition the EG to >> actually define these in the spec once we show that there's a good >> reason to do so, namely the independent implementations. > > The independant implementations are not using sun.misc.Unsafe. Why would > anyone want to use an undocumented implementation-specific class from > another implementation in their own? That makes no sense. There is no > point in petitioning the EC to specify sun.misc.Unsafe since no one in > their right mind uses it, except Sun, in the interna of their > implementation. That's like asking the EC to specify org.kaffe.util.Ptr, > or something equivalently pointless from DLRVM. It makes sense if you wish to use Doug's concurrency package as-is, as it has dependencies on sun.misc.Unsafe, which I think is a Good Thing. After we do that, I think we then go back to the EG and point out that in order for the world to reuse this code, we need to have sun.misc.Unsafe defined (of course, it would be given another namespace...). > > What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, > with a sane API that does not require computing field offsets manually, > like sun.misc.Unsafe seems to do. ;) That would a good thing to ask for two - the two would make a nice request. > > The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather > simple bug in Doug Lea's java.util.concurrent implementation: using > Sun-specific classes directly, rather than delegating to some > java.util.concurrent.VMCompareAndSwap interface layer. That means anyone > adopting the code needs to repeat the mistakes of Sun's implementation > (which has, coincidentally, had a very straightforward remote execution > exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. > > Yay. :/ > > Other than Doug's code, sun.misc.Unsafe does not matter at all, unless > you want "remote-execution-exploit-for-remote-execution-exploit" > compatibility. I believe that's too much to ask for. ;) I think we've been clear all along why we'd implement this - we want to use Doug's code. [SNIP] >> Sure, but again, not everyone will be as wise as Martin - they'll just >> bail on us. They may even realize that there's a problem with their >> code, but there may be nothing they can do about it. > > People bailing on us is not a problem, as people *stuck with Sun-specific > code* will > (and should, IMHO) only use Sun's VM anyway. People blindly trusting us > because > we pretend to run some Sun-specific code according to some unspecified > interface > is a problem, both for them, as their code will obviously behave differently > from > what it expects, in subtle ways, if they are very unlucky, and for us, as we > have > to chase unreproducible behaviour as Sun changes their internal > interfaces around. See the sad story of Ant's chasing around of > sun.tools.javac.Main tail over and over again. Oh, come on. You talk like the rest of the spec is rock solid and perfectly defined. We're spelunking the RI through black-box testing all the time in our drive to get full behavioral compatibility. Adding a few utility classes that people are unfortunately using - knowingly or unknowingly - is simply good customer service, IMO. > > The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is > already taken by Sun. There is no point in trying to compete with them on > that, > or for the audience that wants and expects that. Been there, done that, > etc. ;) I think we'll have to continue to disagree on this one. I do want Harmony to work 100% like Sun to start because we want users to be able to effortlessly transition to Harmony. Software is nothing without users. 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
On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote: > > > Dalibor Topic wrote: > > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: > >> Dalibor Topic wrote: > >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: > Mikhail Loenko wrote: > > The problem is Base64 functionality is unavailable through the > > standard API, so people have a choice either use unportable sun.*, > > o.a.h.*, etc or create the coder from scratch > Understood, I think people are 'driven' to using the non-API types > though necessity rather than doing so by mistake. > >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath > >>> recommends using Apache Commons Codec for projects compatible with the > >>> Apache license. > >>> > >>> Amateur developers use non-standard classes because they are too lazy > >>> to think for themselves, and accordingly copy broken code around > >>> projects. > >>> Alas, a language designed to appeal to the masses naturally attracts a > >>> lot of people who'd have trouble producing portable code in any > >>> programming > >>> language. :) > >> I was being charitable. For sure many such usages can be easily > >> avoided, but in other cases no so easily; like CharToByteConverter would > >> require duplicating a wad of data, and I don't know of any third-party > >> impl. of Unsafe. > > > > Is there something that CharToByteConverter does that > > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen > > code using CharToByteConverter in years. > > > > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks > > to the JVM JSR not being ahead thinking enough to specify an API for > > low-level > > operations. It may or may not work depedending on how a VM interprets > > the non-existent spec for that class, so it is practically useless, > > unless it is running on the VM it was written on, i.e. Sun's. It may or > > may not work by chance, rather than by virtue. > > I think you are being too harsh here, but that notwithstanding, one of > the things we can do as open implementations is petition the EG to > actually define these in the spec once we show that there's a good > reason to do so, namely the independent implementations. The independant implementations are not using sun.misc.Unsafe. Why would anyone want to use an undocumented implementation-specific class from another implementation in their own? That makes no sense. There is no point in petitioning the EC to specify sun.misc.Unsafe since no one in their right mind uses it, except Sun, in the interna of their implementation. That's like asking the EC to specify org.kaffe.util.Ptr, or something equivalently pointless from DLRVM. What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, with a sane API that does not require computing field offsets manually, like sun.misc.Unsafe seems to do. ;) The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather simple bug in Doug Lea's java.util.concurrent implementation: using Sun-specific classes directly, rather than delegating to some java.util.concurrent.VMCompareAndSwap interface layer. That means anyone adopting the code needs to repeat the mistakes of Sun's implementation (which has, coincidentally, had a very straightforward remote execution exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. Yay. :/ Other than Doug's code, sun.misc.Unsafe does not matter at all, unless you want "remote-execution-exploit-for-remote-execution-exploit" compatibility. I believe that's too much to ask for. ;) > > > > > That holds in general for any code using implementation-specific > > interfaces. > > > >> We should appeal to app developers to change implementation dependent > >> code (even provide a recipe book of recommended solutions), but be > >> pragmatic about the need to run the current version. In many cases it > >> may be beyond the apps immediate sphere of influence (i.e. dependent > >> libraries). If everyone responded as quickly and effectively as Martin > >> we would have no worries. > > > > We've been doing that for years. See the GNU Classpath migration page in > > the Wiki that describes how to fix such broken code in many cases. Being > > 'pragmatic' solves nothing, it just encourages people to continue behaving > > in dumb ways, because their code still may run, somehow, even if there > > is no way for Harmony to ensure that it will behave as they expect from > > whatever buggy Sun JDK they are using to run it usually in the corner > > cases, because there is no spec, and there are no tests. > > > > Awarding incompetence doesn't solve the problem. That being said, kudos > > to Martin for fixing the bug in his code. Had we had a Base64 class, > > that bug wouldn't have showed up, and his code would have failed > > elsewhere, or behaved differently on another VM. With the fix, his code > > is portable, behaves
Re: [general] compatibility packages
Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: >> Dalibor Topic wrote: >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: > The problem is Base64 functionality is unavailable through the > standard API, so people have a choice either use unportable sun.*, > o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath >>> recommends using Apache Commons Codec for projects compatible with the >>> Apache license. >>> >>> Amateur developers use non-standard classes because they are too lazy >>> to think for themselves, and accordingly copy broken code around projects. >>> Alas, a language designed to appeal to the masses naturally attracts a >>> lot of people who'd have trouble producing portable code in any programming >>> language. :) >> I was being charitable. For sure many such usages can be easily >> avoided, but in other cases no so easily; like CharToByteConverter would >> require duplicating a wad of data, and I don't know of any third-party >> impl. of Unsafe. > > Is there something that CharToByteConverter does that > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen > code using CharToByteConverter in years. > > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks > to the JVM JSR not being ahead thinking enough to specify an API for > low-level > operations. It may or may not work depedending on how a VM interprets > the non-existent spec for that class, so it is practically useless, > unless it is running on the VM it was written on, i.e. Sun's. It may or > may not work by chance, rather than by virtue. I think you are being too harsh here, but that notwithstanding, one of the things we can do as open implementations is petition the EG to actually define these in the spec once we show that there's a good reason to do so, namely the independent implementations. > > That holds in general for any code using implementation-specific > interfaces. > >> We should appeal to app developers to change implementation dependent >> code (even provide a recipe book of recommended solutions), but be >> pragmatic about the need to run the current version. In many cases it >> may be beyond the apps immediate sphere of influence (i.e. dependent >> libraries). If everyone responded as quickly and effectively as Martin >> we would have no worries. > > We've been doing that for years. See the GNU Classpath migration page in > the Wiki that describes how to fix such broken code in many cases. Being > 'pragmatic' solves nothing, it just encourages people to continue behaving > in dumb ways, because their code still may run, somehow, even if there > is no way for Harmony to ensure that it will behave as they expect from > whatever buggy Sun JDK they are using to run it usually in the corner > cases, because there is no spec, and there are no tests. > > Awarding incompetence doesn't solve the problem. That being said, kudos > to Martin for fixing the bug in his code. Had we had a Base64 class, > that bug wouldn't have showed up, and his code would have failed > elsewhere, or behaved differently on another VM. With the fix, his code > is portable, behaves in the same way on any VM, and may even be faster > than a vm-specific 'just for compatibility' implementation. > > There is no downside to simply fixing the buggy code. Sure, but again, not everyone will be as wise as Martin - they'll just bail on us. They may even realize that there's a problem with their code, but there may be nothing they can do about it. > >>> On a side note, I seem to recall reading on Sun's javac engineer's blog >>> that javac won't allow access to sun internal classes sooner or later, >>> so idiot-proofing class libraries may not be very useful, anyway, >>> as people will have to rewrite such code, or preferrably, throw it away. >> It will be interesting to see what havoc is unleashed by attempts to >> reduce the visibility of sun internal packages by the compiler and at >> runtime. > > I assume it will just cause unmaintained libraries to be substituted by > maintained ones, as people trade up to higher quality implementations of > functionality they need. Code that uses sun.* classes is a bad smell, to > invoke Fowler. If it doesn't get fixed, just get rid of it, and use > something else that doesn't stink. Yah, but I think it's insane to enforce restrictions on one company's package namespace in the compiler. This should be a general feature :) 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 (was: Re: BASE64Encoder class missing?)
On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: > Dalibor Topic wrote: > > On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: > >> Mikhail Loenko wrote: > >>> The problem is Base64 functionality is unavailable through the > >>> standard API, so people have a choice either use unportable sun.*, > >>> o.a.h.*, etc or create the coder from scratch > >> Understood, I think people are 'driven' to using the non-API types > >> though necessity rather than doing so by mistake. > > > > Hardly. Many replacements for Base64 exists, for example GNU Classpath > > recommends using Apache Commons Codec for projects compatible with the > > Apache license. > > > > Amateur developers use non-standard classes because they are too lazy > > to think for themselves, and accordingly copy broken code around projects. > > Alas, a language designed to appeal to the masses naturally attracts a > > lot of people who'd have trouble producing portable code in any programming > > language. :) > > I was being charitable. For sure many such usages can be easily > avoided, but in other cases no so easily; like CharToByteConverter would > require duplicating a wad of data, and I don't know of any third-party > impl. of Unsafe. Is there something that CharToByteConverter does that CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen code using CharToByteConverter in years. Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. That holds in general for any code using implementation-specific interfaces. > > We should appeal to app developers to change implementation dependent > code (even provide a recipe book of recommended solutions), but be > pragmatic about the need to run the current version. In many cases it > may be beyond the apps immediate sphere of influence (i.e. dependent > libraries). If everyone responded as quickly and effectively as Martin > we would have no worries. We've been doing that for years. See the GNU Classpath migration page in the Wiki that describes how to fix such broken code in many cases. Being 'pragmatic' solves nothing, it just encourages people to continue behaving in dumb ways, because their code still may run, somehow, even if there is no way for Harmony to ensure that it will behave as they expect from whatever buggy Sun JDK they are using to run it usually in the corner cases, because there is no spec, and there are no tests. Awarding incompetence doesn't solve the problem. That being said, kudos to Martin for fixing the bug in his code. Had we had a Base64 class, that bug wouldn't have showed up, and his code would have failed elsewhere, or behaved differently on another VM. With the fix, his code is portable, behaves in the same way on any VM, and may even be faster than a vm-specific 'just for compatibility' implementation. There is no downside to simply fixing the buggy code. > > On a side note, I seem to recall reading on Sun's javac engineer's blog > > that javac won't allow access to sun internal classes sooner or later, > > so idiot-proofing class libraries may not be very useful, anyway, > > as people will have to rewrite such code, or preferrably, throw it away. > > It will be interesting to see what havoc is unleashed by attempts to > reduce the visibility of sun internal packages by the compiler and at > runtime. I assume it will just cause unmaintained libraries to be substituted by maintained ones, as people trade up to higher quality implementations of functionality they need. Code that uses sun.* classes is a bad smell, to invoke Fowler. If it doesn't get fixed, just get rid of it, and use something else that doesn't stink. cheers, dalibor topic > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
