Re: Proposal for a "main class" system property
> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes: Tom> What do people think of having a system property that stores the name of Tom> the class whose main method is being run? I need this value to properly Tom> initialize the GTK peers. On irc you had an example showing that this is what Sun's AWT does under the hood. I think it would be fine to have some `gnu.classpath.whatever' property that VMs are encouraged to set. My impression is that AWT will work even if you don't set this, it just might not be as friendly in some situations. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
On Thu, 2004-05-27 at 16:45, Thomas Zander wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 27 May 2004 12:17, Andrew John Hughes wrote: > > > since I still can't apt-get it, its not on my radar. (I'm wondering > > > how many distro's ship kaffe.) > > > > Kaffe is in Debian stable and unstable > Hmm, I use testing.. > So do I -- but I imagine you still have the stable package lists... ;-) I imagine the unstable version will eventually make its way into testing, anyway. > > So, Ant simulates make's functionality, but there > > is nothing to simulate detecting the JVM as the autotools can do (or, if > > there is, you don't see it in any current uses of Ant). > ant is a shell-script; it does its best to look for java. It uses JAVACMD, > or JAVA_HOME if it can't find a java in the path. > I'm not sure this answers your concerns though, and still expects a fully > implemented JVM. > My bad here -- I should have said its the Java compiler that's the problem. Running ant tries to use Sun's compiler from tools.jar by default -- I don't think there's any detection here (and there is a javac (mapped to jikes) in the path). > > If [the autotools] are flexible enough to > > also work with Java code (which they probably predate), this is an > > advantage of their design. > > That is something they can't do; they can call jikes from the command line; > but that is a LOT slower then ant with jikes, or ant with javac. This is > because a) ant knows which 'clusters' of files have changed and passes > them all to the compiler in one compile-run, and b) ant can do dependency > checking (which file needs a recompile because it depends on a changed > one) by reading the class files. > Which is where Ant excels as a Java-optimised build tool -- Makefiles have no concept of what class files are, and so can't pull out the required dependencies. I'm not sure how Ant runs with other compilers like Jikes, but with Sun's, it calls classes from tools.jar rather than the binary -- this probably gives a speed increase. Of course, the dependency handling doesn't always seem to work -- I have a habit of doing a clean of my classes files before a build, because otherwise old class files tend to hang around and hide errors in the code (with Jikes, anyway). > > - -- > Thomas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFAtg0KCojCW6H2z/QRAmDsAJ9AlDKcQ7s/38eC8TrOEFsbOgwRmQCgzGNn > qvC1caK9cgUwgzvdFHUC6JU= > =6c+4 > -END PGP SIGNATURE- > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath Cheers, -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn. signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Proposal for a "main class" system property
On Thu, 2004-05-27 at 23:37, Tom Tromey wrote: > > "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes: > > Tom> What do people think of having a system property that stores the name of > Tom> the class whose main method is being run? I need this value to properly > Tom> initialize the GTK peers. > > On irc you had an example showing that this is what Sun's AWT does > under the hood. > Yeah, when I take a screenshot of any window created by Sun's AWT, it is saved as Screenshot-Mainclassname.png. When I take a screenshot of a pure GTK application, it is saved as Screenshot-Binaryname.png. When I take a screenshot of our AWT, it is saved as Screenshot-.png. gtk_init sets the wmclass property of every window it creates to argv[0] (unless one overrides the value with gtk_window_set_wmclass). The screenshot mechanism puts that property's value in the filename. We currently set argv[0] to "" when calling gtk_init, which explains the weird screenshot name. > I think it would be fine to have some `gnu.classpath.whatever' > property that VMs are encouraged to set. My impression is that AWT > will work even if you don't set this, it just might not be as friendly > in some situations. > Yes, that's right. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Proposal for a "main class" system property
Hello, What do people think of having a system property that stores the name of the class whose main method is being run? I need this value to properly initialize the GTK peers. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 May 2004 04:20, Thomas Fitzsimmons wrote: > AFAIK, Java apps. should die when all non-daemon > > > threads have stopped (i.e. the GC can still be running, as its a > > daemon). > > Right, but we can't make all default threads daemons, or programs will > exit right away. The two non-daemon threads in a typical AWT program > are EventDispatchThread and GtkMainThread. I'm wondering if we should > make GtkMainThread a daemon, and have the exit criteria for AWT programs > be that all threads except EventDispatchThread are daemons, all > EventQueues are empty, and all top-level windows have been disposed. Having a jvm-reaper check if no events are present seems like a design that moves the logic to the wrong place. Why not let the event-dispatch thread die when all top-level windows are disposed? - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtZgiCojCW6H2z/QRAuRQAKDDpTi4TDY2Mt2ByeSUhBriILQd6gCfVynj gPBHDTjSC0wF/tVXboUn8+k= =jy+Z -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
[gui] [merge] java-gui-merge for may 26
hi, I've just completed the "monthly merge" from the java-gui-branch to the gcc libjava trunk. the following patch contains the changes: http://people.redhat.com/graydon/java-gui-merge-may-26-2004.patch it's a couple weeks late and a little rough (not to mention big) this time around. it *does* require that you upgrade your version of cairo to the latest CVS head, if you happen to be using the cairo backend. however, many fixes and additions are present: - AWT lists use GTK treeviews - proper AWT focus management has been implemented - swing menus and scrollpanes are beginning to work - swing splitpanes, dialogs and internal frames were added - swing repainting / double buffering was redone - a lot of AWT imaging and event bugs have been picked out if you have any difficulties integrating or merging this work, please let me know. -graydon ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 May 2004 11:26, Michael Koch wrote: > > footnote; I compiled Mauve some weeks ago only to find out that on > > suns-javac it did not compile. The problem was an > > illegal-code-construct. This tells me that jikes still is not > > mature enough for production code (since many people compiled it > > fine in the weeks before) > > I can compile Mauve fine with javac. This I posted a patch for some time ago, see: cvs diff -r 1.1 -r 1.2 gnu/testlet/java/text/SimpleDateFormat/attribute.java > Except that its slow it works. > Jikes is so much faster. I dont wanna miss it. Since 1.18 its very > stable and IMO more bug free then javac itself. There are situations where javac is faster; for example when its called repeatedly from within the same JVM. Jikes would be slower due to mallocs and the linker taking time for each invocation. > > The only answer I can give is that a superior technology that has > > poor usability tends to be replaced. > > The autofriends vs. ant choice is no once and forever choice. one > project can use autofriends and anohter ant. I fully agree, these emails by me are to give some counterweight to the general opinion in the GNU communities, thats all. The point is that I know quite a lot of non-open-source java developers, and all of them don't even WANT to come near the autotools. If you are developing Java its a good idea to see that, in contrary to most other GNU tools, the majority of your users are on Windows, and even those that are not are not going to use autotools. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtg+5CojCW6H2z/QRAjArAKDBkAnZOqa+ylRi39iVggYXSWZqkQCgsUVP r067DLO2kVK6YzI2Ww5IYM4= =ViRS -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
Andrew John Hughes wrote:
On Wed, 2004-05-26 at 18:44, Thomas Fitzsimmons wrote:
Modified versions of ant and tomcat that work with GCJ are available
from the RHUG project:
http://sources.redhat.com/rhug/
We're also doing work that will eventually allow these packages to run
unmodified on GCJ.
I'm going to take a look now -- I think its great someone is doing this,
although it probably should have been Apache to start with. Given the
length of time that the Free Java projects have now been active, it
amazes me that so little consideration is given to alternate VMs and
compilers by the Java community, especially for FOSS. I know Ant
Yep. But there is little one can do about that except from pointing out
that these projects lock themselves in into Sun-derived runtimes if they
don't test their software on GNU Classpath based runtimes, and help us
fix the problems.
It'd be nice if the FOSS Java community projects would not jump to
release code dependant on Java 1.5 features until 1.5 is officially
released, though, and there are clear specifications of how these
features work.
supports alternate compilers, but this wouldn't exactly be very clear to
someone who wants to use Ant in the same way as make ('make' -->
'ant'). One of the reasons that I think the autoconf/make stuff is
still a superior solution, even for Java, is that these solutions tend
to detect what a user actually has, instead of defaulting to Sun's JVM.
Apologies if some of this is wrong, but this is the impression I, and I
guess other users, get of the Ant/Tomcat situation.
I think this depends what you do.
If you're just compiling java code, than getting the dependency
resolution information from java compilers into your makefiles is a
major pain in the backside, in particular if you want to have the
'incremental compile' effect through your Makefiles, like you'd have it
for C and C++. So one of the reasons why some people like ant is that
ant ocassionally guesses right what needs to be rebuilt. It guesses
wrong, ocassionally, too, unfortunately. Nevertheless, ant is quite nice
for building java software. That's an area where autotools would have to
play a little catchup in terms of predefined task support, though the
ac-archive on sourceforge has some macros in that direction.
On the other hand, if you're using Java with native libraries on 50+
platforms, with all sorts of different C/C++ compilers, static and
shared, and want to be able to link the Java code to the native libs,
than ant is probably not the right tool for the job. In particular if
the problem you're trying to solve requires creating and combining
solutions from different programming languages, then autotools are a
better choice than ant, in my opinion.
I guessed as much, which was why I was wary of committing any patches
for the small problems I've noticed. It seems it would be best for me
to get this set up as you say, and contribute any AWT/Swing patches to
gcj rather than Classpath -- does this need a separate copyright
assignment?
The gui branch has one tiny problem though: it ocassionally (last few
days, apparently) has small amounts of broken Java code that depends on
some bugs in the gcj version on the branch.
That's not meant to be a cricism of the great work gcj hackers are doing
on it, it's meant to be an encouragement for a volunteer (i.e you :) to
help them fix that problem by using a different compiler to build it
yourself, so that the synchronisation between classpath and gcj becomes
simpler.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
Hallo Thomas, Thomas Zander wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 May 2004 12:17, Andrew John Hughes wrote: since I still can't apt-get it, its not on my radar. (I'm wondering how many distro's ship kaffe.) Kaffe is in Debian stable and unstable Hmm, I use testing.. Oh, it's stuck in unstable because it doesn't bootstrap on most debian platforms, save for the popular ones, with active developers on them. 1.1.5 will be better in that respect, hopefully. It's unpleasant, for sure. It's likely to remain broken on non-mainstream platforms where we don't have developers to fix the problems. It's a bit of a bootstrap problem in itself: you need to have a working runtime to attract developers, but to have a working runtime on a variaty of platforms you need the developers to maintain the ports ... Maintainance is the hardest bit, really. Most of Kaffe's 50+ ports have worked on the ported platforms at some point in time. But as the platforms develop, the toolchains develop, and kaffe's core progresses, things break. If there is noone around to fix them, they stay broken. :( So, Ant simulates make's functionality, but there is nothing to simulate detecting the JVM as the autotools can do (or, if there is, you don't see it in any current uses of Ant). ant is a shell-script; it does its best to look for java. It uses JAVACMD, or JAVA_HOME if it can't find a java in the path. I'm not sure this answers your concerns though, and still expects a fully implemented JVM. Well, ant actually looks for some unspecified acpects of an sdk installation: it assumes that there is a tools.jar, for example, and cries foul if it can't find it. When it can't find Sun's javac, it refuses to use anything else, unless you rub its nose (-Dbuild.compiler) at kjc or jikes. Fortunately, people have taken care of extending ant and providing generic javac tasks for jikes and kjc. On the other hand, though, Javah task still seems to try to call some Sun internal class directly, which of course doesn't work well with free runtimes. So does Native2Asci, and a few other tasks. Javah is particularly unpleasant, since that's something you'd like to have if you need to deal with JNI libraries, like Classpath does. I'd say that for some tasks, unfortunately, ant expects more than a fully implemented JVM: it expects a Sun-derived runtime, and nothing else :) But fortunately, that could be fixed, if someone volunteered to make ant fully runtime-agnostic. If [the autotools] are flexible enough to also work with Java code (which they probably predate), this is an advantage of their design. That is something they can't do; they can call jikes from the command line; but that is a LOT slower then ant with jikes, or ant with javac. This is because a) ant knows which 'clusters' of files have changed and passes them all to the compiler in one compile-run, and b) ant can do dependency checking (which file needs a recompile because it depends on a changed one) by reading the class files. The only real, big problem autotools have wrt Java (in my opinion) is getting good dependency tracking information into the build. But that's not that critical with jikes on a fast box, a full rebuild of Kaffe's class libraries takes just a few minutes. If you need incremental recompilation, compile all your files at once (preferably using @large-file-list-file), use jikes with '++' option for incremental compilation, and hit return when appropriate, i.e. when you'd normally call ant :) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
[EMAIL PROTECTED] said: > As Andrew said; when the last non-daemon thread dies; the Sun JVM has > a really nice feature to throw a stacktrace of all threads using one > command (the EOF char; ctrl-\) if not present; please place that on a > feature request list somwhere :) Thread stack dumping is a VM function not a function of Classpath. For the record Kissme implements this functionality, albiet in a rather flakey way. I also recall that SableVM implements it too. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 May 2004 12:17, Andrew John Hughes wrote: > > since I still can't apt-get it, its not on my radar. (I'm wondering > > how many distro's ship kaffe.) > > Kaffe is in Debian stable and unstable Hmm, I use testing.. > So, Ant simulates make's functionality, but there > is nothing to simulate detecting the JVM as the autotools can do (or, if > there is, you don't see it in any current uses of Ant). ant is a shell-script; it does its best to look for java. It uses JAVACMD, or JAVA_HOME if it can't find a java in the path. I'm not sure this answers your concerns though, and still expects a fully implemented JVM. > If [the autotools] are flexible enough to > also work with Java code (which they probably predate), this is an > advantage of their design. That is something they can't do; they can call jikes from the command line; but that is a LOT slower then ant with jikes, or ant with javac. This is because a) ant knows which 'clusters' of files have changed and passes them all to the compiler in one compile-run, and b) ant can do dependency checking (which file needs a recompile because it depends on a changed one) by reading the class files. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtg0KCojCW6H2z/QRAmDsAJ9AlDKcQ7s/38eC8TrOEFsbOgwRmQCgzGNn qvC1caK9cgUwgzvdFHUC6JU= =6c+4 -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [gui] [merge] java-gui-merge for may 26
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 27. Mai 2004 11:50 schrieb Andreas Schwab:
> graydon hoare <[EMAIL PROTECTED]> writes:
> > hi,
> >
> > I've just completed the "monthly merge" from the java-gui-branch
> > to the gcc libjava trunk. the following patch contains the
> > changes:
> >
> >
> > http://people.redhat.com/graydon/java-gui-merge-may-26-2004.patch
>
> libjava does not build any more.
>
> /tmp/cvs/gcc-20040527/Build/gcc/gcj
> -B/tmp/cvs/gcc-20040527/Build/ia64-suse-linux/libjava/
> -B/tmp/cvs/gcc-20040527/Build/gcc/ --encoding=UTF-8 -Wno-deprecated
> -C -g -classpath '' -bootclasspath
> /tmp/cvs/gcc-20040527/Build/ia64-suse-linux/libjava:../../../libjav
>a -d /tmp/cvs/gcc-20040527/Build/ia64-suse-linux/libjava
> ../../../libjava/javax/swing/JWindow.java
> ../../../libjava/javax/swing/JWindow.java: In class
> `javax.swing.JWindow': ../../../libjava/javax/swing/JWindow.java:
> In constructor `()': ../../../libjava/javax/swing/JWindow.java:83:
> error: Can't access package-private constructor
> `java.awt.Window.' from `javax.swing.JWindow'. super();
> ^
> 1 error
> make[2]: *** [javax/swing/JWindow.class] Error 1
I have just commited the attached patch with lets libjava bootstrap
again. Its not really tested and only to make libjava compile again.
Graydon: you should really consider to update gcj in java-gui-branch.
Michael
2004-05-27 Michael Koch <[EMAIL PROTECTED]>
* javax/swing/JPopupMenu.java
(isVisible): Do not use visible directly.
(setVisible): Likewise.
* javax/swing/JWindow.java
(JWindow): call accessible constructor.
* javax/swing/RepaintManager.java
(paintDirtyRegions): Use public methods to obtain iterator.
- --
Homepage: http://www.worldforge.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAtd70WSOgCCdjSDsRAhK3AKCRymFeUH11bsWdpPsafF/DifyHWQCfbwTj
WX4pzyDVowIzqxSsjPeUi5Y=
=A4q3
-END PGP SIGNATURE-
Index: javax/swing/JPopupMenu.java
===
RCS file: /cvs/gcc/gcc/libjava/javax/swing/JPopupMenu.java,v
retrieving revision 1.4
diff -u -b -B -r1.4 JPopupMenu.java
--- javax/swing/JPopupMenu.java 27 May 2004 06:17:39 - 1.4
+++ javax/swing/JPopupMenu.java 27 May 2004 12:25:18 -
@@ -471,7 +471,7 @@
*/
public boolean isVisible()
{
-return super.visible;
+return super.isVisible();
}
/**
@@ -481,7 +481,7 @@
*/
public void setVisible(boolean visible)
{
-super.visible = visible;
+super.setVisible(visible);
firePopupMenuWillBecomeVisible();
Index: javax/swing/JWindow.java
===
RCS file: /cvs/gcc/gcc/libjava/javax/swing/JWindow.java,v
retrieving revision 1.5
diff -u -b -B -r1.5 JWindow.java
--- javax/swing/JWindow.java 27 May 2004 06:17:39 - 1.5
+++ javax/swing/JWindow.java 27 May 2004 12:25:18 -
@@ -80,7 +80,7 @@
public JWindow()
{
- super();
+ super(null); // FIXME: This throws an exception.
}
// huuu ?
Index: javax/swing/RepaintManager.java
===
RCS file: /cvs/gcc/gcc/libjava/javax/swing/RepaintManager.java,v
retrieving revision 1.3
diff -u -b -B -r1.3 RepaintManager.java
--- javax/swing/RepaintManager.java 27 May 2004 06:17:39 - 1.3
+++ javax/swing/RepaintManager.java 27 May 2004 12:25:18 -
@@ -438,7 +438,7 @@
dirtyComponents.clear();
// step 2: paint those roots
-Iterator i = roots.iterator(AbstractMap.ENTRIES);
+Iterator i = roots.values().iterator();
while(i.hasNext())
{
AbstractMap.BasicMapEntry ent = (AbstractMap.BasicMapEntry) i.next();
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 27. Mai 2004 08:16 schrieb Thomas Zander:
> On Wednesday 26 May 2004 23:47, Andrew John Hughes wrote:
> > Given the
> > length of time that the Free Java projects have now been active,
> > it amazes me that so little consideration is given to alternate
> > VMs and compilers by the Java community, especially for FOSS.
>
> The free-java projects have made a bad start; when I just started
> using Java I tried kaffe and Jikes. Kaffe was totally unusable; and
> since I still can't apt-get it, its not on my radar. (I'm
> wondering how many distro's ship kaffe.)
> Jikes is a good example of Foss going wrong; in the time I was
> using 1.11 up-until 1.13, mostly because of its speed.
> During this time more and more problems came in; errors in
> compiling that were not errors at all, and un-verifiable classes
> which caused clients to not be able to run the software as soon as
> it was compiled with jikes. I'm not sure if the situation with
> jikes cleared up; but our company still has a VERY strict policy
> about not using jikes; ever!
>
> footnote; I compiled Mauve some weeks ago only to find out that on
> suns-javac it did not compile. The problem was an
> illegal-code-construct. This tells me that jikes still is not
> mature enough for production code (since many people compiled it
> fine in the weeks before)
I can compile Mauve fine with javac. Except that its slow it works.
Jikes is so much faster. I dont wanna miss it. Since 1.18 its very
stable and IMO more bug free then javac itself.
> > I know Ant
> > supports alternate compilers, but this wouldn't exactly be very
> > clear to someone who wants to use Ant in the same way as make
> > ('make' --> 'ant').
>
> The whole point of ant is to throw away make; Java programmers
> program java because its easier to use the tools. Most have no idea
> if they are using spaces or tabs (for instance). This means that
> they all curse like hell if they have to edit a Makefile and it
> won't work because it needs a tab at begin of line.
> There are dozens of reasons why ant is 'better' then make; it has
> been created as a replacement for make after all...
>
> > One of the reasons that I think the autoconf/make stuff is
> > still a superior solution, even for Java, is that these solutions
> > tend to detect what a user actually has, instead of defaulting to
> > Sun's JVM. Apologies if some of this is wrong, but this is the
> > impression I, and I guess other users, get of the Ant/Tomcat
> > situation.
>
> The only answer I can give is that a superior technology that has
> poor usability tends to be replaced.
The autofriends vs. ant choice is no once and forever choice. one
project can use autofriends and anohter ant. Let the developers
developing a software decide what they use. Dont try to get them
follow your thoughts. They know best why they choose one over the
other. There are many known problems with autofriends but there are
not less other known problems with ant.
Michael
- --
Homepage: http://www.worldforge.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAtbQqWSOgCCdjSDsRAukAAJ0VV6+TXcj8TK+JKTWrGM72eQshFACdFjBf
acNYpgb6hkzkdllRFwC3tsI=
=LVtw
-END PGP SIGNATURE-
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
On Thu, 2004-05-27 at 07:16, Thomas Zander wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wednesday 26 May 2004 23:47, Andrew John Hughes wrote:
> > Given the
> > length of time that the Free Java projects have now been active, it
> > amazes me that so little consideration is given to alternate VMs and
> > compilers by the Java community, especially for FOSS.
>
> The free-java projects have made a bad start; when I just started using
> Java I tried kaffe and Jikes. Kaffe was totally unusable; and since I
> still can't apt-get it, its not on my radar. (I'm wondering how many
> distro's ship kaffe.)
Kaffe is in Debian stable and unstable
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=kaffe&searchon=names&subword=1&version=all&release=all
> Jikes is a good example of Foss going wrong; in the time I was using 1.11
> up-until 1.13, mostly because of its speed.
> During this time more and more problems came in; errors in compiling that
> were not errors at all, and un-verifiable classes which caused clients to
> not be able to run the software as soon as it was compiled with jikes.
> I'm not sure if the situation with jikes cleared up; but our company still
> has a VERY strict policy about not using jikes; ever!
>
> footnote; I compiled Mauve some weeks ago only to find out that on
> suns-javac it did not compile. The problem was an illegal-code-construct.
> This tells me that jikes still is not mature enough for production code
> (since many people compiled it fine in the weeks before)
>
I haven't experienced any problems with Jikes -- but presumably I've
been using more recent versions than this (current Debian is 1.18 from
21st of November, 2002)
> > I know Ant
> > supports alternate compilers, but this wouldn't exactly be very clear to
> > someone who wants to use Ant in the same way as make ('make' -->
> > 'ant').
>
> The whole point of ant is to throw away make; Java programmers program java
> because its easier to use the tools. Most have no idea if they are using
> spaces or tabs (for instance). This means that they all curse like hell if
> they have to edit a Makefile and it won't work because it needs a tab at
> begin of line.
> There are dozens of reasons why ant is 'better' then make; it has been
> created as a replacement for make after all...
I don't disagree that Ant is superior to make -- the problems with make
are one of the reasons that the auto tool set exists as well (reading
these generated Makefiles is a nightmare). This is why I would expect
people to be able to replace the invocation of 'make' with 'ant' when a
build.xml file exists. At present, this fails without alterations when
not using Sun's JVM. So, Ant simulates make's functionality, but there
is nothing to simulate detecting the JVM as the autotools can do (or, if
there is, you don't see it in any current uses of Ant).
>
> > One of the reasons that I think the autoconf/make stuff is
> > still a superior solution, even for Java, is that these solutions tend
> > to detect what a user actually has, instead of defaulting to Sun's JVM.
> > Apologies if some of this is wrong, but this is the impression I, and I
> > guess other users, get of the Ant/Tomcat situation.
>
> The only answer I can give is that a superior technology that has poor
> usability tends to be replaced.
The autotools are primarily aimed at C/C++ protects anyway AFAIK (at
least, that's where they are most used). If they are flexible enough to
also work with Java code (which they probably predate), this is an
advantage of their design.
>
>
> - --
> Thomas
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAtYe3CojCW6H2z/QRApuPAKDhTOouUqGGvfsHgGbzx4+ccUf1PgCdGsAy
> PVu8xeVupxS0W5gY4azpS6c=
> =XxVk
> -END PGP SIGNATURE-
>
>
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath
--
Andrew :-)
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 26 May 2004 19:44, Thomas Fitzsimmons wrote: > > Another problem I noticed -- as soon > > as a toolkit is instantiated, the code doesn't exit anymore, > > presumably because some thread is hanging on -- even something as > > simple as getDefaultToolkit().getScreenSize() needs a Ctrl+C. It > > doesn't seem to be a JVM problem (same on Jam, Sable and gij) so must > > be something in the shared gcj/classpath code for the AWT (either in > > the main code or in the peers). > > Yes, this is still a problem. I haven't figured out yet what should be > the exit criteria for a GUI app. As Andrew said; when the last non-daemon thread dies; the Sun JVM has a really nice feature to throw a stacktrace of all threads using one command (the EOF char; ctrl-\) if not present; please place that on a feature request list somwhere :) Anyway; there is a "Suspend Checker Thread" in that stacktrace that displays a nice idea. (give me an email if you want an example traces-output) I'm wondering if you guys thought about the concept of application-contexts. The seperation of AWT applications in one JVM. Using this concept (which is implemented in a sun.awt package) you can create multiple AWT-Event threads and multiple totally seperate component-hierarchies which allows (for intstance) to have multiple L&Fs installed. The java.awt.Frame.getFrames() uses that application-context, for instance. The implementation on Suns side has some bugs making it unusable; but the idea is certainly _very_ appealing to me. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtYSrCojCW6H2z/QRAsS4AKDhPGi/T2sSzI9pT1yhymJGPuSAJwCdHcji JX3f7o9LmnlZe0L4IOLWtQk= =f8Tj -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 26 May 2004 23:47, Andrew John Hughes wrote:
> Given the
> length of time that the Free Java projects have now been active, it
> amazes me that so little consideration is given to alternate VMs and
> compilers by the Java community, especially for FOSS.
The free-java projects have made a bad start; when I just started using
Java I tried kaffe and Jikes. Kaffe was totally unusable; and since I
still can't apt-get it, its not on my radar. (I'm wondering how many
distro's ship kaffe.)
Jikes is a good example of Foss going wrong; in the time I was using 1.11
up-until 1.13, mostly because of its speed.
During this time more and more problems came in; errors in compiling that
were not errors at all, and un-verifiable classes which caused clients to
not be able to run the software as soon as it was compiled with jikes.
I'm not sure if the situation with jikes cleared up; but our company still
has a VERY strict policy about not using jikes; ever!
footnote; I compiled Mauve some weeks ago only to find out that on
suns-javac it did not compile. The problem was an illegal-code-construct.
This tells me that jikes still is not mature enough for production code
(since many people compiled it fine in the weeks before)
> I know Ant
> supports alternate compilers, but this wouldn't exactly be very clear to
> someone who wants to use Ant in the same way as make ('make' -->
> 'ant').
The whole point of ant is to throw away make; Java programmers program java
because its easier to use the tools. Most have no idea if they are using
spaces or tabs (for instance). This means that they all curse like hell if
they have to edit a Makefile and it won't work because it needs a tab at
begin of line.
There are dozens of reasons why ant is 'better' then make; it has been
created as a replacement for make after all...
> One of the reasons that I think the autoconf/make stuff is
> still a superior solution, even for Java, is that these solutions tend
> to detect what a user actually has, instead of defaulting to Sun's JVM.
> Apologies if some of this is wrong, but this is the impression I, and I
> guess other users, get of the Ant/Tomcat situation.
The only answer I can give is that a superior technology that has poor
usability tends to be replaced.
- --
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAtYe3CojCW6H2z/QRApuPAKDhTOouUqGGvfsHgGbzx4+ccUf1PgCdGsAy
PVu8xeVupxS0W5gY4azpS6c=
=XxVk
-END PGP SIGNATURE-
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
Thomas Fitzsimmons wrote: Modified versions of ant and tomcat that work with GCJ are available from the RHUG project: They are now also Fedora (http://fedora.redhat.com/) - if you install "everything" in Fedora Core, you get a bunch of Java packages, with .jar files, documentation, and gcj-compiled .so files. I'd like to make a compatible kawa-NNN.rpm ... -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
