Re: January 2000 java-linux FAQ
Thanks for the FAQ. It's great. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
On 11 Jan 00, at 11:35, Aaron Stromas wrote: > > > > may someone have a hint as to what my problem may be and how to fix it. > > > > here is what is happening. i have a an rmi application with linux > > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > > UnmarshalException. i could not figure out why it wa happening, so i [snip] > > > Don't the two vm's have to be the same, as the serial numbers will be > > > different between 1.2 and 1.3, which will cause Serialization errors? [snip] > that does not appear to be so, at least, not on solaris - i installed > jdk1.2.1_04 and the client ran ok. We had a very similar problem concerning AllPermission objects being sent via RMI (and dont ask me why we are doing this !!!) from a Linux server running 1.2rc2 and a Windows client running 1.3beta. As a result, an Unmarshalled Exception was thrown. The reason seemed to be that SUN changed the way the AllPermission object was generated from 1.2 to 1.3 by using an AllPermissionCollection object. So the client got an object of type AllPermission and tried to retrieve an AllPermissionCollection object from the 1.2 server, which could not work. SUN changed a few things in 1.3 and I would not be surprised if more of those things arised. Oliver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with exec()
[EMAIL PROTECTED] wrote:
>
> > Dimitris Terzis wrote:
> >
> > Hi guys...
> >
> > I am trying to launch an external application from my Java program,
> > using exec().
> >
> > I do Runtime.getCurrentRuntime() and then try to exec() the
> > application (not internal command), providing a properly created path.
> > My application has a GUI which is never displayed. However, if I type
> > "ps -aux" I can see that the process is there, which is reasonable
> > since, in all cases, the Process object returned from
> > Runtime.getCurrentRuntime().exec(...) is valid and no IOException (or
> > whatever other error) occurs.
> >
> > I am running JDK 1.2.2-RC2 from Sun, on a RedHat 6.1 box.
>
> There's nothing obviously wrong with the system. I'm running the same
> JDK under RH6.1 and this trivial example works:
>
> > public class Temp
> > {
> > public static void main(String[] argv)
> > throws java.io.IOException
> > {
> > Runtime.getRuntime().exec("xclock");
> > }
> > }
If you are using wildcards then you need to invoke the shell
and get it run the command on your behalf
> > public class Temp
> > {
> > public static void main(String[] argv)
> > throws java.io.IOException
> > {
String command = "ls *.java";
String cli[] = { "/bin/sh", "-c", command };
> > Runtime.getRuntime().exec( cli );
> > }
> > }
--
Adios
Peter
-
import std.Disclaimer; // More Java for your Lava, Mate.
T H ER E D A R M Y! ! ! http://www.manutd.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which Linux JVM is better?
After a little more server-side testing I've discovered the following to be true: -- (RedHat Linux 6.1, with kernel modified to up the number of file descriptors and per-user thread limits, 300MHz machine, 256MB RAM) -- Inprise JVM 1.2.2 for Linux vs. Blackdown JVM 1.2.2 RC3 -- green threads vs. native Preface: Tests involved hitting our Java server application, which utilizes JDBC to talk to a MySQL database on a separate box, with as many simultaneous tcp/ip connection requests as possible using Segue's Silk Performer load testing tool. In sum: * The Inprise Java-Linux port could not handle nearly as many simultaneous server-side connections as the Blackdown port when using green threads. * Using native threads, however, the Inprise port wins hands down. This, of course, is to be expected as the Blackdown porters have not finished testing and fixing their native threads port yet. Using Inprise's native threads, our application was able to handle many more simultaneous connections than we could with the Blackdown green threads port. It would seem that if we linux/java users could somehow combine the efforts of both camps (Sun/Inprise and Blackdown), we would have a pretty well-rounded JVM right now, since the Inprise port is doing really well with native threads, and the Blackdown guys have done a good job with green threads. One question I have of Blackdown is why they have prioritized their green threads porting efforts over native threads, when native threads offer the best overall server-side performance (if I'm not mistaken in my assumptions)? I think more and more people are using Java for server-side development, as opposed to client-side, especially on Linux - again, if I'm not mistaken. Thanks, James P.S. These ideas, informations and opinions are my own and do not necessarily express the ideas and opinions of my employer. Mike Christiansen wrote: James Caple wrote: > > For what it's worth, my experience has been that the Blackdown RC3 port is > much more scaleable and stable than the Inprise Linux port. I'd place my > bets on the Blackdown port for server-side performance and scaleability. > Although somewhat slow in porting, Blackdown is doing a very thorough job. As much as I hate to say it, my money is on Imprise. I am finding that Blackdown's VM is causing JRun to hang. This may be a problem with native threads, or with the fact that I am running on a two processor SMP configuration. However, switching to Inmprise / green threads did the trick. Mike > > My comments are based on tests using green threads without a JIT, at the > moment. > > JC
WANTED: Audio Resampling Algorithm in Java instead of C
I am looking to convert the sample rate of audio clip files in Java. There are lots of resource out there on the Net, but in C/C++ not necessarily in Java. Has anyone converted the `C' resampling algorithm that is used in ``sox'' to Java? "README file for resample-1.5.tar.gz from the Digital Audio Resampling Home Page located at http://www-ccrma.stanford.edu/~jos/resample/" -- Adios Peter - import std.Disclaimer; // More Java for your Lava, Mate. T H ER E D A R M Y! ! ! http://www.manutd.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which Linux JVM is better?
> James Caple writes: James> In sum: James> * The Inprise Java-Linux port could not handle nearly as James> many simultaneous server-side connections as the James> Blackdown port when using green threads. And our next release will use poll() instead of select() which will remove another limitation in the green threads VM. James> * Using native threads, however, the Inprise port wins James> hands down. This, of course, is to be expected as the James> Blackdown porters have not finished testing and fixing James> their native threads port yet. Using Inprise's native AFAIK their native threads is more or less a snapshot of our native threads code. The next release will the fix the remaining problems we know of: interrupted() problem, interruption of the primordial thread, EBADF messages. James> threads, our application was able to handle many more James> simultaneous connections than we could with the Blackdown James> green threads port. [...] James> One question I have of Blackdown is why they have James> prioritized their green threads porting efforts over native James> threads, when native threads offer the best overall James> server-side performance (if I'm not mistaken in my James> assumptions)? We haven't! The native threads VM is used by default in our JDK. Sun/Inprise uses green threads VM as default and does not yet support the native threads VM. >> As much as I hate to say it, my money is on Imprise. I am finding that >> Blackdown's VM is causing JRun to hang. This may be a problem with >> native threads, or with the fact that I am running on a two processor >> SMP configuration. However, switching to Inmprise / green threads did >> the trick. One problem is that there are still several race conditions in the LinuxThreads implementation. It looks like glibc-2.1.3 will solve a lot of them. Juergen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java-Linux I18N
Couple of hints on this.
So far, I haven't seen anything in Java I18N that's specific to Linux,
except:
1. Yes, you need Asian fonts. Some come with the distros, I got
additional ones from
http://www.userfriendly.net/linux/RPM/rhcn/noarch/X11_fonts.html
(Japanese, Simplified Chinese, Traditional Chinese, Korean) - these are
all RPMs
2. You do need to change you font.properties file in order to display
Asian in a Java program. But once you have that, you can display it,
even if your machine uses the Western European codepage (i.e.is set up
to behave as a Western European/US machine) - EXCEPT, as of pre-Swing,
TextField and TextArea will NOT display Asian, because these components
use native code (or for whatever reason). From what I understand Swing
components do not have that limitation. Now, there's a great site for
Japanese Linux at
http://hikari.tlug.gr.jp/~craigoda/writings/linux-nihongo/linux-nihongo.html,
including references to Java, and most importantly a font.properties
file for Linux. I simply downloaded that file, dropped it into my
../jre/lib directory of Java installation and into
/usr/lib/netscape/java/classes for my netscape browser. BUT, if you
backup your existing font.properties file (as you would want to) to
java.properties.en (as it would logically be named), your JVM (of the
JRE or Netscape's) seems to still look up the fonts described in that
backed up file, if your machine's default Locale is English. So I backed
mine up to font.properties.ENGLISH (which the JVM apparently cannot map
to my machines Locale), and then it works beautifully - EXCEPT that some
Western European fonts are now not quite so pretty. Of course, you can
and probably should edit that font.properties file, but the one
downloaded from
http://hikari.tlug.gr.jp/~craigoda/writings/linux-nihongo/linux-nihongo.html
is a great starting point.
3. I am fairly certain that there is a way to switch the locale and
charset/codepage of your machine (hence the /etc/charset directory, I'd
think), but I haven't figured it out yet (although I will have to for a
project sometime soon).
4. From what I can tell, the rest is Java I18N as usual. See the I18N
Tutorial at http://java.sun.com/docs/books/tutorial/i18n/TOC.html. There
was also a three-part tutorial at http://www.javaworld.com at somepoint.
Take the first first example of that tutorial and add Japanese to the
choices ("ja", "JP") to allow you to test whether you have correctly
installed the font.properties file. If you did, you'll see Japanese
characters when you select Japanese in this applet (in appletviewer or
in the browser).
Hope this helps.
Renzo
> > [Lee]
> > I'm new in this area too (and new in Java-Linux as well). The issue of
> I18N
> > I have is very basic at this time. That is what we need and need to do to
> > display Japanese and Chinese characters on a JButton on Linux.
> >
> > Q1: Do we need a Japanese/Chinese font packages?
> > Q2: If so, where to find the right font package for Linux?
> > Q3: After find the font package, how to use it to show a Japanese/Chinese
> > character on a JButton?
> > Q4: Is there any Japanese/Chinese version of Linux like Windows NT does?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which Linux JVM is better?
On Fri, Jan 14, 2000 at 06:34:41PM +0100, Juergen Kreileder wrote: > James> One question I have of Blackdown is why they have > James> prioritized their green threads porting efforts over native > James> threads, when native threads offer the best overall > James> server-side performance (if I'm not mistaken in my > James> assumptions)? > > We haven't! > The native threads VM is used by default in our JDK. Sun/Inprise uses > green threads VM as default and does not yet support the native > threads VM. The Blackdown team has put many cycles into getting native threads to work properly. Inprise ships native-threading libraries but doesn't advise their use - they're not robust and fully compliant in that JVM. Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ibm jdk118 > g++ -O
I was considering whether we needed to write some image resampling
inner loops in C++, and wrote a little bilinear interpolation
"mock up" resampling routine.
On a Celeron machine the ibm jdk is actually a hair faster than
the C++ version compiled with -O. Note that the C++ is not
compiled with any more exotic flags, and quite probably
is not making use of PII instructions, but nevertheless this
is a pretty satisfying result. I find it a bit hard to reconcile
with my subjective experience of swing interfaces.
The benchmark ("RESAMPLE") java and C++ source codes are at
www.idiom.com/~zilla/Computer/javaCbenchmark.html.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc
Ok... I found out from this list that jdk1.2.2 needs glibc-2.1.* So I installed glibc-2.1.1 but when I do java it instead tries to load /lib/libc.so.5 instead of /lib/libc.so.6 which is linked to glibc-2.1.* Any way to make this work? :) Thanks -Pedro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
