John Keiser writes:
JNILINK is useless. Use it no longer.
Well, I do not feel so bad know that I did not
have the time (yet) to get into it...
b.
I'd install the libraries in the JVM specific "lib" directory.
Kaffe 1.0b1 use of the JDK 1.2 Invocation API:
vm_args.librarypath = "/opt/local/share/kaffe/lib/i386-linux/";
I take it that this is (an example of) the directory referred
to above?
Christoph Toshok writes:
Kaffe 1.0b1 use of the JDK 1.2 Invocation API:
vm_args.librarypath = "/opt/local/share/kaffe/lib/i386-linux/";
this isn't the 1.2 invocation API. it's a non-standard extension to the
1.1 invocation API.
They named the struct JavaVMInitArgs, not
Brian Jones writes:
Aaron, you may be interestd in DOC++.
If that's
http://www.zib.de/Visual/software/doc++/index.html
that has not been updated in years last time I looked.
It has quite a few bugs, and is not compatible between
the HTML and LaTeX backends - you have to take a
decision. I was
Bernd Kreimeier writes:
http://www.zib.de/Visual/software/doc++/index.html
that has not been updated in years last time I looked.
Checked today, gotta correct myself. It has been updated
recently - ChangeLog lists:
Fri Jun 31 1998
Tue Feb 3 1997
Mon Dec 23 1996
Sources (Sep 15th) do
Moses DeJong writes:
Does anyone know what JNI problem this fixes?
Yeah, well. Brian forwarded my message, which says:
problems with JNI/Invocation with JDK 1.1.7v1a+native
for apps that use libdl.so,
Invocation does not work in certain patterns. The script
comment lists those:
# The
Paul Fisher writes:
Have you looked at DOC++ as a JavaDoc replacement? Does it measure up?
For some reason, I guess the last time I looked at it, it didn't
support JavaDoc, but it appears to now. The bad news is that it's
non-free software. The authors make a contradictory statement
Aaron M. Renn writes:
Per usual I was thinking
of something more ambitious. To the best of my knowledge there is no
standard parsing API. I was thinking that there should be a "parselet" API
for applications that need to parse Java source files (JavaDeps, JavaDoc,
etc).
This is an
I am looking for a Linux tool to generate Java source
from C. I am aware of C2J/C2J++. What I need would
have to be used repeatedly - the code will be
maintained in C. Changing the C code once to match
converters restrictions is feasible.
Short of hacking C2J++ - any recommendations?
Michael Emmel writes:
I am looking for a Linux tool to generate Java source
from C. I am aware of C2J/C2J++.
It's not possible.
Don't even think port C program to java
without complete redesign of basic programs
structures and data.
simple translating of even
Daniel Rall writes:
This is for whoever was asking about a Java/C gadget.
http://www.irisa.fr/compose/harissa/
Nah, this is Java to C.
What I want is a stock dumb tool that automatically
creates an ugly Java source from a C source. The
idea is to map all C functions to static methods
of a
Paul Fisher writes:
whether anyone is working on the 2D and 3D API support?
I don't believe that anyone is working on 3D support. I've become
familiar with the 2D API, and if no one else tackles it before I get
to it, I'll begin work after the 1.1 AWT is complete. (which will be a
Godmar Back writes:
Magician is a Java OpenGL API including implementations
for Linux, Win32, Mac and other OS, supporting JNI,
RNI, and Netscape's JRI. In contrast to Java3D, this
is a portable, popular, efficient solution.
From this perspective, I think that a Java binding for
Edward Ribeiro writes:
Where we can get information about Java OpenGL bindings?
In theory, www.opengl.org would be The Place. In practice,
I can't remember something there short of the occasional
archived news. www.arcana.co.uk keeps HTML mailing list
archives of the ARB/JavaGL discussion
John Keiser writes:
I remember a while back someone knew
of a good javadoc-like tool for C++.
doc++? Used to be:
http://www.zib.de/Visual/software/doc++/
It is not a *good* javadoc like tool IMO. It is a javadoc
like tool, you can restrict yourself to javadoc compatible
tags or use
John Keiser writes:
I am curious: just how tied to Java is this, besides being written in it?
What kind of work would it take to make it work with something like C/C++?
A generic system that could generate doc-comments and do cross-linking and
todo lists would be a very useful thing for
Paul Fisher writes:
Is there a free implementation of Swing avalible
The GNU Classpath project URL:http://www.classpath.org has started
work on a free implementation of Swing; however, it will be some time
before it's completed.
Is this using your AWT? I gather from Kaffe's source
Tom Tromey writes:
I believe we currently require GNU make, sh, a Java runtime, and a
Java compiler. It would probably be possible to get rid of the GNU
make dependency. I'm not particularly motivated to do it.
There is a JavaMake ( and a JavaDepend
SOT, but you have prolly solved this already...
How do you prevent somebody taking a (L)GPL'ed or Open
source for a JVM and/or core classes, hacking backdoors
and trojan horses into it, and deploying it? To be
more precise: sure it'll be either obvious (source is
there) or illegal (violation of
John Keiser writes:
When you get around to dealing with multiple VMs--I know you have a lot
on your plate right now--I suggest you allow a configure option: --single-vm
or --multi-vm.
Second that. Actually, I came to think of Japhar more as
a (potential) toolkit to built and
John Keiser writes:
In short, yes, once I put the LGPL copyright notice in there (which I
haven't yet) it is usable for anyone. I'll send you a copy tonight or
tomorrow once I slap those headers on. I don't think anonymous CVS access
is set up yet, unfortunately :(
Appreciated. If
John Keiser writes:
The problem with the public static final boolean variable
is, you have to edit the source every time you want to change it.
Different classpaths, different Config.java first?
Yeah, well - last time I tried, javac seemed to screw up
dependencies to different packages
Maxim Kizub writes:
Just a few notes about class collecting and re-loading.
I could add something else here. I tried to make my
C++ classes for JVM/JClass/JObject fit for use with
multiple JVM's from the same C application. As none
of the field/methodID information etc. is supposed
to be
Wes Biggs writes:
I think explicit imports help readability anyway
Agreed.
of the classes to check). The utility would look for "import x.y.z",
check if the file x/y/z.java exists, and if so insert a make dependency
line for x/y/z.class accordingly.
Taking the current classpath into
John Keiser writes:
I've been doing some heavy thinking about jnilink.
I must be missing something here. What exactly is jnilink?
Specific to Classpath, used internally to implement the
native parts?
LINK_LinkClass(env,theClass,"java/lang/Integer");
I do not think that adding tags is the right thing
to do, ultimately. I have to dig out some weave/tangle
references with respect to SGML, but for the moment
just for SGML: www.sgmltools.org
What I think is that, within the /** javadoc */ pieces,
SGML should be used instead of HTML. The most
Paul Fisher writes:
which values does the JNI spec say can be cached?
jfieldID's and jmethodID's. See page 17 of the JNI spec. "Accessing
Fields and Methods". As long as you keep a live reference to the
underlying class, the VM ensures that your jfieldIDs and jmethodIDs
are valid.
Stuart Ballard wrote:
One of the goals of the Classpath project is to remain VM-neutral.
Using JNI supports this goal.
Doesn't this settle the issue then?
Or, we could implement one in terms of the other, or implement an
abstraction layer over the top that allowed C code to use whichever
Mark Wielaard wrote:
When you have not agreed to a license/contract the publisher can not
force you to do or don't do anything with the information. You can
use the ideas for everything you want as long as you don't violate
the copyright by directly copying large portions and distributing
Paul Fisher wrote:
Sun is taking the stance that copyright on specifications prohibits
implementation of these specifications w/o a license.
Sun does indeed take this bogus stance. We choose to ignore it.
Sun interprets copyright law far too broadly.
Interesting. I don't know whether
Paul Fisher wrote:
/* As a special exception, if you link this library with other files
to produce an executable, this library does not by itself cause
the resulting executable to be covered by the GNU General Public
License. This exception does not however invalidate any other
Stuart Ballard wrote:
This sounds like a good plan... I never heard of a GNU/Linux system that
didn't include Perl, but certainly some other unixes don't.
One of the implications of Java for free software is that it could
eventually make large inroads into Win32/other non-UNIX. Vice versa,
Per Bothner writes:
You need to analyze CNI (i.e. C++) source code. You need to recognize
CNI field and method references, which are just C++ field/method
references. That implies a semantic analysis of the C++ code.
Yep.
The logical tool is a compiler. The only C++ compiler we have
I (ever so briefly) looked at the GCJ FAQ and pages
trying to find out whether compilation of CNI code
to JNI compliant DLL's is possible, and/or on the
agenda of the GCJ project. Any comments appreciated,
thanks.
b.
34 matches
Mail list logo
