You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
Regards,
Jeroen
-Original Message-
From: Aaron Hamid [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 20:44
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] How much of
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism. It is possible (since I have done it in my OSGi framework) to
create a class loader
Richard S. Hall wrote:
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism.
No, that does not solve the problem of getting access to the
Jeroen Frijters wrote:
No, that does not solve the problem of getting access to the internals
of public classes. For example, java.lang.VMThread needs to access
package private methods in java.lang.Thread.
You are correct, if your design is such that you need private access
both ways,
Jeroen I think there are at least two perceived problems being voiced:
* aversion to the idea of polluting a standard library distribution (e.g.
Classpath) with VM-specific interface implementations. Although there have been
assurances that such work is trivial and the interface is
On Jun 3, 2005, at 6:39 PM, Dalibor Topic wrote:
That's a rather weird thing to standardise, being the internals of
a binding
between the library and the VM, and necessarily something that is
in flux, as
VMs and class libraries change internally. And they do change quite
a bit over
On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:
On Fri, 2005-06-03 at 14:01 -0500, Dan Lydick wrote:
Naw, but have you ever looked into how to design and
construct a JVM? The fundamental classes like java.lang
can typically have implementation-specific requirements,
so I am trying to
On Jun 3, 2005, at 5:22 PM, Aaron Hamid wrote:
I'm sort of confused by this discussion also.
It seems to be about at what granularity we start introducing vm-
specific interfaces/implementations. At some point the class
library has to interface with the VM. We can do that at a very
On Jun 3, 2005, at 4:34 PM, Tom Tromey wrote:
Dan == Dan Lydick [EMAIL PROTECTED] writes:
Dan That includes the language protection features like Geir's
Dan example of package private, which are an interesting game of
Dan navigating class file structures with reflection, etc. I've
Dan
Geir Magnusson Jr. wrote:
Dan That includes the language protection features like Geir's
Dan example of package private,
...
Sorry for not following up on some of my previous remarks on
such things. But briefly, here's a trick that works,
without any need for language-based module
From what I understood from this thread (and of course my understanding
could be wrong), there is some contention over where to hide this
Classlib-VM interface and implementation so that user code is least able
to use/abuse it. One suggestion was to use existing package visibility
modifiers
On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote:
That's not fair. I told you that *I* think that extending java.lang
is a *bad idea*. You many not agree, but that's not the same is
NIH. That doesn't mean that java.lang.VMObject can't be move to
another package,
On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote:
On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:
AFAIK there are
no other class libraries out there which you'll legally be able to
distribute with Harmony. So why create flexibility when there aren't
options?
Are you
+1 to that!
On Sun, 2005-06-05 at 11:53 -0400, Aaron wrote:
From what I understood from this thread (and of course my understanding
could be wrong), there is some contention over where to hide this
Classlib-VM interface and implementation so that user code is least able
to use/abuse it.
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Geir That's not fair. I told you that *I* think that extending java.lang
Geir is a *bad idea*.
I still don't understand why you think this.
Could you explain what problem might arise?
Geir Also, I don't know what the 1.4 and 1.5 Java API
On Jun 5, 2005, at 1:30 PM, Sven de Marothy wrote:
On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote:
That's not fair. I told you that *I* think that extending java.lang
is a *bad idea*. You many not agree, but that's not the same is
NIH. That doesn't mean that
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Dan I've
Dan never tried that, but Geir is right, I think it can be done if
Dan you try hard enough.
In the second case, when there is a security manager, then, no, you
cannot get around the access controls, even with reflection.
Geir Why
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
True, except I really hate extending java.lang. :)
What do you mean by extending java.lang? GNU Classpath does not
extend
java.lang (for any reasonable definition of extend). Having package
private classes is not extending.
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
What do you mean by extending java.lang? GNU Classpath does not
extend java.lang (for any reasonable definition of extend). Having
package private classes is not extending.
Geir Why do you say that? Suppose for J2SE 6, the EG adds the public
On Jun 5, 2005, at 1:45 PM, Sven de Marothy wrote:
On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote:
On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:
AFAIK there are
no other class libraries out there which you'll legally be able to
distribute with Harmony. So why create
On Jun 5, 2005, at 2:05 PM, Tom Tromey wrote:
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Geir That's not fair. I told you that *I* think that extending
java.lang
Geir is a *bad idea*.
I still don't understand why you think this.
Could you explain what problem might arise?
Sun
On Jun 5, 2005, at 2:12 PM, Jeroen Frijters wrote:
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
True, except I really hate extending java.lang. :)
What do you mean by extending java.lang? GNU Classpath does not
extend
java.lang (for any reasonable definition of extend). Having
On Jun 5, 2005, at 2:06 PM, Tom Tromey wrote:
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Dan I've
Dan never tried that, but Geir is right, I think it can be done if
Dan you try hard enough.
In the second case, when there is a security manager, then, no, you
cannot get around the
Geir Magnusson Jr. wrote:
On Jun 5, 2005, at 2:12 PM, Jeroen Frijters wrote:
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
True, except I really hate extending java.lang. :)
What do you mean by extending java.lang? GNU Classpath does not
extend
java.lang (for any reasonable
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
I still don't understand why you think this.
Could you explain what problem might arise?
Geir Sun adds java.lang.VMObject as a public class (ok, farfetched) or
Geir adds it as a private class (not so farfetched).
Ok, this is the scenario.
I actually had not considered this issue which would seem to warrant
these classes living in the same package. But can not an equivalent
solution be constructed such that the implementations of these public
classes can hand the VM* classes references to internal structures (and
vice versa)
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Yes, 1.5 *will* add new requirements to the VM interface. But the
Classpath VM interface isn't some immutable static thing either.
All I'm saying here is: how about crossing that bridge when you get
there, instead of deciding out of hand that
On Sun, 5 Jun 2005, Geir Magnusson Jr. wrote:
Also from time to time the VM interface has to be extended for new
VMs, which have different needs. This is one reason that the
interface isn't yet stable, even for 1.4.
It would be interesting to know why and how it was extended - there's
On Sun, Jun 05, 2005 at 06:20:37AM -0300, Geir Magnusson Jr. wrote:
On Jun 3, 2005, at 6:39 PM, Dalibor Topic wrote:
That's a rather weird thing to standardise, being the internals of
a binding
between the library and the VM, and necessarily something that is
in flux, as
VMs and
On Sun, Jun 05, 2005 at 02:20:53PM -0300, Geir Magnusson Jr. wrote:
On Jun 5, 2005, at 1:45 PM, Sven de Marothy wrote:
On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote:
On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:
AFAIK there are
no other class libraries out there
On Fri, 2005-06-03 at 14:01 -0500, Dan Lydick wrote:
Naw, but have you ever looked into how to design and
construct a JVM? The fundamental classes like java.lang
can typically have implementation-specific requirements,
so I am trying to focus on isolating these items from
the rest of the
El sb, 04-06-2005 a las 17:59 +0200, Sven de Marothy escribi:
(...)
So why create flexibility when there aren't
options?
to enable the development of other options?
without arriving to flexibility syndrome, good interfaces enable
competing implementations.
Your question has exactly the same
32 matches
Mail list logo
