While reviewing the class file structure of
java.lang.Object in Sun's 1.4.2_06 JDK, I
noticed that its major_version field is 48.
The JVM Spec version 2 says, Implementations
of version 1.2 of the Java 2 platform can
support class file formats of versions in the
range 45.0 through 46.0 inclusive.
[Original Message]
From: Sven de Marothy [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Date: 6/4/05 3:49:37 PM
Subject: Re: [arch] How much of java.* and friends does Harmony need
towrite. Was: VM/Classlibrary interface
On Sat, 2005-06-04 at 21:44 +0200, Santiago Gala wrote:
We don't necessarily have to do it here, but given the wide and deep
community here, we might be able to get some benefit through
coordination and networking.
geir
On Jun 1, 2005, at 9:11 PM, Leo Simons wrote:
On 01-06-2005 18:27, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I thought
On Jun 3, 2005, at 7:18 AM, Peter Edworthy wrote:
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
I agree, but ClassPath has its interface classes in Java.lang
On Jun 3, 2005, at 1:06 PM, Sven de Marothy wrote:
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
By writing _only_ java.lang and java.lang.*,
we can
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
I suspect the motivation behind the original post by Peter was more
about formal modularization of the class library than general java
package separation. I think that there has been some good work in
this area in other places, such as larger scale J2EE systems via OSGi
or -ish.
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.
Dan == Dan Lydick [EMAIL PROTECTED] writes:
Dan What gives? Where can I find correct descriptions of
Dan the latest .class file definitions for JDK 5?
Here's one source I found via google. Not sure if it is the most up
to date.
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
El dom, 05-06-2005 a las 02:00 -0500, Dan Lydick escribi:
[Original Message]
From: Santiago Gala [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Date: 6/4/05 1:22:40 PM
Subject: Re: Summer of Code, something for Harmony?
...snip...
El jue, 02-06-2005 a las 02:11
El dom, 05-06-2005 a las 01:56 -0500, Dan Lydick escribi:
(...)
I suppose I need to do some more homework then.
If GNU Classpath is used without modification for
numerous VM's, then great! Ultimately, what I am
A few classes need to be modified:
- jamvm (from README): A number of classes
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
Hi,
It seems like there is a little bit of heat being generated by this
topic due to confusion. While Geir has not actually stated this anywhere
I assume that the reason that he is advocating for a VM interface that
is independent of GNU Classpath is because he has plans to interoperate
with
One potential use is for companies (and individuals) to work around
particular performance limitations and bugs in the Sun VM while
keeping the libraries they know inside and out. I imagine that could
become common if Harmony ends up being as modular as we all hope.
I am curious as to how
On Jun 5, 2005, at 9:32 PM, Peter Donald wrote:
Hi,
It seems like there is a little bit of heat being generated by this
topic due to confusion. While Geir has not actually stated this
anywhere I assume that the reason that he is advocating for a VM
interface that is independent of GNU
On Jun 5, 2005, at 10:06 PM, Craig Blake wrote:
One potential use is for companies (and individuals) to work around
particular performance limitations and bugs in the Sun VM while
keeping the libraries they know inside and out. I imagine that
could become common if Harmony ends up being
Bytecode verifiers appear to be one thing where the Harmony project
could contribute some work in standardising interfaces.
At the moment I know of two open source verifiers written in Java: BCEL
(http://jakarta.apache.org/bcel/index.html, Apache Licence) and ASM
(http://asm.objectweb.org/, BSD
Hi Steve and all,
| The approach of using C Compiler generated code rather than writing a
| full compiler appeals to me:
| http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
From: Steve Blackburn [EMAIL PROTECTED]
Date: Tue, 24 May 2005 21:08:05 +1000
They automatically build themselves
40 matches
Mail list logo
