Re: JAVA PROJECT! CODER WANTED!!
>> What, are you kidding? >HE'S COMPLETELY NUTS Maybe a refugee from the Freedows project :-)
minor bug in java.awt.List.removeAll()
If you call java.awt.List.removeAll() on a List that's never had anything added to it, you get a warning from Motif: Warning: Name: slist Class: XmList Item(s) to be deleted are not present is list. Should I file a bug report to the formerly Open Group about the typo in the warning message, too? :-)
Re: Java debugger under Linux
>I don't know of any options that don't use jdb, unfortunately. There's the Jikes debugger from IBM AlphaWorks, available at http://www.alphaworks.ibm.com/alphapreview_tools/ it's a generic Java debugger but relies on a moving target of the Java debugging interface. It says it only works in JDK 1.1.6.
Re: java SEGV under solaris/NT, not linux?
[complicated Java app with native code crashing in some OSes, not others] >My first assumption is that I must have some strange memory bug in >the C library. It sure sounds that way. >The thing that confuses this is that the C-only test programs run >fine on all three OS's and the java clients run fine under Linux. >It's only java under solaris and NT that is a problem. Memory trashing gives very random bugs. Try running your C test programs under Purify or an equivalent tool. I haven't kept up in this domain; gcc was supposed to build in some support for bounds checking, Checker looked pretty good for Linux a year ago, even ElectricFence might turn something up. Steve - are you able to test your JDK ports under one of these tools? It could help a lot in making the VM more stable, although if Sun isn't careful about this kind of testing then you might spend all your time hunting down their bugs.
Re: Profiler for Linux?
>I've been playing with GIF images and am having major performance >issues - it's just taking too long to read and write the files! Make sure you're using the right kinds of streams. It's very easy to end up with nonbuffered I/O in Java by accident, and the performance of those is indeed really awful. So make sure you having a buffering stream in the pipeline somewhere. >Can anyone point me to a good profiler for Linux? I don't know of anything other than java_g -prof. Worth looking around though, maybe someone has come up with one for the Sun JDK under Unix that will also work in Linux.
Re: Need a Java/Linux RedHat 5.0 configuration where getLocalHost works
one more datapoint - I have localhost as the first entry in /etc/hosts (where it belongs, I might add), but the test program correctly prints out pinotnoir.media.mit.edu/18.85.16.104 What's the difference? I'm not running glibc, I'm using libc5. My system is a mostly-Redhat-4.1 system with libc-5.3.12 and java version "Linux_JDK_1.1.5_v7". glibc must be doing something different. Whether it's a bug or a misfeature, I wouldn't want to guess.
Re: TurboJ
>Has anyone tried TurboJ from the opengroup yet ? Welcome to the web: http://www.camb.opengroup.org/openitsol/turboj/ I got as far as installing it, then found you have to get a license from Sales to run it. I guess it's not free, but I couldn't find any info about pricing online. So.. has anyone tried it? :-)
Re: TurboJ
>I'm rather doubtful about Java->C compilers. I had great luck with Toba back in Java 1.0. Well, that may be exaggerating. The Toba version of javac was terrific, at least five times faster than the interpreted version. But between the Java interpreter getting faster in 1.1, and the overhead of JITting everytime, jdk1.1+tya isn't worth it for javac. Is there a good fast alternative for javac for Java 1.1 in Linux?
Re: [Fwd: Your Own Adult Paysite!!!]
>WHY??? would a technical based newsletter, circulate trash about >setting up a porn web site, to its subscriber list ? Because the Blackdown administrators are big evil ripoff artists. They get 5 cents for every spam that goes through their mailing list. It pays for running the list here. Sigh, I guess I have to put a :-) here. Duh, it's spam. The only way to shut it down on a mailing list like this is to set it so only members can post. I think it'd be nice if this list were set up that way, but there are reasons not to do it.
Re: instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
>>My workaround, which has been generally successful, was to subclass >>JFrame. In the subclass I override dispose (and also setVisible()) >>with a method that forks off Thread with a lower priority than the >>current thread. That's a clever workaround, but ugh! >Is Nelson's application multi-threaded? Yep, heavily. >I'm pretty new to this Java game, but it appears to me that the AWT's >dirty little secret is a lack of thread safety. AWT's threading is very strange and complicated (and update runs at the wrong priority), but I've never seen it do something unsafe. My impression is this is more like a Peer problem, that maybe the Peer implementation isn't safe. >The closest thing I've found to relevant information is in the >documentation for Swing -- which states explicitly that Swing is not >thread-safe, and that all GUI access, after the GUI is instantiated, >needs to happen from the AWT Event thread. This is certainly a requirement I can live with. But in this case, the dispose() only happens in an AWT Event thread. It's called when the user clicks on a button (stackframe included again) >On the other hand, I've found that adopting Swing's approach has >solved my GUI reliability problems. Norm's approach sounds >suspiciously similar. Actually, isn't it exactly the opposite, putting the call to Swing in some non-Swing thread? Here's that stack trace again - "AWT-EventQueue-0" (TID:0x407209c0, sys_thread_t:0x4154bf04, state:R) prio=5 *current thread* sun.awt.motif.MComponentPeer.dispose(MComponentPeer.java:215) sun.awt.motif.MFramePeer.dispose(MFramePeer.java:101) java.awt.Component.removeNotify(Component.java:2526) java.awt.Container.removeNotify(Container.java:1149) java.awt.Window.dispose(Window.java:177) java.awt.Frame.dispose(Frame.java:372) edu.mit.media.nelson.straum.agent.CreateAgentUI.createAgent(CreateAgentUI.java:70) edu.mit.media.nelson.straum.agent.CreateAgentUI$2.actionPerformed(CreateAgentUI.java:45) java.awt.Button.processActionEvent(Button.java:254) java.awt.Button.processEvent(Button.java:227) java.awt.Component.dispatchEventImpl(Component.java:1764) java.awt.Component.dispatchEvent(Component.java:1704) java.awt.EventDispatchThread.run(EventDispatchThread.java:63)
Re: URL for JDK Src license - for README.linux.src
>I happened to have it handy :-) >http://www.javasoft.com/nav/business/source_form.html Interesting.. I'd always been under the impression that the source license for Sun's Java had some NDA-like terms in it, including provisions that would make it difficult for someone to develop an alternate VM if they'd seen Sun's source. (Over and above any general issues about copyright). But reading the license mentioned above, it seems like a fairly benign agreement. Yes, your redistribution rights are very limited, but it doesn't seem like there's any NDA-like stuff in it. What's the risk in signing their agreement?
Re: rmic is way slow
>I am running into a real bottleneck when compiling rmi applications >with: java_dyn full version "Linux_JDK_1.1.6_v2". rmic takes forever >to run on a single class. At first I thought it was just a jdk 1.x >problem, but when running sun's 1.1.6 rmic finishes in about 1/30th >the time that Linux does. It's possible this is NFS-related; it's distressingly easy to use an unbuffered output stream in Java. If you don't buffer writes, then it's incredibly slow over NFS in Linux. (I think Soalris cheats and does some write-combining, so the unbuffered writes might be faster). Try running it so that rmic's output is written to local disk like /tmp. Is it better? Let us know. (This trick works with Voyager's vcc utility, which is similar to rmic in some ways.)
Re: rmic is way slow
To all you bozos sending me mail saying "get me off this list", I have nothing to do with subscribership. Try talking to [EMAIL PROTECTED] or [EMAIL PROTECTED] >That sounds like the problem... and yes... running rmic in /tmp runs >a trillion times faster. Ah, good. I'd still be curious to know why Linux is so much worse than Solaris with unbuffered NFS writes. Again, my guess is that Solaris is caching the data a bit in the kernel before doing NFS. I believe this is officially disallowed (NFS writes are synchronous), but it sure makes things nicer. Maybe 2.1.x kernels do a better job of this? >Unfortunately I can not perform all of my compiles in /tmp. Any ideas >on how to get around this? This problem convinced me to switch to CVS. I do my development on local disk, then check the sources in to CVS on my NFS mounted (and backed up) disk. Not exactly a simple solution, but it was good to use CVS anyway. The other option is to write a shell script wrapper around rmic that writes to /tmp and then copies the output back.. If rmic has a -d option similar to javac, then it's easy. Just do something like rmic -d /tmp Foo.java mv /tmp/RMIFoo.class . (sorry, I don't know rmic that well. I hope the idea is clear). Without a -d option you'll have to copy Foo.java to /tmp first. The only other thing I could think is to reverse engineer rmic, fix it so that it uses a buffered output stream, and recompile it. That's probably illegal. (Bummer about not having source to rmic. Jini is going to be open source, which is incredibly cool.)
Re: linux on laptops
Why did you post this message to java-linux? This is not a generic Linux support mailing list. There is a lot of documentation out there on the web about exactly the sort of question you ask. You should do your research first, then ask questions later, and then only in the appropriate place. mailing list cop for the day, Nelson
Re: Thread.sleep(..) for Linux?
>Linux system timer resolution is (according to manpage) 10msecs. Yep, although this is configurable in the kernel. >And currentTimeMillis returns increments below a 10msec resolution. Newer kernels have more precise timers - they take advantage of some timers in the Pentium. I believe the basic system calls to get time do this transparently, so Java probably just passes the data on through. I don't know what's going on with sleeps though. Maybe it's rounding down instead of up?
mirror troubles
I hate to hassle the porting team, but it's been two weeks since v4a was released but very few mirrors have it. I finally found it at ftp://ftp.bogus.net/pub/mirrors/liquor.cabi.net/ Is something wrong with the mirroring setup?
jdk 1.1.5_v7 -> 1.1.6_v4a, socket problem.
I have a bunch of complicated network code that works fine under jdk 1.1.5_v7, but fails in jdk 1.1.6_v4a with a socket exception: COM.objectspace.voyager.TransportException: java.net.SocketException: Socket option unsupported Unfortunately, my program has a lot of stuff in it, so it's hard to narrow down. The code that's causing the socket exception is from Objectspace's Voyager 1.0.1, a distributed object and mobile agent framework. That error is being thrown when I try to create an agent in one program and then move it to another machine. Most other things in my code (like the distributed object communication) work fine, it's only this one simple mobile agent thing that is failing in a rather opaque manner. I don't even know if all mobile code is failing, or just this. Note, Voyager does not use any RMI anywhere, it's its own thing. I'd be happy to try to get more information about this failure to help the porting team, if someone could tell me what to look for. I might eventually be able to turn out a simpler test case but I won't have the hours that would take for about two weeks. For now I'm going to stick with jdk 1.1.5_v7. Thanks Nelson
Re: Versioning -- Linux JDK needs your HELP!
I've got a Redhat 4.1 system with lots of random upgrades. All the Blackdown JDKs that distributed their own libraries have worked out of the box for me, including jdk 1.1.6v4a. I seem to have the same library versions that the JDK distributes, maybe that's why there's no problem. > 1) Your system's libc version libc.so.5.3.12 > 2) Your system's libdl version libdl.so.1.7.14 > 3) Whether you had to remove libc and libdl to make Java work for you nope. $ ldd /usr/local/java/jdk1.1.6v4a/bin/i686/green_threads/java libjava.so => not found libm.so.5 => /lib/libm.so.5.0.6 libdl.so.1 => /lib/libdl.so.1.7.14 libawt.so => not found libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 libXt.so.6 => /usr/X11R6/lib/libXt.so.6 libICE.so.6 => /usr/X11R6/lib/libICE.so.6 libSM.so.6 => /usr/X11R6/lib/libSM.so.6 libXext.so.6 => /usr/X11R6/lib/libXext.so.6 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 libXp.so.6 => /usr/X11R6/lib/libXp.so.6 libc.so.5 => /lib/libc.so.5.3.12 libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1 libSM.so.6 => /usr/X11R6/lib/libSM.so.6.0 libICE.so.6 => /usr/X11R6/lib/libICE.so.6.3
Re: jdk 1.1.5_v7 -> 1.1.6_v4a, socket problem.
>> COM.objectspace.voyager.TransportException: java.net.SocketException: Socket >option unsupported >It's a v4a bug. It's fixed in our development code, but that's waiting >on me to get the library version handling code tested. I bet you were >setting LINGER or REUSEADDR -- these got broken in v4a. Ah, cool, thanks for the info. I'm not using either myself, but it's quite possible that Voyager does. Strange that most things work, just not this one part of Voyager.
Re: Re[2]: Can Java Catch Signals ?
>What I would like is just a very simple SignalCatcher for SIGTERM, >SIGQUIT, SIGHUP and SIGINT: just four signals. I want to catach them >in Java, and write the capture to a systems log. So that at least >overnight personnel would know how my java batcher died . Someone wrote just that for Linux recently, it was posted to this list. I don't know what, though. Hopefully the list is archived somewhere?
Re: Write Once Run Anywhere?
There's definitely no problem moving .class files between Linux and Win95, I do it all the time myself and it works fine. >I copied the files across using a DOS floppy disk and the linux mcopy >program. Did mcopy properly preserve the long filenames, the case, etc? Newer versions get this mostly right, but you may have better luck zipping everything first.
Re: Write Once Run Anywhere?
>However, most of your proposed solutions fall wide of the mark. Gee, so sorry. Again, there's no fundamental problem with Linux Java, the problem is something in your own environment. >Now here is a detail that may be more relevant: There are 19 .java >files in the package. The compilation under linux is making them into >19 class files. When compiling under Win95, 27 class files are >created. Two of these are for non-public classes defined in other >java files. The other six files have names like x$1.class where >x.java is one of my project files (x.class is also created by >the compilation). The $1 files (and $2, etc) are anonymous classes. If javac on Linux isn't producing them, something is very strange about your setup. Maybe they're being placed elsewhere?
OOPSLA Java VM panel notes
I was at OOPSLA '98, the big yearly American object oriented programming conference. It's mostly an industry conference, not academic. This year there was a whole lot of Java stuff at the conference, including a panel session headed by David Ungar on the "new crop" of Java VMs. These are my notes from that panel. It might be useful as pointers for what some well known Java developers think is the way to go with the VM. There's a note at the end about the lack of interest in a free Java VM.. The panel consisted of: David Ungar - Sun, Self project, now JVM development Lars Bak - Sun, Hotspot tech lead John Duimovich - IBM, VisualAge for Java Jesse Fang - Intel, working on Intel specific VM Scott Meyer - Oracle, working on Aurora (Java in Oracle DB) The panel started out with short (15 minute) talks. I mostly just copied stuff down from their slides. I put a (*) next to issues that seemed particularly interesting. Lars Bak - HotSpot architecture Adaptive Optimization the standard HotSpot story - analyze running code, compile active stuff GC - generational collector. Exact. first generation - copying collector train generations - also copying permanent generation - mark & collect <10ms pauses for GC, at least up to 60-80MB cores (*) Fast Synchronization - minimize space & speed Observation: all Java synchronization is block structured Solution: put monitors in the activation. Move object header word into monitor structure, put forwarding pointer in obj Advantage: stack allocated monitors, implict lock count, fast common case (From questions) HotSpot footprint in JDK 1.2 is close to Symantic JIT's HotSpot should support interactive development, but not in process now. John Duimovich - VM in VisualAge for Java (From questions) - this VM is really for development only, not production. so it's a little slow. Can't be *too* slow though. (*) VM issues for advanced IDE Features (incremental development stuff) Hot Method/Class replacement (semantic issues) Multiple VMs in IDE address space (size/sharing issues) Class File Sharing (no bytecode rewrite, per-VM optimization) Code snippet execution - run and test bits of code live Modify system on the fly. In process debugging support Metamodel underneath the IDE VM (???) 32 bit object pointers, untagged primitive types Objects contain accurate GC type info (ie: where pointers are) 12 byte headers for objects (wasteful, he says) class, size, flags: writeable, hash, "shape", age, misc objects can be read-only and shared (critical to share between VMs) Two GCs: exact GC - all pointer locations are known Global Garbage Collector (mark, sweep, compact) Local Garbage Collector (generation scavenger) Mixed interpreted / JIT Green Threads - better control for debugging (??!!) JIT code de-optimizable VisualAge's JIT "polymorphic inline caches" optimized stack frame build top of stack data flow / optimization Don't inline stuff - not good for an IDE Jesse Fang - Intel MicroComputer Research Lab (*) Big lesson: synchronization, JIT, GC are *all* important for Java performance Performance of implementation of JVM is hardware platform dependent How do we make Java run bets on Intel hardware? (Specific note - floating point requirements of Java are a hassle) Different JITs and GCs for different applications Maybe different JVM implementations for different applications server, small client, etc. Interested in OS independent systems. Needs better benchmarks for Java Caffeine too small, SPECs not big enough for GC testing too much emphasis on java.io and java.net Scott Meyer - Oracle's Aurora JavaVM (*) They want to run 10,000 sessions, each with a Java VM JDK is a medium sized program - 3MB of text, 6MB of data That'd be 60GB of data for 10,000 VMs. That's no good. 10,000 threads.. (doesn't work) SQL integration, same address space Inside their server a pool of worker threads (processes) that share everthing memory durations call (lifespan of a pointer) session (possibly shared, data you have to keep around) global (shared, indefinite, often read-only) Implications of sharing separate namespaces per session Abstract references simple pointers don't work with shared memory so do some sort of relative offsets different representatios for the same class Activation - support mostly immutable objects No modifications to byte-codes after class load no quick-style optimization, dynamic optimization debugger uses "parallel interpreter" Memory management Java heap is in call-duration memory Classes, methods, etc are shared (activation to store static variables) Static variables are stored in session space "Standard" generational GC Implemented with MOSS, a Metaobject System Closed universe
Re: [off-topic] Putting codebase in classpath, or equivalent
>I am running some RMI applications on a machine which doesn't have >the necessary classes installed -- the RMI class loader runs out and >grabs the ones that are needed, using the codebase property. That >works great. Yay mobile code! >I wonder if I will have to obtain the javac source and hack it to use >RMIClassloader.loadClass instead of Class.newInstance or something >like that. I think you could just build a new javac that has a different ClassLoader. Someone might have even done this already, it's sort of obvious. javac itself is trivial, all the real work is in java.lang.Compiler and its friends. One thing that's complicated, though - the Java compiler loads .java files as well as .class files. The ClassLoader doesn't, as far as I know. So the logic might be a bit screwy.
Re: Announcing JDK 1.1.7_v1a with Native Threads!
cool! Good work!
Open Java
I'd really hate to see this list get dragged into a debate about Java Linux porting team politics. The folks who have donated their effort to bringing Java to Linux - all of them - have done a wonderful job. Thanks to you all! However, there's an interesting point here: >The big problem I have is the current closed porting method is only >related to Java today. This completely ignores all possibility of >advancing java when backward compatibility is not and issue. I'm not exactly sure what the poster has in mind, but it reminds me of one of my major problems with Java. Sun has a tight lock on what "Java" is, what the definition of it is. They don't seem very interested in having people hack up the VM or the language, or in general pushing Java in any future research directions they do not directly control. I think this is horribly short-sighted of Sun, and very frustrating, but that's their position (at least, as I see it.) Unfortunately, the JDK licensing terms reflect Sun's attempts to keep Java locked up. I don't think it's fair to blame the Linux Java porting team for not making Java an open language. Their effort has been to port the Sun JDK to Linux. And they've done a wonderful job of it. What we do need, in the research community, is a more open Java system. Something we can all hack on, experiment with. It's not going to come from Sun, and therefore I suspect it's not going to come from the Linux porting team. It could possibly come from one of the free VM efforts - Kaffe, Japhar, or what Cygnus is up to. If you're really interested in building an open Java base to experiment with, I think those are the places to start.
Re: JavaDocs?
>Polardoc used to be at >http://www.ualberta.ca/~tgee/polardoc >But they seems have been zapped from the system. >Anyone of the new home? No, where'd it go? Polardoc was good stuff.. Note that all of javadoc changes in Java 1.2, there's a nice new formatter and a "doclet" spec to let you configure the look of your documents. If you're serious about doing javadoc, you might want to just start using that, or wait until Java 1.2 is out for Linux.
shuJIT: another Java/Linux JIT
You can tell the Java/Linux thing has finally taken off when more has happened than is announced on this mailing list. While browsing the ever-helpful Java Linux News http://www.w3com.com/paulcho/javalinux/ I found a link to another JIT for Linux, shuJIT, at http://www.shudo.net/jit/ Executive summary: also works with FreeBSD, says performance is about like TYA, interested in working eventually with thread migration. The author is in a research group working on "OpenJIT", a project to make the JIT itself be controllable by Java to make it easier to tune. Looks quite interesting.
Open Java, take 2
Well, it's almost like they read java-linux "In response to some disgruntled elements of the Java community, Sun Microsystems in coming weeks will announce a new process that allows non-Java licensees to have a role in defining new Java APIs across the spectrum of Java classes." Full story at http://www.infoworld.com/cgi-bin/displayStory.pl?98119.ehjava.htm
Re: shuJIT: another Java/Linux JIT
Thank you for telling us more about shuJIT. It's wonderful to have several options for JITs for Java/Linux! >If we pursuit real good performance, I think that we should deploy >the intermediate representation such as GCC's RTL and perform more >optimizations like C compiler and register allocation rather than >direct translation like TYA and shuJIT. I think you are right. Is anyone on the mailing list knowledgable about what Cygnus is doing with gcc and Java? They have Java front end and back ends for gcc now, but I believe they are targeting one-time compilation rather than JIT. I sure wouldn't want the whole gcc image in core for all my Java programs :-) >Primary purpose of my development of JIT is having our thread >migration system worked with JIT. Thread migration requires being >able to take execution context out in machine independent form. >Common JIT's don't allow us that. Ah, I understand. Thread migration is an interesting topic - I'd love to have it for my own research in mobile agents. Is there any information online about your thread migration work? >> The author is in a research group working on "OpenJIT", >Sorry for misleading my writings, I'm not a member of >OpenJIT project. I respect the leader of the project, >Prof. Matsuoka and I'm very interesting in the project. My apologies! I was looking at your web page and guessed you were working with Prof. Matsuoka. I am very sorry for misstating your affiliation.
Re: [Java-Linux] about this list ...
> 1) include [Java-linux] in your Subject:, for every mails to this list No, please don't. There's no point. This list has been running just fine for two years without anyone doing this. All mail from this list already comes with this header: Resent-Sender: [EMAIL PROTECTED] Any decent mail software can filter based on this. > I also want to ask everyone there to *please* skip all the irrelevant > when they include a message for a reply... This is very good advice for all email. One last request, specific to java-linux. For every mail you write, consider two things: "is it about Java?" and "is it about Linux?". If it's not about both topics, do not post it here. Mail about Java in general or Linux in general have no place here.
Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Why?
This thread hasn't had anything to do with Linux. I'd really prefer to keep non-Linux discussion off this list. However, I'll now gamely try to bring this back to a java-linux discussion - >Have a method, such as stop(), that sets a boolean, and in the thread >that's running, have it loop testing if the boolean has been set by >stop() or not, and if so, then exit itself. Right. But what if the thing running the thread you're trying to stop is hostile or buggy and you can't count on it to check that flag? Are there any low-level "terminate" type methods left in 1.2? >Stopping a thread otherwise is problematic because it is not clear where it >was when it was stopped (it's an ugly stop). The story I've been told when they deprecated Thread.stop() in 1.1 is they couldn't guarantee that monitors were released correctly with Thread.stop(). So rather than fix the VM, they took it out of Thread. Maybe there's a problem with the spec. All this is just to say that Java's threading model is severely broken. The JVM is about 3/4 of an OS. But it's missing a crucial part, a decent threading model. Hence, my Linux-related point - Wouldn't it be wonderful if we were allowed to hack up Sun's reference implementation, to add in better threading support and donate that code back to Sun for consideration and inclusion into the standard Java? They don't need to be afraid of us polluting the language (a la Microsoft) because we'd do it all open and free. My understanding is that the new Linux licensing stuff has been carefully written to not allow this sort of extra access to the system. Is that true? (Another example - some folks presented a really nice piece of work at OOPSLA, adding per-thread memory and CPU usage accounting to Java. Stop denial of service attacks from applets! But they had to hack it all in to an opaque JVM (Microsoft's) without any support from the VM itself, because the VM is closed. Ick! Useful work is being impeded by the closed nature of Java implementations.) [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
RE: Unix Programming Book
>>I'm looking for good intro book on unix programming. Know anyone >>that wants to sell one? >If this isn't what you wanted or expected, re-post a detailed question. Just don't post it to Java Linux [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Sun may open up Java more?
Interesting article at http://www.zdnet.com/pcweek/stories/news/0,4153,373117,00.html With a key legal victory in its pocket, Sun Microsystems Inc. (SUNW) is firming up plans to loosen its grip on the Java programming language. Sun is drafting new, more open Java licenses that could lead to the release of Java as open source code. If successful, that could exponentially expand Java's developer and user bases. [...] We think there are some interesting advantages to the open source model," said Alan Baratz, president of Sun's Java software division, in Cupertino, Calif. [...] The article goes on to talk about politics of the Microsoft case, ISO standards, etc. It explicitly mentions the Jini license as a model for how Sun might release Java. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Subject: Sun may open up Java more?
>Major issue imho. Sun/JavaSoft really has a _big_ problem. They're >trying to develop both a (1) freely available standards (most of them >with a reference implementation) and (2) software that is supposed to >bring in money, all at the same time. That's why I say that Sun's actions look to me like a company that hasn't quite figured out a clear strategy to commercialize Java. It feels to me like there's a struggle going on inside, between traditional corporate managers who say "oooh, proprietary, closed, must charge lots of money" and a bunch of very clueful engineers who are saying "open systems, make it free, let it grow." Or to put it harshly - Java is the first big new idea we've seen from Sun in awhile. Suddenly, it's caught on, but they don't know how to capitalize off of it. The good news is the forces of openness seem to be slowly winning out. The release of Jini with source is a big thing. So is the semi-official support for Linux. >What Oracle believes, and what Marima believes, and what I personally >believe is that there should be one standard and lightweight Java >platform, containing only a set of core Java packages (no AWT, no >Swing, no CORBA, no RMI), having well-defined behaviour, suited for >realtime and multithreading/multitasking applications. The problem is there are several smaller Javas. PersonalJava, at least two different Sun embedded Java systems, etc. You're right about size, btw. JDK 1.2 is about 3 times as big as JDK 1.1 (which itself was twice as big as JDK 1.0). A really nice reference for a perspective on all of Java is the "Java Developer's Almanac", a pocket dictionary sized reference to all of Java 1.2b3. It has a listing of every class and member and which version of Java they came in, whether they're in Personal Java, etc. Also a summary in the back of language growth statistics. I find it useful. It's $15 from Amazon, http://www.amazon.com/exec/obidos/ASIN/0201379678/nelsonminar [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Why?
>The whole Thread.stop() thing is very nasty in non-green-thread >systems. The core OS may not support the needed mechanisms to cleanly >stop a thread at various points (such as during a blocked I/O) URGH! So the entire Java language is weakened to support OSes with poor threading support. Even *after* we have a library, green threads, that lets you work around bad threading in the OS? Not being able to stop a thread preemptively is a really big problem. How do you stop an applet in a browser that happens to be buggy or malicious and has spun off in a tight loop? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Using "setSize" with a Frame.
>If I use setSize(100,100); I get a frame that's smaller than that: >something like 90x72 I think: I've deleted the source and can't be >bothered retyping it. Top level frame sizes unhelpfully include the size of the window decorations - titlebar and borders. It was a really bad choice, IMHO, but it's there. There's some magic way to get the size of the decorations from Java and do the math yourself. Another fun thing is that Frames in Windows can't be any narrower than about 108 pixels - that's the minimum width of the title bar. Platform independent GUI is suprisinglyh hard. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Jikes released as Open Source
I'm happy to spread the news that IBM has released Jikes as open source. We Java/Linux folks have been happy to have Jikes as a fast, correct drop-in for javac under Linux. Now, IBM and the Jikes team have released the sources to Jikes as well, allowing us to look at and improve the compiler. The slashdot story is at http://slashdot.org/articles/98/12/05/1216225.shtml [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: [FYI] Java violates US patent?
>miscrosoft (mbasic) did. >cbasic did. even Applesoft BASIC did it Let's do it, let's byte-compile our files! Nelson, musical. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Periodic curmudgeonly reminder: Java *and* Linux
We've had a lot of posts on java-linux recently that are generic Java questions, that have nothing at all to do with Linux. I'm here to remind the list, once again, that this sort of question is *not appropriate*. Do not post questions here unless they are about the specifics of Java on Linux. Furthermore, I would encourage regular members not to answer these messages here either, so as not to encourage people to keep posting inappropriate questions. I don't mean to sound unkind, but this list has an important function: to discuss issues having to do with running Java on Linux. Off topic messages dilute the list and make it less useful for everyone. Thank you, Nelson [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: A file system for organising java stuff ?
>Anyways, what occurred to me during the new years break is to arrange >my java stuff into a file system along the lines used in linux >systems (unix in general?). It might make sense for the Java Linux principles to work with some of the major distribution folks and the people behind the Linux filesystem standard to come up with a standard Java directory tree for Linux. The main requirements I see are: Dealing with the way the JDK wants to be installed. At least in JDK 1.1, it's quite inflexible about where its pieces are. Nicely supporting the new Java 1.2 class loading system, in particular the support for a directory of jars. Making it easy for people to install new jar files and new shared libraries for the JVM to load. Making it easy to install alternate Java implementations - a new VM (Kaffe or Japhar), new class libraries (Classpath), etc. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: jikes & '$' in variable names....
> 16. boolean Size$readonly = true; >*** Lexical Error: Illegal token >now standard javac has nothing t complain about this is there a >way i culd continue to use jikes? is it a problem with my setup? RTFM. Use "jikes -$". I'm not sure why they make that an option that's off by default, but you can turn it on. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: RMI hangs on remote calls
>I don't know if this is a Linux-only problem or Java-specific since I >run the servers under Linux. It's a Java RMI thing. There's an rmi-users mailing list that you might want to look at. >whenever events are pushed to this client while in this state, the >Linux server hangs sending this event for a long time (I've seen it >hang for one hour!). This is the expected behaviour for RMI; all remote method calls are synchronous, so you have to wait until the client returns. If the client is hung in a bad state you might just delay for a long time. Worse, you can't tell this condition from a random network slowdown. RMI should timeout, though, and I believe it tries to sooner than 60 minutes. I thought there was even a Java property you could set to control the timeout, but I can't find it now. This part might be Linux specific, since the timeout stuff is a socket option. Can anyone on the porting team comment? As for what to do about it, you might need to implement some sort of server-side asynchronous messaging. For event delivery, I have some simple code that forks a thread for every single message. That's not such a good idea. A thread per receiver is a bit better. This is a fundamental limitation of RMI. Sorry :-( [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: RMI hangs on remote calls
>Do you know how to contact the rmi-users mailing list? I'd like to check >them out. Try [EMAIL PROTECTED] There's an archive at http://archives.java.sun.com/archives/rmi-users.html BTW, I found a cryptic reference to a property sun.rmi.transport.connectionTimeout that might be settable, but then again might not be standard or approved. There's also some more relevant information at http://developer.java.sun.com/developer/techDocs/SearchData/dd/rmi/179.html >I guess I understand RMI's behavior since there's no such thing as a >fixed amount of time that a method ought to execute within. It's just >a pain when the method you call hangs up. It's a real problem. I think this is a serious limitation in RMI; most other distributed object systems have some sort of asynchronous messaging capability built in. But you can work around it. >I've been reluctant to use a thread per client (there can be hundreds >of clients) since I'm worried about running so many threads Sure. If you use thread pools and reuse threads, you can have a lot of control. But that code gets tricky. If this is a commercial system, there are commercial frameworks that are more robust or scalable than RMI. Ask me offline, though, it's not really appropriate to java-linux. >Is there much experience out there with running lots of threads? I >don't even know how well (though I could write a test program, but I >have so much other work to do!) green threads would work in the JVM >if I had hundreds of client push threads responding to each event. I'd love to hear about Linux users' experiences with lots of threads, too. Where does it break, with both green threads and native threads? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Problems with Xaccel Driver and Swing
>In order to support the S3Trio3D card in our IBM computer, we >purchased the "Xaccel" X server from Xi Graphics. This works fine >except for our Swing Java applications. If we run the card in its >accelerated mode, then the display is corrupted and the Swing JFrame >never fully displays. If we run the card in "frame buffer only" mode, >then the display is OK, but our Swing application will only start one >time withour rebooting the computer. This is almost certainly a bug in your X server. An X client should not be able to crash the X server; if the X server crashes, it is a bug in the server. I've had bad luck with the Xi Graphics servers, but maybe they can fix your problem. Try another server? Maybe XFree86 or the SuSE X servers support your card. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Strange Class.forName() problem
This question has nothing to do with Linux, it's really not
appropriate here.
>c = Class.forName("String");
>java.lang.ClassNotFoundException: String
>c = Class.forName("java.lang.String");
You have to use the full package name if you're using reflection-like
methods to work with classes. The imports at the top of the file are
only for the compiler; you're doing something dynamic, at runtime.
I'm not sure what you're doing, but typically you don't use
Class.forName() very often. Only use it if the classname has to be
dynamic. An alternative is Class c = java.lang.String.class.
[EMAIL PROTECTED]
. . . .. . . . http://www.media.mit.edu/~nelson/
Native threads in Java
>On the other side creating native threads is an expensive operation. >Especially on Linux, where threads are heavy-weight system processes. Can anyone tell me whether the Linux port of native threads uses some sort of thread reuse mechanism to cut down on the OS overhead? Ie: if I fire up a new thread, then it stops, and then I fire up a second new thread, does Linux/Java reuse the kernel thread from the first case? In my current research I'm firing off threads left and right, without any sort of pooling. The performance is OK with green_threads, but I haven't tried it out with native. I'd really prefer not to have to write my own thread pooling; my feeling is that this is something the VM can do better. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
RE: Another JDK 1.2 Status Report
>But what about "true" multitasking? In my experience, green threads >don't do that very well. In Java, green threads may not do multitasking at all. Java makes no guarantees about preemptive threading - it's entirely correct for one thread to dominate the CPU, as long as it's the highest priority. Java makes very few guarantees at all about thread execution. If I understand the spec right, it's even correct for Thread.yield() to do nothing at all, although that would be pathological. So it's good to use native threads, because you get preemptive multitasking, but code that relies on that is non-portable. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Green/Native threads
>All that other discussion about Linux process table slots and >implementation details is interesting, but not really relevant to the >distinction between light and heavy. There's one important difference - you can only have as many threads in Linux as you can have processes. And there's a suprisingly low upper limit on that, something like 256? I'm one of those wacky people who likes the idea of writing programs with thousands of threads (most stopped most of the time), so that's a bit of a drag. I'm curious how Java thread priorities are layered on top of LinuxThreads.. When a thread of high priority becomes runnable, is a SIGSTOP sent to all lower priority threads to make them stop until the high priority thread finishes? I sure wish Java's threading model was different. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Green/Native threads
A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in /usr/src/linux/include/linux/tasks.h. The default is 512, but then there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I understand right, that means that a Java process using native threads is limited to 256 threads in the default kernel. It's possible that boosting NR_TASKS up and recompiling the kernel will Just Work, but I don't know. I also don't know the implications on kernel memory used or scheduler performance. The reason kernels have compiled-in limits like this is it greatly simplifies and speeds up the scheduler. Dealing with dynamic memory structures is a mess, particularly if you can't rely on the VM system in the kernel to manage your memory. Most Unix kernels I know have similar limits. Another issue is pre-emptive multitasking. Java does *not* guarantee pre-emptive multitasking, period. So in some sense, a correct Java application should not care whether it's green threads or native threads. Personally, I think it'd be nifty if Java/Linux were higher quality than other Java implementations, and had nicer threading. The VM to beat here is Windows NT, at least under Java 1.1. The problem is, what improvements should one make? It's not clear that guaranteeing preemption is the best thing, since Java is speced to not guarantee it itself. Personally, I'd like to see thread creation and switching time be optimized heavily, and secondarily to make sure that Java/Linux can deal with a whole lot of threads at once. Another angle to pursue is to follow what the Java Real Time Extension people are up to; they will presumably need to augment the Java threading model, and if Linux can track that we might have a leg up. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Green/Native threads
Nathan Meyers asks: >But I'm always curious about "wacky people" who like to use thousands >of threads (or tons of memory or zillions of levels of recursion, >etc.). Is that approach fundamental to solving the problem >efficiently, or do you use it because it's convenient and/or cool? A bit of both. My work in Java centers on building distributed agent systems. Roughly, for me an agent is exactly a Java object with its own thread. (An "Actor"). So my system can only support as many agents as there are threads available. That's a fundamental requirement of my model of computation, and I'd really rather my OS supported lots of threads. Typically, though, I have less than 50 agents in one process, so it's not a big problem. The other reason I need lots of threads is to simulate asynchronous messaging. When an agent calls a method on a remote agent (via RMI), they don't necessarily want to wait for the remote agent to return. Ie: I want some method calls to be asynchronous. The naive way to implement that is to fork two threads per message call - one for executing the call asynchronously, and one (that mostly sleeps) to implement a timeout on the call. There are more efficient ways to implement these things - you can do some thread pooling for message execution, and if you're clever you can have one thread for the whole VM managing timeouts. But they're a pain, and I'd dearly love it if the VM could just support the simple implementation directly. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Opengroup JDK port for Linux!
Reading the Linux Weekly News this week, I just found a mention of a port of the JDK 1.1.6 for Linux from the OpenGroup in Grenoble. The URL is http://www.gr.opengroup.org/java/jdk/linux/ The big news is it has native threads. You can't download the binaries yet, but they said they'll make them available soon under a non-commercial use license. They've also got a version of gdb that debugs threads in Linux. OpenGroup (in Cambridge) also produces TurboJ, a Java compiler that supports Linux. Their licensing terms aren't exactly clear, but it seems to not be free to use for anyone.
Improving Java/Linux support
>Judging from the volume of "when will 1.2 be ready?" messages, it's >clear that interest in the Blackdown work is reaching some sort of >critical mass. With 1.1.7, Linux is either the best or second best Unix platform for running Java. Solaris is obviously alright, but most of the other Java ports (SGI, Digital Unix, etc) have really bad problems. The Blackdown team has produced quality. Combine that with the general interest in Linux and you can see why Java on Linux is so desired. Heck, we even had one of Sun's big distributed Java gurus asking us when 1.2 would be ported for Linux :-) >Perhaps when the dust settles from the 1.2 port, it might be possible >to arrange more formal and detailed visibility into what work is >being done, what's under consideration, what's of interest, and progress. I'd like to see more information about the porting process myself, but that's asking the porting team to do even *more* work. The old rules for Java made doing a Linux-style port awkward; things had to be discussed in secret, code couldn't be released, etc. What's the impact of the new community source licensing? Maybe we can open up the porting process some? I haven't reviewed the licenses well enough. A second thing to watch is the growth of Japhar and Classpath. My impression is that this code is quality, that we might soon see a truly viable open source Java. Of course, I said that about Kaffe too, but that's never quite come to fruition. Another interesting option is to see if we can get financial support for the Linux porters. I was sort of hoping Sun would do this, by donating some engineers' time, but maybe that's not come together. Maybe some of the companies relying on Java/Linux could be convinced to chip in some money? That would again put more responsibility on the part of the porters, but in this case with a reward for doing it. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Mailing list trouble
This mailing list has troubles, yes. The maintainer (Karl Asha) asked here about a month ago if someone else could host it, because he didn't have the time or resources to keep it going. Now might be a good opportunity for someone to contact him about rehosting the list. His email address is [EMAIL PROTECTED] Please, if you do make this offer, be sure that you have the resources and commitment to see it through. We had a fiasco about 6 months ago trying to move the web pages to a site that dropped the ball. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Hatred of 1.2 messages
Gerald Gutierrez writes: >What I propose is simple. FIRST, for every message regarding the >status of JDK1.2 on Linux, refer the inquirer to the 1.2 Status web >page, and refain from degrading the reply by any of your personal >comments. SECOND, the web page should provide a best guess as to when >the porting should be finished. And you're volunteering to do both of these things! Fabulous! Go for it. You're probably going to have a hard time doing the SECOND thing, but hey, good luck. Just to give a little perspective on the JDK 1.2 situation, has anyone other than Sun released a Java 2 platform yet? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: javac 1.2 a real pig
>The problem is that the jikes compiled code does not pass the >bytecode verify stage. If you run the same code under JDK 1.1 and it >works then you know for sure that that is the problem. Well, not exactly. You might also want to try runnign it with JDK 1.2 without verification. "oldjava" does this, and is there a -noverify flag? >Please post notes about this problem on the jikes mailing list. A >small example that shows the problem would be good too. yes, sample code is majorly useful to find bugs. And now that we have the source for Jikes, we can fix the bugs ourselves! [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to create a NetworkClassLoader in JDK1.1.x?
(An aside - why do people keep dumping questions not appropriate to java-linux on this list? It's not even ignorance - people keep saying things like "I know I should ask this elsewhere, but...". Folks, that's just plain rude. Please stop.) At the risk of encouraging more off-topic posts, I'll answer this: >Does anyone know how to create a NetworkClassLoader? A ClassLoader >loading classes from a URL such as http://www.test.com/testdir/ ? You're going to be much happier doing this in Java 1.2, but if you have to do it in 1.1, you're sort of on your own. RMIClassLoader and AppletClassLoader both have the basics of what you need, but not readily in the form you need them. A good article on how classloaders work is at http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Jikes and Java 1.2
David Shields, one of the Jikes authors, asked me to forward the following: --- Jikes now supports the Java language changes added in 1.2. We'll soon be adding support for the three new classpath-related arguments ( -sourcepath, -bootclasspath and -extdirs) added to 1.2 javac. dave http://www.ibm.com/research/jikes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tya 06 + jdk_1.1.5_v7?
Does tya06 work with sbb's latest port of the JDK, 1.1.5_v7? TYA's configure script breaks when it tries to detect the Java version, but if you hack it so that it sees Byrne JDK 1.1.5 libc and use the same bit of configuration that's used for the version that matches java*root:02/25/25* it seems to work OK, I got about a x2 speedup on my application. But JITs are a subtle thing, so I thought I'd ask.
jdk 1.1.5_v7 crashes
I've been having some random crashes of the JDK 1.1.5_v7. I believe
they're related to a window being disposed. This never happened with
sbb's JDK 1.1.3, but it happens maybe 15% of the time when I call
dispose on a Frame with 1.1.5.
Anything else I can do to pin this down? I'll try to see if I can
catch out the same bug in java_g, but since it's notdeterministic it's
hard to reproduce.
Here's the segfault from java:
SIGSEGV 11* segmentation violation
stackbase=0x4156b000, stackpointer=0x4156ac74
and the thread that looks to be the guilty party.
*current thread*
sun.awt.motif.MComponentPeer.dispose(MComponentPeer.java:215)
sun.awt.motif.MFramePeer.dispose(MFramePeer.java:101)
java.awt.Component.removeNotify(Component.java:2526)
java.awt.Container.removeNotify(Container.java:1149)
java.awt.Window.dispose(Window.java:177)
java.awt.Frame.dispose(Frame.java:372)
edu.mit.media.nelson.straum.agent.CreateAgentUI.createAgent(CreateAgentUI.java:70)
edu.mit.media.nelson.straum.agent.CreateAgentUI$2.actionPerformed(CreateAgentUI.java:45)
java.awt.Button.processActionEvent(Button.java:254)
java.awt.Button.processEvent(Button.java:227)
java.awt.Component.dispatchEventImpl(Component.java:1764)
java.awt.Component.dispatchEvent(Component.java:1704)
java.awt.EventDispatchThread.run(EventDispatchThread.java:63)
And the relevant method in my application (line 70 of CreateAgentUI.java)
newAgentWindow is a Frame that was created by this same class - the
idea is that the CreateAgentUI class puts up a form (newAgentWindow),
waits for the user to click a button, then destroys the newAgentWindow.
public void createAgent() {
String remoteHost =
server.getServerDirectory().resolveToAddress(serverNameField.getText());
BaseAgent newAgent = null;
try {
newAgent = (BaseAgent)agentClass.newInstance();
} catch (Exception e) {
Debug.println(Debug.CRITICAL, "Agent could not be created: " + e);
return;
}
((MonitoringOneHost)newAgent).setHostToMonitor(remoteHost);
newAgent.launch(Global.localServer());
newAgentWindow.dispose(); // THIS IS LINE 70
}
--PAA27523.895607981/pinotnoir.media.mit.edu--
--QAA24419.895608000/aleve.media.mit.edu--
instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
I'm still getting some occasional instability when disposing of Frames in the Linux JDK - I get IOT trap/Abort. My application is crashing randomly and it's driving me nuts. Is there anything I can do to help find this bug (I can send complete class files and instructions that crash the system fairly often)? Can anyone think of a work-around? The crash happens right when I call Frame.dispose(). I'll include the stack frame for the running thread when the thing dies. The frame contains several components: a Label, a TextField, and a Button, all in a FlowLayout. The last stackframe in my code (CreateAgentUI.java:70) is calling Frame.dispose() on a frame for a dialog box it created awhile ago, in response to a user clicking on a button in that frame. Is it possible that there's some sort of race condition where the Button si being destroyed while the AWT still needs it? The bug happens with both java and java_g, but not entirely reproducably. sbb once asked me to test this while DO_NOT_FREE was defined. Unfortunately, the bug is random enough that I can't test it easily. Next time the moons are in the wrong alignment I'll try to do that. Here's the stack frame that seems most relevant: "AWT-EventQueue-0" (TID:0x407209c0, sys_thread_t:0x4154bf04, state:R) prio=5 *current thread* sun.awt.motif.MComponentPeer.dispose(MComponentPeer.java:215) sun.awt.motif.MFramePeer.dispose(MFramePeer.java:101) java.awt.Component.removeNotify(Component.java:2526) java.awt.Container.removeNotify(Container.java:1149) java.awt.Window.dispose(Window.java:177) java.awt.Frame.dispose(Frame.java:372) edu.mit.media.nelson.straum.agent.CreateAgentUI.createAgent(CreateAgentUI.java:70) edu.mit.media.nelson.straum.agent.CreateAgentUI$2.actionPerformed(CreateAgentUI.java:45) java.awt.Button.processActionEvent(Button.java:254) java.awt.Button.processEvent(Button.java:227) java.awt.Component.dispatchEventImpl(Component.java:1764) java.awt.Component.dispatchEvent(Component.java:1704) java.awt.EventDispatchThread.run(EventDispatchThread.java:63) My application has a tangle of threads going every which way, so I won't include them all. Here's the rest of the threads that are Runnable: "XEventServer Reader" (TID:0x4071f3d8, sys_thread_t:0x4152af04, state:R) prio=5 java.net.SocketInputStream.read(SocketInputStream.java:92) java.net.SocketInputStream.read(SocketInputStream.java:75) java.io.InputStreamReader.fill(InputStreamReader.java) java.io.InputStreamReader.read(InputStreamReader.java) java.io.BufferedReader.fill(BufferedReader.java) java.io.BufferedReader.readLine(BufferedReader.java) edu.mit.media.nelson.straum.sysinfo.unix.XEventServer.run(XEventServer.java:96) java.lang.Thread.run(Thread.java) "TcpTransporter Server" (TID:0x406fc458, sys_thread_t:0x41485f04, state:R) prio=5 java.net.PlainSocketImpl.accept(PlainSocketImpl.java:387) java.net.ServerSocket.implAccept(ServerSocket.java:206) java.net.ServerSocket.accept(ServerSocket.java:189) COM.objectspace.voyager.VoyagerDefaultServerSocket.accept(VoyagerDefaultServerSocket.java:26) COM.objectspace.voyager.TcpTransporter.run(TcpTransporter.java:118) COM.objectspace.voyager.ReusableThread.run(ReusableThread.java:132) "Async Garbage Collector" (TID:0x406fbc98, sys_thread_t:0x4141bf04, state:R) prio=1 "Idle thread" (TID:0x406fba08, sys_thread_t:0x413faf04, state:R) prio=0 --KAA24401.900599060/pinotnoir.media.mit.edu--
Re: Linux/Java/KDE
>> Are there any plans to port java so that it uses the KDE toolkit >> (http://www.kde.org)? >I don´t know, but I consider this a good idea. Any volunteers :) ? There's a lot of issues with Qt licensing. The free alternative is GNOME, http://www.gnome.org/. If someone gets serious about doing a port please consider the two platforms, in particular license issues. Doesn't all this toolkit stuff get easier with Java 1.2 and Swing?
new VolanoMark benchmark scalability results
Interesting article comparing Java VMs at http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html The results here are oriented towards testing lots and lots of connections. Suprisingly, Linux does quite poorly with both the JDK and TowerJ. The article suggests that this might not just be a slow Java, but rather problems with Linux.
3rd JDK for Linux/Intel available (OpenGroup)
On the freshmeat tip, the OpenGroup has finally released their port of the JDK for Linux. http://www.camb.opengroup.org/RI/java/linux/ This one is based on native Linux threads. Three JDK ports for Linux, hooray! And now with yet another delay for JDK 1.2, we're almost caught up :-)
Activism for Java on Linux
>About HotSpot: I really wouldn't know. Would like to see it myself >too. Linux allways comes last (JDK 1.2, RDMBS's etc), but things are >changing I guess... for the good. Does anyone with knowledge of Sun politics know how we can effectively lobby for more support for Java on Linux? I really don't understand what's going on at Sun. The official word is they are "supporting" Linux, but the results they've delievered have been less than exciting. No offense, Blackdown guys! You're doing great. But have you really gotten any help from Sun? The part I don't understand is every single person at Sun I've ever talked to is enthusiastic about supporting Linux. There's a good technical case to make for it now, too - Java is moving towards the embedded systems market (notably, through Jini), and Linux is better suited for this application than pretty much any other mainstream OS. Is there some internal politics going on that is making Linux be second fiddle to Windows? Anyway, if anyone with some understanding of Sun is interested in working on putting together some effective activism, please contact me. Maybe we can make something happen. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Activism for Java on Linux
I realized in my first message that I was a bit unclear. I want Sun to put Java on Linux on the same footing internally as Java on Windows or Java on Solaris. I have no idea if this is realistic, because I don't know enough about Sun politics. I think it is a reasonable goal business-wise for Sun, though, and I think it would benefit the Linux community. I'm not arguing here that Sun should make Java all free, or even generate special licensing terms to Blackdown. Personally, I'd rather see all that effort go towards developing a free Java alternative, like Japhar+Classpath. I'm asking that Sun devote internal effort to Linux ports. From what I've heard, this wouldn't even be that much work for them. I firmly believe that Java is the future of Internet programming. And I believe that Linux is best positioned to be the future of Internet operating systems. How do we bridge the gap? My impression is that the current deal with Sun isn't working out very well. Blackdown team, correct me if I'm wrong. So maybe another tack is appropriate? I have no idea if these goals are realistic, or even a good idea. But I want to raise the issue, see what people think. Another question for the mix - what's up now with the production version of the JDK? Is there any hope of a Linux port of that? I hear rumours that it is quite good. >What worries me is that SUN will not give HotSpot for free so I don't >know how the licensing will be worked out for the Blackdown organisation. I don't expect Sun to give out HotSpot. I just want them to make a commercial version for Linux as well, and release it at the same time as the Windows version. >I also read an article where the say that SUN was the last major >company to endorse Linux I guess that they are scare of Linux and >want to protect their beloved Solaris. That's the politics of which I want to understand more. Personally, I can't imagine anyone inside Sun thinking Solaris x86 is a viable long term product. Is that accurate? And what's going on now with the SCSL? Sun isn't just licensing the JDK under SCSL, it's licensing Solaris, even the Sparc chip design. That's pretty amazing. Is this new semi-open source movement in competition with Linux? Spiritual cooperation? Unrelated? [Feel free to answer me off-the-record, or anonymously, I'll respect your privacy.] [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE PLAF
Anyone up for java.themes.org? We could get Raster to design us a fancy videogame-looking PLAF for Java :-) [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: go back to gzip!
>Nobody has bzip2, whatever that is. You're making your product less portable. It always amazes me when people using free software are rude to the folks who are doing the work. Your message was impolite, and you were too lazy to go find bzip2, thereby wasting everyone else's time. You can get bzip2 at http://ma.us.mirrors.freshmeat.net/appindex/1998/04/15/892661723.html [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Curious about glibc 2.1 also... Redhat 6.0?
I'm also curious about the status of the JDK on glibc 2.1 systems. How hard will it be to make the JDK run with glibc 2.1? Is it easy to keep a glibc 2.0 around so JDK will run? Does anyone know what glibc Redhat 6.0 is planning to ship? (Anyone seen 5.9?) I think it's important that some JDK run on the major distributions.. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recompilation only when needed
This question is only marginally Linux related, but since Linux javac is so slow, it's a special concern for us :-) >I have been trying to get javac (1.1.7 for linux) to recompile only >those java-files newer than their class-files. This stuff doesn't work very well. javac -depend is undependable, and jikes' isn't much better. If you're using jikes and you have a reasonably sized sourcebase, you're better off just recompiling all the files everytime rather than trying to selectively compile a subset. I have a 2 line project in 100+ files. Compiling everything with jikes one file at a time takes about 2 minutes. Compiling them all in one command takes 10 seconds. Compiling *two* files seperately takes about 15 seconds - so for me, compiling everything everytime is better than even trying to figure out which two files have changed. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RMI troubles
>I have been trying to get RMI to work for some time now. RMI works fine in Java/Linux - I rely on it heavily with my code, and it works as well as it could. (There are some interesting issues relating to socket limits and 50+ simultaneous calls, but that's Linux and RMI's fault, not the Linux port). >I can run the server class, and it binds with the registry just fine. >When I try to connect with the client, it tells me that the _Stub >class cannot be found. This is a basic RMI problem - you should read the RMI FAQ on Sun's web site. Classpaths in RMI are a bit subtle. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re: Sun's Agenda?
I share the frustration expressed recently about the status of Java on Linux. We've always been somewhat second class citizens. The problem is most definitely not Blackdown's fault - they're doing great given their resources and the licensing structure of Java. As for Sun's "agenda", my feeling is that it's not that well defined, in particular for Linux. There's the Sun corporate stance, of which there are many competing factors. The Solaris organizatoin doesn't necessarily see eye to eye with the Java organization, and lord only knows who is thinking what about Solaris/x86. Then there are plenty of geeks inside Sun and inside Javasoft who love Linux themselves, use it for their own work, etc. The most frustrating thing is I can't see any way, in the current structure, to improve the porting of the JDK. Blackdown's doing as well as they can. Personally, I think there are only three ways Java is going to get better on Linux: Sun decides Linux is a priority and assigns engineers. I think they have a real case for doing this to support Jini - they need a platform that can easily embed Java, and Linux is a good high-end way to do that. Of course, this drags us into the embedded Java mess... One of the free Java efforts (Japhar, Kaffe, Cygnus' new thing) gains enough momentum to be a serious JDK replacement. One of the non-free Java efforts (IBM's VM, Symantec's stuff, etc) gets ported and supported on Linux. I have no idea which of these is most likely or most desireable. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HotSpot?
>When Sun formerly stated that Hotspot would be a commercial product >there was not much competition around. Now fierce competition is here. And reading between the lines, maybe Hotspot isn't that hot afterall. The speedups they claim (2-4 times, presumably over a simple JIT?) are nice, but not earth shattering. And the "long lived server" emphasis on the web site suggests that the performance isn't so good for things that don't run for a long time (like, say, most user applications). I hope I'm wrong - the technology underlying Hotspot is very cool. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
politics - "Rival Java consortium founded"
There's an article on the latest move in Java standards politics: http://technews.netscape.com/computing/technews/newsitem/0,290,36236,00.html?pt.netscape.fd.hl.ne A group of companies that don't want to play by Sun Microsystems' Java rules have formed an outside work group into an outfit called the J Consortium. The companies, including Hewlett-Packard, Microsoft, and NewMonics, have formalized an ongoing effort to set a standard for a component of Java called "real-time" extensions My feeling is this split actually has some meaning. HP knows what they're doing in the embedded market. Not clear what the Linux angle on this is. Seems like we're not players at all. Replies directed to me alone, since java-linux doesn't really need lots of political discussion. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: position of java applications starting up.
>i was wondering if it is possible to set the position of >a java GUI once it starts up. Whenever i run a application >it starts up in the corner of the screen. Like people said, setLocation() will do that. But I have a related question - how do I *not* set the position of a window? I don't call any methods to set the position, yet my window manager thinks the window is demanding to be placed at 0,0. I'd rather let the window manager decide itself. Am I doing something wrong here? Is this a (small) JDK bug for X? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: position of java applications starting up.
>>Take a look at MComponentPeer.pInitialize(). It sets the location of >>the window (to 0,0 if no setLocation call has occurred). >This bug annoys me intensely. bug id 4102292 It annoys me too. Thanks for finding it in the Bug Parade. I can live with this, so my question here is more political than technical. According to the license with Sun, can the Blackdown porters change this behavior? Would they want to? I presume this isn't in any Java spec. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
documenting all the Blackdown environment variables
I'd like to make a list of all the environment variables the Blackdown
JDK uses to change its operation. I don't think there is a
comprehensive list anywhere. Here's what I know, can others correct
this or add to the list? Maybe we can get it into README.linux on the
next release.
1.1 refers to 1.1.7_v3a, 1.2 refers to 1.2pre-v1
Variable1.1? 1.2? Settings
THREADS_FLAGyesyes"green" for green threads
"native" for native threads
JAVA_COMPILER yes???If set to "tya", then "libtya.so"
will be installed as a JIT compiler
NS_JAVA yes???If set, runs a JDK with no AWT or X11.
Starts up faster, no graphics. See
also DISPLAY
DISPLAY yes???If unset, acts like NS_JAVA is set
DYN_JAVAyes???If set, Motif is dynamically linked
instead of using the Motif statically
linked into the JDK bins.
JDK_NO_KERNEL_FIX yes???"true" to remove fix for kernel
accept() bug
DO_NOT_FREE yes???Turn off freeing memory entirely.
DO_NOT_CHECK_MEMyes???If set, removes some checks for
double-freed memory bugs associated
with AWT. Dangerous, but slightly
faster.
[EMAIL PROTECTED]
. . . .. . . . http://www.media.mit.edu/~nelson/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New list of Blackdown JDK environment variables
Folks seemed to like my list of JDK environment variables, so here's a
second pass incorporating all the feedback I got. Steve, are the
DO_NOT_FREE and associated variables supported in 1.1 native threads?
--
The following is documentation for environment variables the JDK
supports. Note, this is not a comprehensive document for all
variables: generic variables like LD_LIBRARY_PATH and LOCALE are
not mentioned unless they have Jave-specific meanings.
1.1 refers to 1.1.7_v3a, 1.2 refers to 1.2pre-v1. "green" means the
option is only supported in green threads.
Variables with Blackdown specific behaviour:
Variable1.1? 1.2? Settings
THREADS_FLAGyesyes"green" for green threads
"native" for native threads
NS_JAVA yesno If set, runs a JDK with no AWT or X11.
Starts up faster, no graphics. See
also DISPLAY
DISPLAY yesno If unset, acts like NS_JAVA is set.
See also man page X(1)
DYN_JAVAyesno If set, Motif is dynamically linked
instead of using the Motif statically
linked into the JDK bins.
JDK_NO_KERNEL_FIX yesgreen "true" to remove fix for kernel
accept() bug
DO_NOT_FREE yesgreen Turn off freeing memory entirely.
DO_NOT_CHECK_MEMyesgreen If set, removes some checks for
double-freed memory bugs associated
with AWT. Dangerous, but slightly
faster.
Generic JDK (may be Unix only):
CLASSPATH yesyesSee JDK documentation
JAVA_COMPILER yesyesIf set to "tya", then "libtya.so"
will be used as a JIT compiler if it
is installed correctly.
[EMAIL PROTECTED]
. . . .. . . . http://www.media.mit.edu/~nelson/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Redhat and Kaffe (was Re: First Step)
What do people here think about Redhat having Kaffe installed by default as the binary "java"? I think it's a bad idea because Kaffe really doesn't support enough Java to be useful, at least to me. On the other hand, I want to support Kaffe and Japhar and other free software efforts, I don't want to exclude them. I've just seen a lot of people be confused by "why doesn't Java work on Redhat?". Does anyone know the story on the Klasses.jar they distribute as part of kaffe? What's the license terms, how is it different than classpath? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
environment variable list, take 3
Per request, I've reformatted the list so that there are specific JDK 1.1 and JDK 1.2 sections rather than mixing them together. I am still not sure if this is comprehensive. If someone with access to the Blackdown sources would be so kind as to grep through them for calls to getenv(), that would help a lot. -- The following is documentation for environment variables the JDK supports. Note, this is not a comprehensive document for all variables: generic variables like LD_LIBRARY_PATH and LOCALE are not mentioned unless they have Jave-specific meanings. 1.1 refers to 1.1.7_v3a, 1.2 refers to 1.2pre-v1. The Blackdown ports support both green threads and native threads - some variables are only valid in one of the two. Variables with Blackdown specific behaviour Java 1.1 and Java 1.2: VariableSettings THREADS_FLAG"green" for green threads "native" for native threads Variables with Blackdown specific behaviour Java 1.1 and Java 1.2, green threads only: VariableSettings JDK_NO_KERNEL_FIX "true" to remove fix for kernel accept() bug DO_NOT_FREE Turn off freeing memory entirely. DO_NOT_CHECK_MEMIf set, removes some checks for double-freed memory bugs associated with AWT. Dangerous, but slightly faster. Variables with Blackdown specific behavior Java 1.1 only, all threading models: VariableSettings NS_JAVA If set, runs a JDK with no AWT or X11. Starts up faster, no graphics. See also DISPLAY DISPLAY If unset, acts like NS_JAVA is set. See also man page X(1) DYN_JAVAIf set, Motif is dynamically linked instead of using the Motif statically linked into the JDK bins. Generic JDK variables, Java 1.1 and Java 1.2: VariableSettings CLASSPATH See JDK documentation JAVA_COMPILER If set to "tya", then "libtya.so" will be used as a JIT compiler if it is installed correctly. If set to "none", no JIT will be used. Java 1.1 uses no JIT if unset Java 1.2 uses Sun JIT if unset [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sunwjit slows down JDK
>This posting reminded me of my many struggles trying to find a neatly >compiled list of java properties. Does anyone know if such a list >exists for JDK properties? There's an excellent list in the Java Developer's Almanac, an all-around nifty reference: http://www.amazon.com/exec/obidos/ASIN/0201432986/nelsonminar [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 117 for Linux
>I am attempting to compile an RMI application with the 1.17 version >of the Blackdown JDK, and when I do, I get a Segmentation Fault. This >does not leave any trace of why the fault occured. I use RMI extensively in JDK 1.1.7, under Redhat 4.2, 5.2, and 6.0, and haven't run into this. Is it rmic that's failing? Does it fail on any file, or only one specific one? Which JDK 1.1.7 are you using? Are you using any JITs? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Swing on Linux
I've just started looking at using Swing for my Java project. It seems really really slow. Is anyone here seriously using Swing under Linux, without a JIT? Is there some way to improve things? Do JITs make enough difference to make it bearable? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Swing on Linux
>>I've just started looking at using Swing for my Java project. >Question: doesn't java 1.2 include the swing classes? If you're >"just start"-ing to look at swing, why not start with java 1.2 instead? Because I have 25,000 lines of code with scary classloader and RMI hacking that I haven't ported to Java 1.2 yet. The GUI is the smallest part of what I'm doing :-) Thanks to everyone's responses. I'd summarize by saying "Swing is slow, but usable, on Linux". Slow is of course relative.. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Swing on Linux
>How can I get the swing classes for jdk117v3 Go to http://java.sun.com/, find the Swing page, and download the release. All you really need out of it is swingall.jar, put it in your classpath and you're set. A bit more on the Swing front - I was confusing slowness on startup with general slowness. Are there any tricks to making the first Swing windows you create come up faster, so it at least feels faster? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM released an early jdk for linux
>It is only jdk1.1.6 though. But I will take it. Yeehaw! If you don't like hunting, it's at http://www.alphaworks.ibm.com/tech/linuxjvm Native threads, requires glibc 2.1 and kernel 2.2. Says Redhat 6.0 is good to go, and it seems to be. It requires Motif, but they have helpful instructions about how to install LessTif 0.88.1. I did a few quick tests against the Blackdown JDK 1.1.7_v3 (no JIT). The main story is that it works! I'm quite impressed. I did a bit of speed comparison, nothing comprehensive, I'd be interested in real benchmarks. A fancy animated graphics program I wrote does great under the IBM JDK, running smoothly at a framerate and size well beyond where it'll choke running under Blackdown. My big distributed application environment, Hive, seems to run fine with it. I can't actually compile it (JDK 1.1.6 rmic has a bug), but it'll run the classes just great. Hive makes use of lots of concurrently running threads, graphics, object allocation, and RMI. It runs well under the IBM JDK and seems quite responsive. My only complaints so far.. a bit of font damage in java.awt.Choice. And rmic, the compiler, seems to run slower under the IBM JDK. But maybe that's a different version of rmic itself, or maybe just JIT overhead for a funny case. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM released an early jdk for linux
>Is the 90 day evaluation license for real? I took this as a sign that this was only a prerelease alpha, that they will be having a more stable version soon. A bit frustrating, but I think it makes sense in this context. >On a serious note, how will the IBM JVM impact the Blackdown port? That's a good question. There's no reason not to have multiple ports. The Blackdown folks know a *lot* about how Linux works. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What's so platform dependent with Java2 source?
>Why has it been so difficult to port Sun's Java2 source to Linux? I have no specific knowledge - I'm not part of the Blackdown team, have never seen the JDK sources, etc. But I can guess :-) The port is a spare-time effort with non-open source. Java2 is a hell of a lot of code. No matter how good it is, when it's big it's hard to port. The Blackdown folks seem to be adding a lot of value back to the Java port. How many of their patches have gone back into the Java tree? Java hits threads very hard. In particular, the native threads port of Java stresses the glibc threading framework (and the kernel!) more than most systems. So you have to contend not just with portability problems, not just bugs in the Java sources, but bugs and misfeatures in the Linux implementation too. Memory management is tough to port. Remember how long the Linux JDK didn't free memory? AWT gives porters a hard time. I don't personally understand this, except Xlib is icky. I'd be interested to hear what the Blackdown folks can say on the subject. In particular, what about Linux makes it hard to port? Maybe some of us can help improve the Linux side.. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Platform dependence of Java2 source ...
>Alright. In order to gain a good understand of the issues that have >arisen during the port of Java2 on Linux, I have read over the past >messages regarding technical difficulties in the port. You mostly quoted back my own speculation. Please understand, it was only speculation - I have no knowledge of the JDK sources or the details of the porting effort. And please be careful when you ask questions like this - it's very easy to sound like you're criticizing the porters, implying that it shouldn't be this hard. I don't think you mean to do that, but please be sensitive to it. The Blackdown folks are doing a terrific job. Java2 has been painfully slow to be ported anywhere, Linux is further along that most Unixes. Anyway, my answer to your questions is "C code is not portable". Posix, standard C libraries, standard X libraries - those don't mean anything. If you've tried to write large portable C programs, you understand this. Java pushes things harder than most projects because it has a big graphics library, complicated memory management, and uses threads. (The Linux kernel, by contrast, is simpler - it defines its own execution environment!) If you want to know more, definitely take a look at those diffs on ftp.tux.org. That'll give you a good sense of the scope of the porting effort. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
a filesystem standard for the JDK
Has anyone worked up a filesystem standard for the JDK on linux? I've seen it installed all over the place on different Linux systems. Maybe we can come up with a standard place to put everything and make the world safe for RPMs and .debs everywhere. Is there a sensible Solaris standard? Anyone want to work on this with me? Requirements: executables in /usr/bin Tricky, JDK is picky about which directory things are run from. support multiple JDKs installed simultaneously At least JDK 1.1 and JDK 1.2, IBM vs Blackdown, ?? easy way to install new .jar and .class files Standard classpath has to be established easy way to install .so files for JNI extensions tya, shujit, rx/tx, etc. Has to interact with ld.so documentation has to be installed as well. Maybe requirements: peaceful coexistence with kaffe, japhar, classpath, etc. The way I do things now is I have /usr/local/java /usr/local/java/jdk1.1.17_v3/ /usr/local/java/jdk1.2pre-v2/ /usr/local/java/ibm-jdk/ /usr/local/java/classes (in my CLASSPATH) /usr/local/java/jdk, a symlink to whichever JDK I want today /usr/local/java/jdk/bin/ in my PATH It works OK except the symlink is a kludge and I have no good way to install .so files. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
odd AWT focus bug in JDK 1.1 and JDK 1.2 (with test case)
/** Demonstration of a bug in focus with the AWT on Linux and Java.
**
** Creates a Frame with a Choice and a TextArea. Every other time the
** Choice box is selected, the text area loses the ability to take
** focus. To demonstrate this, type some text into the text area,
** then select something from the Choice. Type into the text area
** again, then select something from the Choice again. The text area
** is now locked, and cannot be typed into.
**
** Removing focus and restoring it to the Java app allows the text
** area to be used again, but it re-locks every second time the
** Choice is selected.
**
** Bug verified with WindowMaker and fvwm2,
** Blackdown JDK 1.1.7_v3 and 1.2_pre2
**
** Nelson Minar <[EMAIL PROTECTED]> and Tucker Sylvestro <[EMAIL PROTECTED]>
** Mon Jul 19 18:51:14 EDT 1999
**/
import java.awt.*;
public class FocusBug extends Frame {
Choice c = null;
TextArea t = null;
public FocusBug() {
c = new Choice();
c.addItem("Item 1");
c.addItem("Item 2");
add(c);
t = new TextArea();
t.setEditable(true);
add(t);
pack();
setVisible(true);
}
public static void main(String args[]) {
Test f = new Test();
f.setLayout(new FlowLayout());
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netscape 4.61 bus error
>I just upgraded to RedHat 6.0 and Netscape 4.61 and when I invoke a Java >applet, Netscape exits with a 'bus error' when trying to start Java. I don't have that happen, but pretty much any Java applet I run works for about 5 seconds before the entire netscape process wedges, consuming 100% CPU and having to be kill -9ed. I've just assumed that once again Netscape on Linux has bad Java support. In particular, I'm guessing glibc2.1 kills it. Is there some workaround for this? Anyone have better results? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
netscape 4.61, Java, Redhat 6.0
>I've not had that many problems with Netscape and Java. Could it really just be me? I'm running pretty basic Netscape, about the only change I made was running Fortify over the browser. Trivial applets like http://nelson.www.media.mit.edu/people/nelson/research/mas964/ps2/CircleRepetition.html are killing it. Try it yourself - run the applet, click and hold in the window and drag around awhile. (Enjoy the pretty circles). For me, after about 15 seconds of this, Netscape locks up solid. With the Redhat RPMs, it consumes 100% CPU and can't be killed except with signal 9. The Mandrake RPMs at ftp://ftp.wtfo.com/pub/linux/mandrake/6.0/Mandrake/RPMS/ are a bit better - it still locks up, but doesn't consume CPU and can be killed with the normal signal. The netscape wrapper script in the RedHat RPMs is quite complex, but doesn't seem to be doing anything with LD_LIBRARY_PATH or the Java environment. The one with Mandrake is much simpler, also doesn't set anything that seems related. It all feels to me like some bad instability between AWT and glibc2.1. (The applet I've pointed you to is quite simple Java1.0 stuff. No threads are spawned. It does a fair amount of work inside mouseDrag(), but that's all. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netscape 4.61, Java, Redhat 6.0
So basically, Netscape 4.61 is whacked for Java. On Redhat 6.0, Redhat
5.2, and Debian potato. Yay!
What's frustrating is this stuff used to work. I was using Netscape
4.5 for the longest time with Java with no problems. So maybe it's a
recent Netscape bug, rather than a Linux version problem.
Is anyone running a Netscape that does work well for Java on Redhat 6.0?
Here's the source code for my simple applet that's killing Netscape.
It's just one example, I haven't found any Java to run reliably in
Netscape recently. My apologies for the ugly code, it's some of the
first Java I wrote. The paint/repaint interactions are a bit bizarre
in DoubleBufferApplet, maybe that's the source of the problem.
// mas964 ps2
// draw circles on mouse click that demonstrate repetition
import java.applet.*;
import java.awt.*;
import java.lang.Math;
import DoubleBufferApplet;
public class CircleRepetition extends DoubleBufferApplet {
public boolean mouseDrag(Event e, int x, int y) {
return mouseDown(e, x, y);
}
public boolean mouseDown(Event e, int x, int y) {
Graphics g = imageBuffer.getGraphics();
this.clearImageBuffer();
g.setColor(this.getForeground());
int maxNumCircles = 30;
int circleSizeGradations = 10;
int numCircles;
int circleSize;
float cellSize;
// y coordinate controls the number of circles drawn
numCircles = maxNumCircles * y / imageBufferSize.height + 2;
if (imageBufferSize.width > imageBufferSize.height)
cellSize = imageBufferSize.width / numCircles;
else
cellSize = imageBufferSize.height / numCircles;
// x coordinate controls how big the circles are
circleSize = (int)(cellSize * x / imageBufferSize.width) + 1;
if (circleSize < 2)
circleSize = 2;
// System.out.println("numCircles " + numCircles + " circleSize " + circleSize);
// now draw circles in a hexagonal pattern (some slop on both sides
// to handle roundoff error)
int i, j;
for (i = -1; i < numCircles+4; i++) {
for (j = -1; j < numCircles+4; j++) {
if (i % 2 == 0)
g.fillOval(Math.round(i * cellSize), Math.round(j * cellSize),
circleSize, circleSize);
else
g.fillOval(Math.round(i * cellSize),
Math.round(j * cellSize + cellSize/2),
circleSize, circleSize);
}
}
repaint();
return true;
}
public void init() {
this.setBackground(Color.white);
this.setForeground(Color.black);
super.init();
}
}
// base class for double buffered applets. Drawing is done to imageBuffer,
// an offscreen buffer that's BLTed to the frame as need be. This gives
// you less flashies and some measure of image persistence across exposes.
// (it'd be nice if we could do this for arbitrary components, but that
// would require changing the root Component class)
// Draw model:
// When drawing, don't use this.getGraphics() or paint()'s argument-
// use imageBuffer.getGraphics()
// override paint() as expected to paint, but make sure to
// call super.paint() to actually render your changes
// call this.repaint() to actually cause the drawing to show up
// (or wait for something else to call this.update())
// use this.setBackground() as you would normally
// call clearImageBuffer() to reset the entire drawing to background color
import java.applet.*;
import java.awt.*;
public class DoubleBufferApplet extends Applet {
protected Image imageBuffer;
protected Dimension imageBufferSize;
// paint - just call update. Subclass can override this, be sure to call
// super.paint() as the last step.
public void paint(Graphics g) {
this.update(g);
}
// clear the image buffer to whatever the background colour is.
public void clearImageBuffer() {
Graphics ig = imageBuffer.getGraphics();
Color oldColor = ig.getColor();
ig.setColor(this.getBackground());// clear the buffer
ig.fillRect(0, 0, imageBufferSize.width, imageBufferSize.height);
ig.setColor(oldColor);
}
// update - render the buffer onto the screen
// also handles lazy creation of the offscreen buffer
public void update (Graphics g) {
Dimension appletSize = this.size(); // read the current size
// check that the buffer is valid - if not, build one
if (imageBuffer == null ||
appletSize.width != imageBufferSize.width ||
appletSize.height != imageBufferSize.height) {
// System.out.println("Building a buffer of size " + appletSize);
imageBuffer = createImage(appletSize.width, appletSize.height);
imageBufferSize = appletSize;
this.clearImageBuffer();
}
g.drawImage(imageBuffer, 0, 0, this);
}
}
Title: Repetition Circles
Repetition Circles
You control the vertical
You control the horizontal
Re: netscape 4.61, Java, Redhat 6.0
>Well, I'm running Netscape 4.61 on the Mandrake 6.0 release, and just can't >seem to get Netscape to crash at all! Thanks for the info, Todd. Anyone know how different Mandrake's libraries from Redhat? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netscape 4.61, Java, Redhat 6.0
OK, we're getting somewhere - the libc5 and glibc versions behave differently. Hooray. I tried downloading libc5 Netscape direct from Netscape, or the mirror at ftp://ftp.the.net/pub/mirrors/ftp.netscape.com/pub/communicator/english/4.61/unix/supported/linux20_libc5/ I then fortified it and ran it on my Redhat 6.0 system with my little circle applet. It still crashes/hangs after dragging along a lot, although with the libc5 system it doesn't chew 100% cpu and responds to normal kill signals. glibc chewed 100% CPU and required signal 9 to kill. The Mandrake RPM version runs more or less like the libc5 version does for me for Java. The Mandrake version also seems to have a bug where you can't press escape to stop loading a page, which is awfully annoying. So I'm still without a reliable Netscape for Java, but at least the crashes aren't as bad. I think the real solution is for Netscape to statically link a build of Netscape 4.61. Yeah, it's ugly, but maybe it'd at least work. Maybe the X libraries could be dynamically linked on the hope it's the C or C++ libraries that are the problem. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working with many .java files
>>As soon as my application grow and more classes are created, I'm >>beginning to feel the weight of a full scale compilation (like 20 >>seconds now, but it's increasing fast) even after I change 1 line of >>code in 1 class. >We use make to great advantage. Our system has ~1000 java files and >make reduces compile time dramatically. ( We use jikes, too, so that >helps. ) I've found that with Jikes, it's best just to recompile everything. I have a Java system that's currently 280 .files, 36000 lines of code. It also links to 5 or 6 extra jar files. Using jikes, it takes less than 5 seconds to compile all 280 files at once. It takes about the same amount of time to use jikes to compile one file. It's faster to compile everything at once than to recompile two files separately. I guess the optimal thing would be to tell Jikes to only compile the files that had changes. But given the complexity of doing that with make, not to mention finding/maintaining Java dependencies, it's just better to recompile all files each time. Make sure your .java and .class files are not going through NFS. We keep everything on local disk and use CVS for backups to reliable storage. I do use make for the files I run rmic on. There the dependencies are easy, and rmic is very slow. Someone should write a perl replacement. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working with many .java files
>Granted I don't know much about Jikes but 280 files in 5 seconds >amI missing someething? Jikes is really, really fast. Being on all local disk (NFS) makes a huge difference. And I'm on fast machines - a 500 MHz Pentium III now, I think. >Are you sure that jikes isn't just skipping over files that don't >need to be recompiled? I pass all the .java filenames on the commandline. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working with many .java files
>Actually, I'm pretty sure Jikes has built in automatic dependency >checking. It might, but I wouldn't trust it. And in my code, static dependency checking doesn't work - I'm routinely loading things dynamically. >Try comparing the compile time for a "make clean" to a "make" (after >changing a few non-critical source files) It's the same. I'm serious. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] jikes [was headed OT: Re: Working with many .java files]
>Are you suggesting that I could do something like this: > find . -name \*.java -print | xargs jikes ++ The principle works fine for me, although you'll eventually hit a command line argument length! The nice thing is you can probably make a generic Java makefile that works with any code. You can do the equivalent of most of the find in GNU make. I do this: # A variable of all the directories I use. (Would be nice to do find) JavaAutoDirs = . agents server agents/graphics # First, the magic to make targets out of everything in JavaAutoDirs. # Turn each directory in AutoMakeDirs into the pattern dirname/*.java JavaAutoPatterns := $(foreach dir,$(JavaAutoDirs),$(dir)/*.java) # Now glob out the pattern, so we get all the actual filenames. JavaAutoSources := $(wildcard $(JavaAutoPatterns)) # Substitute .class for .java for the targets. JavaAllAutoTargets := $(patsubst %.java,%.class,$(JavaAutoSources)) # And strip out any special cases JavaAutoTargets := $(filter-out $(ExcludeClassFiles),$(JavaAllAutoTargets)) # Now, the actual list of targets that the rules will make. # Construct the names of all the .class and .java files we need to make AllClassFiles := $(JavaAutoTargets) $(OtherClassFiles) AllJavaFiles := $(patsubst %.class,%.java,$(AllClassFiles)) # Finally, a monitor file we use for dependency to compile all files at once BuiltMonitorFile := $(DESTDIR)/.built # To compile all files at once, test a monitor vs. the java files $(BuiltMonitorFile): $(AllJavaFiles) $(JAVAC) $(JFLAGS) $(AllJavaFiles) && touch $(BuiltMonitorFile) [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
