Re: build ideas
> Additions? Contrary notions? Devil's advocate? For my own JVM running on the ETH-Oberon System (thus no C compiler available and no UNIX-like platform) I need only the .class files and the data files. I also need to compile a few own classes like VMSystem. One option is to have a glibj.zip with the whole classpath, recompile only my own classes and add them to glibj.zip. Personally I rather prefer to build everything directly with my own classes. A side note: I tried to build classpath last week. Apparently config.in is in the wrong directory (classpath root instead of include). -Patrik -- Patrik Reali, [EMAIL PROTECTED] http://www.inf.ethz.ch/personal/reali/ http://www.oberon.ethz.ch/native/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Error in FileInputStream?
One of the FileInputStream constructors is
implemented as follows:
public
FileInputStream(FileDescriptor fd) throws SecurityException
{
// Hmmm, no other exception but this one to throw, but if the descriptor
// isn't valid, we surely don't have "permission" to read from it.
if (!fd.valid())
throw new SecurityException("Invalid FileDescriptor");
SecurityManager sm = System.getSecurityManager();
if (sm != null)
{
// try
//{
//sm.checkRead(fd);
throw new SecurityException("ffo");
//}
// catch (AccessControlException e)
//{
// throw new SecurityException(e.getMessage());
//}
}
native_fd = fd.getNativeFD();
}
When the JVM boots, System.in is allocated using a file descriptor.
If the security manager is already installed, then an exception
is thrown.
Is there a reason, for assuming that the security manager is not
available at this point or is this only some forgotten code that,
by chance, nobody else but me run into?
-Patrik
--
Patrik Reali, [EMAIL PROTECTED]
http://www.inf.ethz.ch/personal/reali/
http://www.oberon.ethz.ch/native/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Hi! On Mit, 17 Okt 2001 Brian Jones wrote: > I'm seeking suggestions or ideas from individuals about how they would > like to be able to build Classpath. I guess two cases exist, building > >from CVS and building from a release. I'll start the discussion with my > suggestions but I'm hoping for others and some concensus at the end. > > Like other GNU projects, I would like to continue to use the > automake/autoconf system for driving the compilation of Classpath. I'm not sure if I understand all your arguments for this, but I can tell you that moving from make to Ant was a huge step forward for the ArgoUML project (to which I'm contributing a bit). I don't think anyone wants to go back to the old make tools. > For releases I'd like to continue to distribute compiled .class files > and generated JNI headers. If you need libs like GTK, I'd rather like to see a distribution with automatic dependency checking, like a rpm file (I'm using RedHat Linux) or so. > I want CVS builds to generate JNI headers > and .class files relying only on free software. There exists a need > within our community to generate .class files without compiling native > libraries and I'd like that to be easier... it seems to me that to be > successful this must be faster than 'jikes -d /tmp `find java gnu > vm/reference -regex ".*\.java$"` or some working equivalent. I guess jakarta-ant is the answer to this problem... http://jakarta.apache.org/ant/ I thought someone is already working on a build.xml file? Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Brian said: > I want CVS builds to generate JNI headers > and .class files relying only on free software. There exists a need > within our community to generate .class files without compiling native > libraries and I'd like that to be easier... it seems to me that to be > successful this must be faster than 'jikes -d /tmp `find java gnu > vm/reference -regex ".*\.java$"` or some working equivalent. Andreas said: >I guess jakarta-ant is the answer to this problem... > http://jakarta.apache.org/ant/ >I thought someone is already working on a build.xml file? Personally, I don't like Ant. It's not *free* software either. There's not much you can do with Ant that can't be done with Make (given a little thought). Ant is also very Java centric, Classpath has a lot of C (and C++ if we include the GCJ stuff). Make is perfect for those languages. Brian, would you like to check out the Paperclips and Classpathx make files? They use the the @filelist convieniance to facilitate better make control over java projects. Nic Ferrier ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Nic Ferrier wrote: > Ant is also very Java centric, Classpath has a lot of C (and C++ if we > include the GCJ stuff). Make is perfect for those languages. Yes, but on the other hand 'make' is very C-centric (meaning that it sees dependencies as tree, not as graph). Fitting it to java is like putting a nail with screwdriver (?or was it other way around? - these idioms...) For me main benefit of 'make' over 'ant', is that with 'make' and jikes you don't need a java set up to compile code. Artur ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
[EMAIL PROTECTED] writes: > A side note: I tried to build classpath last week. Apparently > config.in is in the wrong directory (classpath root instead of > include). In CVS it is in include/, so I'm not sure how it ended up in root for you. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
I remember doing the following suggestion before on this list; you can also find an implementation of my idea in Sablepath (see http://sourceforge.net/project/showfiles.php?group_id=5523&release_id=52287 ) My suggestion is to use the GNU auto* tools for the native code, and use Ant for the Java code. See comment below. On Wed, Oct 17, 2001 at 01:51:54PM +0100, Nic Ferrier wrote: > Personally, I don't like Ant. It's not *free* software either. I think you are mistaken here. Ant is indeed free software (BSD like license with adv. clause), but it is not Copyleft software (GNU GPL). If you don't want to use non-GPL software, you'll get in trouble: the Jikes compiler is not GPLed either, and it has a license which is incompatible with the GPL. (See http://www.gnu.org/licenses/license-list.html for a good explanation of all this). So, I see no reason not to use Ant for the Java stuff. Yes, it is a Java centric tool, but this is what you want here. One could say that the GNU auto* tools are C/C++ and traditional *NIX languages centric; they are pretty ill suited for Java (I don't intend to open a debate on this, I am just stating my *personal* view). So, please give a look at Sablepath, which is divided into 2 packages: sablepath-classes : the Java code, Ant based build sablepath-libs : the native code, GNU auto* based build This would satisfy the various groups using Classpath. Groups that don't need the native stuff would simply get the *-classes package, people needing standard JNI native stuff would download the *-lib package, you could even add different native implementations, like *-cni-lib, etc. Etienne -- Etienne M. Gagnonhttp://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Error in FileInputStream?
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > When the JVM boots, System.in is allocated using a file descriptor. > If the security manager is already installed, then an exception > is thrown. > > Is there a reason, for assuming that the security manager is not > available at this point or is this only some forgotten code that, > by chance, nobody else but me run into? It looks like code that was commented out to get around another bug or to work around the fact that something wasn't implemented yet. Probably should be cleaned up. I'll try to do it in the next couple days. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ "We have a choice, either to change the way we live, which is unacceptable, or to change the way that they live, and we chose the latter." - Sec. of Defense Donald Rumsfeld, News briefing, 2001-09-18 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Nic Ferrier <[EMAIL PROTECTED]> writes: > Personally, I don't like Ant. It's not *free* software either. > > There's not much you can do with Ant that can't be done with Make > (given a little thought). Last I checked this is quite true. > Ant is also very Java centric, Classpath has a lot of C (and C++ if we > include the GCJ stuff). Make is perfect for those languages. I think Ant could only be useful for Java. I would not want to use it for making shared libraries. > Brian, would you like to check out the Paperclips and Classpathx make > files? They use the the @filelist convieniance to facilitate better > make control over java projects. I'll do that. -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Eric Blake <[EMAIL PROTECTED]> writes: > I'm all for a way to compile the .class files without the shared > libraries. I develop on a cygwin platform, which does not have the best > support for free VMs or for shared libraries, so I tend to just compile > the java files. I'd like to get native compilation working with cygwin and perhaps eventually with Mingw. I actually managed to write a working .dll with Mingw a couple of weeks ago... and I don't consider myself a Windows programmer. The fact it just worked was amazing to me. Gcj might work on cygwin. Porting ORP would probably not be too hard although it would help if they used autoconf with that one. > By the way, I think developers should have the autotools installed on > their machine, so I see no reason for CVS to keep track of generated > files like configure and Makefile.in, only the originals like > Makefile.am. The generated files should be part of the distribution, > though, since end users should not be required to have all the developer > tools just to use the final product. Fortunately, automake does this > correctly. I think we're doing this correctly today. > Who knows, improving the build framework might inspire someone to > improve the dependency tracking that jikes does, to make that part of > compilation even more efficient and compatible with automake. I tried working with jikes dependency tracking some time ago and I think I pretty much gave up on it. What is the current state of this? -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi! On Mit, 17 Okt 2001 Bryce McKinlay wrote: > Andreas Rueckert wrote: > > >>Not necessarily. Any paths seen by ld (e.g. with -L) will not be > >>automatically searched by the loader (assuming an ELF target). > >> > >>So each lib directory must be one of the "system" lib dirs or mentioned in > >>LD_LIBRARY_PATH, unless you also link with -rpath. > >> > > > >All these libs are in /etc/ld.so.conf , so it should work. > > > > Nope. The path to the libraries must be in LD_LIBRARY_PATH. I believe > this is a limitation of dlopen or maybe libtool's ltdl. Ok, I set the LD_LIBRARY_PATH var. Same result. > >Is there any way to > >get additional info what lib is missing? > > > > Classpath's reference runtime implementation should throw the missing > library name with the UnsatisfiedLinkError. For some reason your stack > trace didnt mention it. Which VM is this? ORP 1.0.6 > >I honestly think that Classpath is ridiculously complex to install. I guess > >you're doing a great job, but as it is, noone will notice. Have you ever > >thought of creating RPMs for popular Linux distros, or so? > > > > Here is the build procedure I use to get a classpath suitable for use > with ORP: > > 1. create gnu/classpath/Configuration.java by hand, from >gnu/classpath/Configuration.in > 2. mkdir build > 3. javac -d build -classpath .:build `find java gnu vm -name "*.java"` > 4. cp gnu/java/locale/*.uni build/gnu/java/locale/ > 5. cp gnu/java/locale/*.properties build/gnu/java/locale/ > > > I admit that this doesn't help if you want the native libraries, > however. The lack of an easy-to-use configure/build is a known problem, > and we'd love it if someone were to help fix it. Console apps seem to work. At a HelloWorldApp worked as expected. It seems that it's just a problem with the GTK lib. Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Brian Jones wrote: > > > Who knows, improving the build framework might inspire someone to > > improve the dependency tracking that jikes does, to make that part of > > compilation even more efficient and compatible with automake. > > I tried working with jikes dependency tracking some time ago and I > think I pretty much gave up on it. What is the current state of this? As far as I know, little work is currently being done on jikes' dependency tracking (there are only 3 or 4 active developers at the moment, and none of us have been tackling it). There is one outstanding patch that has yet to be applied to CVS which claims to allow command-line specification of the target directory for the generated .u files. Yet there are also several standing bug reports on flaws in the algorithm, such as questions over whether a .java file should be dependent on inner classes. Personally, I have never looked at that part of the jikes code, so I have no idea what it would take to make +M spit out the best possible dependence files. However, I feel that I could usefully spend some time on that project if it would help the Classpath project. I agree with the earlier sentiment that Ant has the drawback of requiring a working JVM installed on the machine, while make does not. While Ant may be the de-facto build framework for Java projects, it would be difficult to use when bootstrapping a free machine, which probably would not come with a free VM binary already installed. I also agree that make CAN be made to do anything that Ant can, it is just a tougher assignment to write the correct rules. But with automake and jikes dependency tracking (fixed, of course), I think this should be feasable. By the way, I don't have Ant installed on my machine; but make comes standard with cygwin. What about the idea of both a Makefile and build.xml approach to building the .class files? Then Ant users who just want classes.zip and already have a VM don't have to worry about make, but developers that care about the native code don't need to worry about Ant even for the .class files. The only drawback of this dual approach is that developers must remember to list new .java files in two separate build framework files, instead of one. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
On Wed, Oct 17, 2001 at 07:43:43AM -0600, Eric Blake wrote: > I agree with the earlier sentiment that Ant has the drawback of > requiring a working JVM installed on the machine, while make does not. This is just a atandard bootstrapping problem. (If you look at autoconf and M4, you'll find the same kind of bootstrapping problem). This problem is easily resolved by having: 1- Jikes 2- using a simple shell script to compile all java classes (no dependency tracking, etc.) [something like: find . | grep \\.java$ | xargs jikes -d classes ] Once a first set of class files are generated, a Free VM can then work and execute Ant, allowing a much nicer build environment. In fact, neither Make nor Ant should be *necessary* to compile the java sources. One needs these tools only to be able to get partial recompilation of sources, or use them to do additional things like installing the code, or building source/binary packages. Another example of bootstrapping can be seen in Ant itself. Ant uses Ant to build, but the source package also contains an initial bootstrapping shell script. So, I do not *personally* think that the dependency of Ant on Java is a valid argument against using it for the Java part of Classpath. Etienne -- Etienne M. Gagnonhttp://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
Hi! On Mit, 17 Okt 2001 Eric Blake wrote: > What about the idea of both a Makefile and build.xml approach to > building the .class files? Then Ant users who just want classes.zip and > already have a VM don't have to worry about make, but developers that > care about the native code don't need to worry about Ant even for the > .class files. The only drawback of this dual approach is that > ddevelopers must remember to list new .java files in two separate build > framework files, instead of one. New .java files shouldn't be a problem with Ant. It should find them automatically in most cases. Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build ideas
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> Gcj might work on cygwin. Not yet, alas. People talk about it sometimes, but the port is still incomplete. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
java.security.Security proposal
Anthony Green submitted a gcj patch that fixes a Security bug. It also changes Security.loadProviders to look for `gcj.security' and not `classpath.security': http://gcc.gnu.org/ml/java-patches/2001-q3/msg00460.html One problem with this is that it introduces a divergence between Classpath and libgcj. I prefer to avoid those. What if we change this mechanism so that we can have a VM-dependent `.security' file in addition to the `classpath.security' file? The idea would be to use the `java.vm.name' property to look up the initial security file, and then fall back on classpath.security. Comments? Tom PS I'm going to check in his bug fix shortly. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
java.security.Security question
Right now java.security.Security looks for classpath.security in /lib/security/. According to GNU standards this should be /share/security/ instead. Using lib is fine if we're following the JDK convention and want to be compatible with 3rd party packages that write to the .security file as part of their installation process. But in that case we ought to name the file `java.security'. I'd like to change this code to follow GNU standards. Any objections? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.security.Security proposal
Tom Tromey <[EMAIL PROTECTED]> writes: > Anthony Green submitted a gcj patch that fixes a Security bug. It > also changes Security.loadProviders to look for `gcj.security' and not > `classpath.security': > > http://gcc.gnu.org/ml/java-patches/2001-q3/msg00460.html > > One problem with this is that it introduces a divergence between > Classpath and libgcj. I prefer to avoid those. I apologize for not having read that link yet, but how does changing the name to gcj.security have to do with fixing a bug? Is this really gcj specific? Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.security.Security proposal
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> I apologize for not having read that link yet, but how does Brian> changing the name to gcj.security have to do with fixing a bug? Brian> Is this really gcj specific? Sorry -- the patch had two parts. One part was a bug fix; I checked it in. The other part changed the name of classpath.security. I'd prefer to have it search both .security and classpath.security. That allows for VM-specific security providers. As AG points out, there might be a CNI-based shared library provider. Putting that in classpath.security might confuse other VMs using Classpath. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.security.Security question
Tom Tromey <[EMAIL PROTECTED]> writes: > Right now java.security.Security looks for classpath.security in > /lib/security/. According to GNU standards this should be > /share/security/ instead. > > Using lib is fine if we're following the JDK convention and want to be > compatible with 3rd party packages that write to the .security file as > part of their installation process. But in that case we ought to name > the file `java.security'. > > I'd like to change this code to follow GNU standards. Any objections? Only what you mention above. -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.security.Security proposal
"Anthony Green" <[EMAIL PROTECTED]> writes: > Brian wrote: > > I apologize for not having read that link yet, but how does changing > > the name to gcj.security have to do with fixing a bug? Is this really > > gcj specific? > > It's possible to have an installation with native shared library > providers and no .jar implementation. You really don't want to have > a global classpath.security file in this case because gcj is the > only implementation that will find and use those providers. I'm not very familiar with Java's security framework here so I'll take your word for it. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
