RE: compiler for C source to Java bytecode

2000-11-24 Thread Suru Dissanayake

Hi Pramila,

This is a great page with links to all these tools.

http://www.meurrens.org/ip-Links/java/codeEngineering/

Kind regards,
Suru


-Original Message-
From: Pramila [mailto:[EMAIL PROTECTED]]
Sent: den 24 november 2000 05:09
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: compiler for C source to Java bytecode


Hi!,

   Could u please let me know where I can find

  - Converters: from Java source to C source   &
 -  Decompilers: from Java bytecodes to C source .

   Thanks in advance.

--Regards
Pramila


Suru Dissanayake wrote:

> Hi!
>
> I have found a couple of:
> Decompilers: from Java bytecodes to C source
> Converters: from Java source to C source
> Decompilers (to Java): from Java bytecodes to Java source
>
> But does anyone know anything about a compiler for C source to Java
> bytecode?
> (Preferably for Linux)
>
> I would like to create a java class file from a c-application and load it
> dynamically to a java program. Has anyone done this?
>
> Any information on the subject is gladly accepted!
>
> kind regards,
> Suru
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: compiler for C source to Java bytecode

2000-11-24 Thread Pramila

Hi Suru,

   Thanks a lot!

Regards
Pramila

Suru Dissanayake wrote:

> Hi Pramila,
>
> This is a great page with links to all these tools.
>
> http://www.meurrens.org/ip-Links/java/codeEngineering/
>
> Kind regards,
> Suru
>
> -Original Message-
> From: Pramila [mailto:[EMAIL PROTECTED]]
> Sent: den 24 november 2000 05:09
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: compiler for C source to Java bytecode
>
> Hi!,
>
>Could u please let me know where I can find
>
>   - Converters: from Java source to C source   &
>  -  Decompilers: from Java bytecodes to C source .
>
>Thanks in advance.
>
> --Regards
> Pramila
>
> Suru Dissanayake wrote:
>
> > Hi!
> >
> > I have found a couple of:
> > Decompilers: from Java bytecodes to C source
> > Converters: from Java source to C source
> > Decompilers (to Java): from Java bytecodes to Java source
> >
> > But does anyone know anything about a compiler for C source to Java
> > bytecode?
> > (Preferably for Linux)
> >
> > I would like to create a java class file from a c-application and load it
> > dynamically to a java program. Has anyone done this?
> >
> > Any information on the subject is gladly accepted!
> >
> > kind regards,
> > Suru
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Socket.set{Send,Receive}BufferSize do not properly delegate to underlying OS

2000-11-24 Thread Wolfgang Hoschek

java.net.Socket.setSendBufferSize() and
java.net.Socket.sendReceiveBufferSize() misbehave partially or
completely on Linux and Solaris, both in JDK 1.2.2 and 1.3.0.
They work as expected on Windows. And they work in C based tcp test
programs like `iperf`.

If the underlying operating system is configured to allow large buffer
sizes, these calls should use them just as C setsockopt() does.
It is known that there are no guarantees as to which buffer size the OS
will actually use. This is fine.
The data below seems to imply that the JDK is itself assigning funny
(and too small) buffer sizes, whereas this really is the job of the OS.
The JDK used to call setsockopt() through JNI, which is precisely the
expected behaviour. Something funny is happening in more recent
releases.

Please find attached a tiny program that reproduces the behaviour.
It tries to set socket buffer size to 256K, but only gets much less.
OS level TCP tuning parameters are set appropriately on all used
machines (and can be dumped with the attached script).
Please consider that not being able to properly tune buffer sizes means
that high performance data intensive applications running over Gigabit
Ethernet LAN, and/or high bandwidth * delay WAN path can easily be one
order of magnitude slower than under ideal settings (as can be verified
with `iperf`).
See http://www-didc.lbl.gov/tcp-wan.html for more material explaining
why these things matter.

This may perhaps be related to bug#4292944, but the "evaluation" given
to #4292944 does not apply here.

##
iperf verifies that we can actually use large buffer sizes on linux and
solaris (256K and 512K)
##

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug] iperf -s -p 8000 -w
256K -m

Server listening on TCP port 8000
TCP window size:  256 KByte

[  4] local 137.138.137.126 port 8000 connected with 137.138.181.215
port 1138
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-10.0 sec   472 MBytes   378 Mbits/sec
[  4] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
[  4] Read lengths occurring in more than 5% of reads:
[  4]  2896 bytes read  4066 times (5.57%)
[  4]  6744 bytes read  3784 times (5.18%)
[  4]  8192 bytes read 48088 times (65.9%)

[inssrv1 /afs/cern.ch/user/h/hoschek/tmp/socketbug] iperf -c monarc01 -p
8000 -w 256K -f K

Client connecting to monarc01, TCP port 8000
TCP window size:  512 KByte (WARNING: requested  256 KByte)

[  3] local 137.138.181.215 port 1138 connected with 137.138.137.126
port 8000
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  483536 KBytes  48344 KBytes/sec



#
SOLARIS 2.6 and 2.7: FAILED
#

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug] uname -a
SunOS monarc01 5.6 Generic_105181-12 sun4u sparc SUNW,Ultra-4

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug] dumpparams.sh
tcp_max_buf=1048576
tcp_xmit_hiwat=8192
tcp_recv_hiwat=8192
tcp_cwnd_max=262144

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug]
/afs/cern.ch/sw/java/sparc_solaris26/jdk/sun-1.2.2/bin/java -version
java version "1.2.2"
Solaris VM (build Solaris_JDK_1.2.2_06, native threads, sunwjit)

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug]
/afs/cern.ch/sw/java/sparc_solaris26/jdk/sun-1.2.2/bin/java
SocketBufferBug 
before: sendBufSize=8192
before: recvBufSize=32768
after : sendBufSize=262144
after : recvBufSize=57344



[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug]
/afs/cern.ch/sw/java/sparc_solaris26/jdk/sun-1.3.0/bin/java -version
java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

[monarc01 /afs/cern.ch/user/h/hoschek/tmp/socketbug]
/afs/cern.ch/sw/java/sparc_solaris26/jdk/sun-1.3.0/bin/java
SocketBufferBug 
before: sendBufSize=8192
before: recvBufSize=32768
after : sendBufSize=65536
after : recvBufSize=57344



#
LINUX REDHAT6.1
#

[inssrv1 /afs/cern.ch/user/h/hoschek/tmp/socketbug] uname -a
Linux inssrv1 2.2.17-7.4.0smp #1 SMP Thu Nov 16 10:17:16 CET 2000 i686
unknown

[inssrv1 /afs/cern.ch/user/h/hoschek/tmp/socketbug] dumpparams.sh
wmem_max=514288
rmem_max=514288
wmem_default=65535
rmem_default=65535


[inssrv1 /afs/cern.ch/user/h/hoschek/tmp/socketbug]
/afs/cern.ch/sw/java/i386_redhat61/jdk/blackdown-1.2.2/bin/java -version
java version "1.2.2"
Classic VM (build Linux_JDK_1.2.2_FCS, native threads, sunwjit)
[inssrv1 /afs/cern.ch/user/h/hoschek/tmp/so

Accessing virtual consoles from Java?

2000-11-24 Thread Barnet Wagman

Is it possible to access virtual (text-mode) consoles from Java?  I'm
writing a app that I'd like to run without X.  It would be best if it
could have access to more than one console, but I'm don't know how to do
i/o to consoles except via java.lang.System streams.

Thanks,

Barnet Wagman


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]