Thread: [Sablevm-developer] Code indenter / Uncompilable classes
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Etienne M. G. <eti...@uq...> - 2001-08-27 20:21:24
|
Hi.
Lately, I have imported the latest sources from the Classpath repository into
sablepath-classes, using scripts to extract java sources (and related resource
files) and relocate them in a sane directory structure.
I-
===
One thing I would like to have is a code indenter, somethink akin "indent".
This would simplify code maintenance as we could run the indenter along the
"import" scripts so that diffs with the vendor CVS branch wouldn't be
artificially inflated by simple code re-indentation. Also, it makes life
simpler for everybody to have a uniform indentation style.
Personally, I would like a program that indents programs closely to the "GNU C"
style, with matching parenthesis level, one space between identifier/keyword
and "(", with minor modifications... something like:
void foo (int a, long b)
{
...
}
*** NOT ***
void
foo( int a , long b ) {
...
}
Anyone knows a *** robust *** program to do so? All the ones I have tried so
far have bugs when confronted to inner-classes/anonymous classes, or are not
flexible using Sun's ugly unmatched "{" "}" levels, etc.
II-
===
The latest Classpath source files are mostly broken under Jikes (I'm using
version 1.14). So I have cheated, and tried compiling them under "javac". [I
am not checking that semantics are OK, just that they compile]. Even this is
asking a lot from Classpath... There are 20 classes that are definitely
broken. Here is the list:
src/gnu/javax/swing/plaf/gtk/GtkBorders.java
src/gnu/javax/swing/plaf/gtk/GtkCheckBoxUI.java
src/gnu/javax/swing/plaf/gtk/GtkIconFactory.java
src/gnu/javax/swing/plaf/gtk/GtkLookAndFeel.java
src/gnu/javax/swing/plaf/gtk/GtkRadioButtonUI.java
src/gnu/javax/swing/plaf/gtk/GtkSliderUI.java
src/java/util/jar/JarEntry.java
src/java/util/jar/JarFile.java
src/java/util/jar/JarInputStream.java
src/java/util/jar/JarOutputStream.java
src/javax/accessibility/Accessible.java
src/javax/accessibility/AccessibleHypertext.java
src/javax/accessibility/AccessibleText.java
src/javax/swing/GrayFilter.java
src/javax/swing/plaf/BorderUIResource.java
src/java/net/JarURLConnection.java
src/javax/accessibility/AccessibleComponent.java
src/javax/accessibility/AccessibleSelection.java
src/java/net/URLClassLoader.java
src/java/util/IdentityHashMap.java
I have not looked for the reason why these are broken. More annoying is the
fact that many classes, including "core" library classes (I think java.io.File
is part of them) are broken under Jikes. Jikes seems to die with something
like a "signal 11".
As usual, you must be careful to set BOTH the "-bootclasspath" and "-classpath"
command line options to for the compiler to use "SablePath" as its core system
library when you compile the code (with jikes and/or javac).
All help/suggestions would be appreciated.
Have fun,
Etienne
--
Etienne M. Gagnon eti...@uq...
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Ian R. <ir...@cs...> - 2001-08-31 17:19:16
|
Hi, Here's a summary of where I'm up to. I'm trying my best to build the sablepath-classes with a standard SuSE 7.2 set up. To build the .class files I'm running "find src -name '*.java'|xargs jikes +E -classpath /home/ian/sable/sablepath-classes/src:/home/ian/old-classpath". Jikes version 1.2. The story so far: > src/java/util/jar/JarEntry.java > src/java/util/jar/JarFile.java > src/java/util/jar/JarInputStream.java > src/java/util/jar/JarOutputStream.java > src/java/net/JarURLConnection.java The jar stuff relies on java/util/zip which for some reason isn't in the classpath repository. If it were I'm confident this would build. > src/java/net/URLClassLoader.java Built fine for me. Possible issues with the Jar stuff tho'. > src/java/util/IdentityHashMap.java The clone method needs to have "throws java/lang/CloneNotSupportedException" appended. I guess Object.clone was updated and this file was missed during the update. > src/javax/swing/plaf/BorderUIResource.java Wouldn't compile so moved out of the build tree. Issues mainly with a border package. > src/javax/swing/GrayFilter.java Compiled fine when the body of createDisabledImage was altered to return null; and filterRGB's result was cast to an int. > src/javax/accessibility/AccessibleText.java > src/javax/accessibility/Accessible.java > src/javax/accessibility/AccessibleHypertext.java There's clearly issues with javax/accessibility. I moved these files. > src/javax/accessibility/AccessibleComponent.java > src/javax/accessibility/AccessibleSelection.java Compiled fine for me, but failed when the other files were moved. > src/gnu/javax/swing/plaf/gtk/GtkIconFactory.java Failed most notably because java/swing/plaf/gtk/Icon was misssing, therefore moved. > src/gnu/javax/swing/plaf/gtk/GtkSliderUI.java > src/gnu/javax/swing/plaf/gtk/GtkLookAndFeel.java > src/gnu/javax/swing/plaf/gtk/GtkRadioButtonUI.java > src/gnu/javax/swing/plaf/gtk/GtkBorders.java > src/gnu/javax/swing/plaf/gtk/GtkCheckBoxUI.java Failed for lots of reasons, javax/swing/plaf/basic and javax/swing/border not being present being one of them, files moved. > I have not looked for the reason why these are broken. More annoying is the > fact that many classes, including "core" library classes (I think java.io.File > is part of them) are broken under Jikes. Jikes seems to die with something > like a "signal 11". I'm running a slightly older version of Jikes and things appear to be fine. I'm keen to keep using this older version of Jikes too, until someone points out a really good reason to upgrade. In summary, everything is there and building except Swing and the Jar related stuff. As some of the core stuff relies on the Jar stuff I'm keen we get that working. I'll e-mail the maintainer and hopefully find out when the stuff will appear in the classpath CVS repository. The Swing stuff isn't critical to me, and it appears very incomplete. I suggest we move it out of the code tree for the time being. Finally, the way I'm building the code at the moment puts all the pressure on jikes. Should we build a set of makefiles, configure, etc.. ? All the best, Ian Rogers |
|
From: <eg...@j-...> - 2001-09-03 19:32:01
|
Hi Ian, On Fri, Aug 31, 2001 at 05:43:24PM +0000, Ian Rogers wrote: > files I'm running "find src -name '*.java'|xargs jikes +E -classpath > /home/ian/sable/sablepath-classes/src:/home/ian/old-classpath". Jikes > version 1.2. The story so far: I have tried recompiling jikes 1.14 from sources, but it didn't solve the segmentation fault problem. I have noticed that there's a bug report on the Debian package I was using, relatively to this problem, so I grabbed the sources from : http://oss.software.ibm.com/developerworks/project/showfiles.php?group_id=10 The problem is that jikes 1.02 is not available there. Do you have a copy of this packages (sources)? > The jar stuff relies on java/util/zip which for some reason isn't in the > classpath repository. If it were I'm confident this would build. I've noticed your request on the classpath-list. Hopefully people will finally check-in those sources. > > src/java/net/URLClassLoader.java > > Built fine for me. Possible issues with the Jar stuff tho'. I need to get a version of jikes that does not sigfaults. Maybe it is related to the fact I have GNU LibC 2.2.4 on my system? > I'm running a slightly older version of Jikes and things appear to be > fine. I'm keen to keep using this older version of Jikes too, until > someone points out a really good reason to upgrade. My problem is that I'm on Debian "unstable" which keeps updating to the latest "stable" version of programs (which means 1.14 for Jikes)... I can always do a local installation, out of source packages too, but I didn't find version 1.02. I'll try the oldest one available 1.04 and report back success/failure. > In summary, everything is there and building except Swing and the Jar > related stuff. As some of the core stuff relies on the Jar stuff I'm > keen we get that working. I'll e-mail the maintainer and hopefully find > out when the stuff will appear in the classpath CVS repository. The > Swing stuff isn't critical to me, and it appears very incomplete. I > suggest we move it out of the code tree for the time being. > > Finally, the way I'm building the code at the moment puts all the > pressure on jikes. Should we build a set of makefiles, configure, etc.. > ? The "build.xml" file is the equivalent of Makefile.am/configure.ac files. It is for use with the Jakarta "ant" tool. See http://jakarta.apache.org/ant/ This tool is written in Java, and offers a much more appropriate way to build classes, jar files, and distributions for Java programs than the GNU auto-tools. It has a pretty simple "XML" based syntax. We can use it to "exclude" from compilation those files we know not to build. My problem was that, on my system, jikes failed to compile too many classes. Currently, I use Sun's jdk to "run ant". Hopefully, someday soon I'll be able to run it on SableVM instead. Obviously, we will also need to provide a simple script to bootstrap the first compilation on a user system;-) But for maintenance, ant is a charm to use (for the Java part). Obviously, we want to maintain the JNI/C code under the GNU auto* tools. This is why I have made a separate sablepath-lib CVS project for it. You could give Ant a look and ask me any question you have. I'll get back as soon as I can get jikes to work decently on my system. If you have made any modifications to the sources, you can check-them in CVS. If you have Ant running, you can add an "exclude" specification in the <javac ...> task so to exclude the files you "moved away" in your local copy. Have fun! Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne M. G. <eg...@j-...> - 2001-09-03 23:50:05
|
- I've imported the latest classpath updates into CVS. - Jikes 1.13 works fine for me. I think 1.14 introduced some locale stuff which somehow creates prolems on Debian. Others are following upon this on Debian (and probably jikes) so I won't waste my time on this. - I've checked the http://jazzlib.sourceforge.net/ project. Their zip stuff is under a compatible license, and copyrighted by the FSF. I could import their latest CVS snapshot (as their latest release is rather old) into another vendor branch, as I do with classpath. What do you think? - I've modified "build.xml" so that it does not try to compile the classes listed in the file "broken-classes" (new also). For those of you who don't know about it, there's a cvs-commit mailing-list so that you get notified on every update. You can subscribe for the daily digest option if you do not want to be flooded by mail on multiple updates. See the mailing-list collection at: http://sourceforge.net/mail/?group_id=5523 Have fun! Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Ian R. <ir...@cs...> - 2001-09-04 11:02:36
|
Hi, > - I've imported the latest classpath updates into CVS. I checked it out and everything built for me just fine. I couldn't (didn't try too hard) to get jakarta-ant to build for me, so I just used the binary version. But yep, great :-) > - I've checked the http://jazzlib.sourceforge.net/ project. Their > zip stuff is under a compatible license, and copyrighted by the FSF. I > could import their latest CVS snapshot (as their latest release is > rather > old) into another vendor branch, as I do with classpath. What do you > think? I don't actually need java.util.zip (I think). It may just be worth waiting for classpath to integrate jazzlib. If that takes too long then we can integrate it, but it should probably be a low priority unless there is a particular need. > - I've modified "build.xml" so that it does not try to compile the > classes > listed in the file "broken-classes" (new also). Works a treat. OK, I'm playing with sablepath-libs now. I'll let you know of problems I find with them and SpecJVM. Ta, Ian |
|
From: Etienne M. G. <eti...@uq...> - 2001-09-04 14:02:31
|
On Tue, Sep 04, 2001 at 12:02:50PM +0000, Ian Rogers wrote: > I checked it out and everything built for me just fine. I couldn't > (didn't try too hard) to get jakarta-ant to build for me, so I just used > the binary version. But yep, great :-) I don't like much ant's packaging. I will probably make a simpler package for people to build/install. I need to do this, anyway, for my students, as I do not want them to fight with the system to get ant & xerxes installed; they're new to Java:) As Tuesday is my teaching day, I won't be able to accomplish much today. Please be forgiving. > I don't actually need java.util.zip (I think). It may just be worth > waiting for classpath to integrate jazzlib. If that takes too long then > we can integrate it, but it should probably be a low priority unless > there is a particular need. I'd like, at some point, to have the system class-loader (which is NOT the bootstrap class-loader, and IS written in java) to load classes out of jar files. The zip stuff would be great for this. But it can wait a little. Would you try contacting the 2 persons Brian refered to in his reply to me? Maybe they're on vacation, or inactive, or whatever; so it would be a good idea to check that they are aware that people are waiting for action. It is my experience that when Brian says that somebody is responsible for something, it means that he himself is not responsible for it; it does not necessarily mean that he will do anything to contact the responsible person and try to get things moving... > > - I've modified "build.xml" so that it does not try to compile the > > classes > > listed in the file "broken-classes" (new also). > > Works a treat. So, are you sold on not using the GNU auto* stuff for Java code? It was a SableCC user that introduced me to Ant. Once you get to know it, you don't want to go back to Makefiles (or GNU auto*) for your Java projects. > OK, I'm playing with sablepath-libs now. I'll let you know of problems I > find with them and SpecJVM. Ta, Hmmm... I haven't updated sablepath-libs with the latest Classpaht CVS snapshot. I still have to adapt my "extracting" scripts for the latest code. But, you can certainly have a quick look, to see how I think the code should be organized. Mainly, I organize the code into one directory for every .so library that can be loaded through System.loadLibrary(). Etienne -- Etienne M. Gagnon eti...@uq... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X