I just took a quick look in EF's source tree (only at the names of the
files, though) and it appears that they have all the classes needed for
Classpath integration. I would guess that this integration will be at
least as easy as Japhar was.
The Throwable bit might be the hardest part, as it se
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Stuart Ballard
>
> them>
>
> I just took a quick look in EF's source tree (only at the names of the
> files, though) and it appears that they have all the classes needed for
> Classpath integration. I would guess that this integrati
: From: "John Keiser" <[EMAIL PROTECTED]>
: Date: Mon, 25 Jan 1999 10:59:34 -0700
:
: Throwable I plan to move into the VM Integration API pretty soon.
: gnu.vm.stack.* will go away. It's been on my plate for a while, but I
: haven't gotten around to it. I'll see about it Wed. night, and make s
Jochen Hoenicke wrote:
>
> I'm currently using gnu.vm.stack.StackTrace in
> java.util.ResourceBundle, to get the ClassLoader of the calling method
> (which might be the system class loader). SUN JDK uses a native
> method getClassContext() for this.
>
> Some suggestion how this should be solved
> From: Jochen Hoenicke
>
> : From: "John Keiser" <[EMAIL PROTECTED]>
> : Date: Mon, 25 Jan 1999 10:59:34 -0700
> :
> : Throwable I plan to move into the VM Integration API pretty soon.
> : gnu.vm.stack.* will go away. It's been on my plate for a while, but I
> : haven't gotten around to it. I'l
John Keiser wrote:
>
> (Oh, and Stuart ... saw your mail while I was writing this. Take note that
> he's trying to call these methods from java.util, not java.lang, so we
> simply cannot avoid security risks.)
Yeah, I saw that. But I was under the impression that *native* code
isn't subject to
Stuart Ballard <[EMAIL PROTECTED]> writes:
> John Keiser wrote:
> >
> > (Oh, and Stuart ... saw your mail while I was writing this. Take note that
> > he's trying to call these methods from java.util, not java.lang, so we
> > simply cannot avoid security risks.)
>
> Yeah, I saw that. But I was
Stuart Ballard wrote:
> I just took a quick look in EF's source tree (only at the names of the
> files, though) and it appears that they have all the classes needed for
> Classpath integration. I would guess that this integration will be at
> least as easy as Japhar was.
Allow me to point out th
John Keiser wrote:
> > We'll just need to make it possible to specify native libraries
> > that have higher
> > precedence than EF's built-in versions.
> >
>
> That'd work, too. Hmm. How could that be done automatically and securely,
> though? There would have to be the following precedence fo
Scott Furman wrote:
>
> John Keiser wrote:
>
> > Does Electrical Fire currently work with JDK (and implement its native
> > methods)?
>
> Currently, to run EF you need to download the official JDK1.2 jar file.
>
> > In that case, it shouldn't take long to port. Japhar was
> > designed that w
Good afternoon to everyone. I have for some time now been thinking that a
free implementation of the Java class libraries should exist in some form
or another, but never knew of the Classpath project. I am really excited
to see this happening.
I looked over much of the code last night and am ce
William Tipton wrote:
> I looked over much of the code last night and am certainly impressed with
> not only the sheer amount of code written but also the quality of the code
> as well as its documentation. This is definitly a project to which I'd
> love to contribute, but I have a few questions
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> I think at this point we are all targeting Java 1.2. Certainly 1.1
> compliance is a must, but I am personally doing as much 1.2 as I
> can.
Our AWT is targeting Java 1.1. 1.2 support will come after 1.1 is
working.
--
Paul Fisher * [EMAIL PROTEC
> From: William Tipton [mailto:[EMAIL PROTECTED]]
>
> Good afternoon to everyone. I have for some time now been thinking that a
> free implementation of the Java class libraries should exist in some form
> or another, but never knew of the Classpath project. I am really excited
> to see this hap
I wrote a GPL'ed version of the complete vecmath library when the very
first spec came out. I guess that was almost a year ago (June 1997).
Anyway, I still have the code. I had tested each function and it was
working great. I released it on the net but I don't think it got
archived anywhere. I
>As long as StackTrace and StackFrame are working right now, we can use
>those. Incidentally, I didn't think that StackTrace and such were yet
>implemented in Japhar ... are ResourceBundles working?
ResourceBundle's work (if you are loading from plain files and not from a
zip file). Stack trace
Jochen: Stuart suggested a nice way to get around the problem and allow the
removal of the superfluous StackTrace and StackFrame classes in the short
term. I didn't understand it at first, but the last message helped.
The solution he came up with was to go out to a native method in java.util
and
>I wrote a GPL'ed version of the complete vecmath library when the very
>first spec came out. I guess that was almost a year ago (June 1997).
>Anyway, I still have the code. I had tested each function and it was
>working great. I released it on the net but I don't think it got
>archived anywhere
> From: Scott Furman [mailto:[EMAIL PROTECTED]]
>
>
> "Aaron M. Renn" wrote:
>
> > If it is (a), then you might want to make use of the Classpath libraries
> > directly. This is really not too hard, but requires some work.
> Basically
> > we expect that some of the lowest level functions of the
John Keiser wrote:
> Does Electrical Fire currently work with JDK (and implement its native
> methods)?
Currently, to run EF you need to download the official JDK1.2 jar file.
> In that case, it shouldn't take long to port. Japhar was
> designed that way, too, and the port Aaron did didn't ta
> From: Scott Furman [mailto:[EMAIL PROTECTED]]
>
>
> John Keiser wrote:
>
> > Does Electrical Fire currently work with JDK (and implement its native
> > methods)?
>
> Currently, to run EF you need to download the official JDK1.2 jar file.
>
> > In that case, it shouldn't take long to port. Japh
John Keiser wrote:
> The VM doesn't already implement Object--thus the need for VMObject, which
> implements the trivially few methods that actually require the VM's input.
> The point of the VM interfacewas to make the job as easy as possible for the
> VM to implement things (read: as few classe
> From: Scott Furman [mailto:[EMAIL PROTECTED]]
>
> John Keiser wrote:
>
> > The VM doesn't already implement Object--thus the need for
> VMObject, which
> > implements the trivially few methods that actually require the
> VM's input.
> > The point of the VM interfacewas to make the job as easy as
23 matches
Mail list logo
