Re: javac can not find com.sun.java.swing.JApplet class

[Troy Wu]

How about checking the JDK-1.2 docs...?  The package name is:

javax.swing.*

not

com.sun.java.swing.*

On Wed, 31 Mar 1999, Richard James wrote:
  
  public class RootApplet extends com.sun.java.swing.JApplet {


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

Re: go back to gzip!

[Peter Kovacs]

jdk1.2pre-v1.tar.bz2   24457274
jdk1.2pre-v1.tar.gz26062044

Means a 6.1% better compression rate. Is it really that much improvement? If it was at 
least 15%...

Peter

John Goerzen wrote:

> "David Wall" <[EMAIL PROTECTED]> writes:
>
> > It was a bit rude as written, and that's part of the problem with email in
> > general.  Sometimes terse statements sound worse than the intended message
> > was to be delivered.
>
> You said "nobody uses bzip2", which is CLEARLY incorrect.
>
> > While I am really happy with the work that this free software team has been
> > doing, and I appreciate and make good use of their labor, the original post
> > did have a good point: why introduce a new zip scheme that would not be
> > available to most people?  gzip is open source and widely deployed.  Was
> > there a particularly strong reason for using bzip2 over gzip?
>
> First, this is not "new".  bzip2 has been around for some time.
> Secondly, the source is available and it runs on a wide variety of
> platforms.  How is there a problem here?  This is exactly how gzip is
> distributed.  While it's true that bzip2 is not GPL, it does meet the
> DFSG.
>
> Your question about why to use it demonstrates that you do not know
> how it works, or what it does.  Yet you criticise the use of it.
> Perhaps why you realize how much better compression it gets than gzip,
> and check out its homepage at http://www.muraroa.demon.co.uk/, you'll
> see that any computer that's going to be running the JDK will probably
> be of sufficient speed to benefit from bzip2.
>
> --
> 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]

libc5 JDK 1.2

[Slava Pestov]

Hello everybody,

I searched the archives and couldn't find an answer to this one...

Will there ever be a _libc5_ JDK 1.2 for linux? I ask this because my
primary development platform is a Linux box with libc5 (and upgrading
it to libc6 would be a real nightmare, it's a hacked up Slackware 3.4)

Slava
-- 
[ Home page:  ]


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

Re: go back to gzip!

[Robb Shecter]

Peter Kovacs wrote:

> jdk1.2pre-v1.tar.bz2   24457274
> jdk1.2pre-v1.tar.gz26062044
>
> Means a 6.1% better compression rate. Is it really that much improvement? If it was 
>at least 15%...
>

Well,  that looks like 1.6 MB per download.  So, multiplied by the 500,000 downloads 
it'll get  :),
that's a lot of traffic that can be saved, esp. for a non-commercial provider.

If bzip2 is "better", then we should use it for -everything-.  It doesn't matter if it 
hurts a bit in
the short run.  As long as there's a new version coming of (say) tar that knows about 
it, and it makes
sense, then it should be done.

This, to me, is a BIG strength of the Linux world.  Choices are made because of 
quality, and we go
through sometimes painful changes because it's better in the long run.  (I'm thinking 
of elf format, c
library changes, etc.)  In Dos/Windows, this rarely happens: they're tied to an old 
customer base that
uses crap, and so new versions must also be crappy.

- Robb

PS: I put better in quotes, because I'm not so sure we can make a flat judgement like 
that: bzip has a
higher compression rate, but it seems much slower than gzip.  So, it may not be 
appropriate for all
uses.


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

EventQueueListener not found on JDK1.2

[Jesus Correas Fernandez]

I am working with JDK 1.2 for Solaris, and i want to work with the linux
version. I use the java.awt.event.EventQueueListener class, but i cannot
find it in the linux jdk. Is this a bug?

Thanks in advance.

Jesus


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

Re: go back to gzip!

[Thomas Koehler]

On Thu, Apr 01, 1999 at 12:19:44PM +0200, Robb Shecter wrote:
> 
> Peter Kovacs wrote:
> 
> > jdk1.2pre-v1.tar.bz2   24457274
> > jdk1.2pre-v1.tar.gz26062044
> >
> > Means a 6.1% better compression rate. Is it really that much improvement? If it 
>was at least 15%...
> >
> 
> Well,  that looks like 1.6 MB per download.  So, multiplied by the 500,000 downloads 
>it'll get  :),
> that's a lot of traffic that can be saved, esp. for a non-commercial provider.
> 
> If bzip2 is "better", then we should use it for -everything-.  It doesn't matter if 
>it hurts a bit in
> the short run.  As long as there's a new version coming of (say) tar that knows 
>about it, and it makes
> sense, then it should be done.

Try "tar Ixf filename.tar.bz2" (your tar should be a recet version)
[(GNU tar) 1.12 does the job here.]

HTH,
Thomas

-- 
Thomas KöhlerEmail: [EMAIL PROTECTED]
<><   WWW:http://home.pages.de/~jeanluc/
  IRC:   jeanluc
  LCARS --- Linux for Computers on All Real Starships


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

Why is System.arraycopy() slower than dest[j]=source[j] ?

[Wolfgang HOSCHEK]

Please apologize for this lengthy elaboration.

I ran some array copy benchmarks on NT with JDK1.2 and Visual Age
(VAJ2.0).
The results are surprising and indicate major inefficiencies in the
implementation of System.arraycopy(), both in VAJ and the NT JDK.

Other measurements on Solaris seem to tell that the Solaris JDK (1.2?)
uses a better implementation of System.arraycopy().
Has anyone figures from Linux or other environments?

The benchmarks copied all elements from one large array into another
large array (array.length=10^6).
Like this:

byte[] source = new byte[size];
byte[] dest = new byte[size];

//variant A: System.arraycopy()
System.arraycopy(source,0,dest,0,size);

//variant B: dest[i]=source[i]
for (int j=size; --j >= 0; ) dest[j] = source[j];


The measurements show that both VAJ and JDK delegate to pretty much the
same (bad) C implementation of System.arraycopy().
For variant B the JDK1.2 JIT produces code that is *not quicker* than
System.arraycopy()! (Except for byte units).
This is the case even though every single array index access in Java
checks if bounds are legal, while System.arraycopy() needs to perform
bounds checks only once before entering the copy loop. In fast, one
would assume that System.arraycopy() is lightning fast.

Here are the results:

Config: Pentium Pro 200MHz, NT. Compilation without -o flag or any other
optimizer.
All mem is allocated upfront with
java -verbosegc -Xms50m -Xmx50m ch.cern.colt.test.ArrayCopyBenchmark 10
100
No gc taking place. No swapping either. Plenty of RAM free. No other
work load biasing results.

Benchmark results given in MB/sec.

VAJ 2.0  | byte int long

arraycopy()  | 44   38  39
a[j]=b[j]|  3   13  16

JDK 1.2  | byte int long

arraycopy()  | 43   39  38
a[j]=b[j]| 15   40  40


Enclosed please find the benchmark code.

Mathias Waack wrote:
> I can't reproduce your results. Running the bench on my Solaris Ultra Box
> (333MHz), I've got:
> 
> byte int long
> array136 142  136
> = 43  74   78
> 


Does anybody know what is slowing System.arraycopy() on NT so much down?
Has anyone figures from Linux or other environments?

Wolfgang.
-- 
--
Wolfgang Hoschek | e-mail: [EMAIL PROTECTED]
CERN IT Division | phone:  +41 (22) 767 8089
European Laboratory  | fax:+41 (22) 767 7155 
for Particle Physics | home:   http://www.cern.ch/CERN/Divisions/EP/HL
--
 ArrayCopyBenchmark.java
 Timer.java

Re: go back to gzip!n

[John Summerfield]

On Wed, 31 Mar 1999, Volker Augustin wrote:

> Ok, there has been a long discussion about using bzip2 or not. Apart from
> personal problems using bzip2 (I have only access to a Win95 machine and

You oughta upgrade it. We do have a win95 machine here: it's the least
used.

> bzip2 --help does display help, but since it's going to stderr you cannot
> read all of it and since I could not find documentation I have no clue

bzip --help 2>&1 | less
man bzip2



> how to use bzip2) I would recommend that you provide both a bzip2 and a
> gzip-version of the distribution. Isn't that a fabulous idea? Why didn't
> anyone else come up with it? It's the obvious thing to do, isn't it? It

Since everyone with linux has or can get bzip2, why?



-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.


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

Re: Why is System.arraycopy() slower than dest[j]=source[j] ?

[SHUDO Kazuyuki]

[EMAIL PROTECTED] wrote:

> My setup:
>
> jikes compiler, Blackdown JDK 117a, Blackdown JDK 1.2pre,

Code generated by Jikes is different from the code
generated by javac. Code generation method of Jikes is
more straightforward and less sophisticated than one of javac.

But, I suppose that kind of Java compiler doesn't affect
the results.

>byte int  long
> 117a arraycopy  109  122  121
> 117a a[i] = b[i] 311   21
> 12pre arraycopy 123  117  120
> 12pre a[i] = b[i]20   60   83

Kazuyuki SHUDO  Happy Hacking!
  Muraoka Lab., Grad. School of Sci. & Eng., Waseda Univ.


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

Re: go back to gzip!

[John Summerfield]

On Tue, 30 Mar 1999, Tucker Balch wrote:

> Don't get me wrong, I'm glad to have java-linux even if I have to
> download and install bzip2 to use it.  Still I think it's better
> to stick with more commonly available installation tools (and libraries
> and kernels for that matter).
> 
> Is java-linux for kernel developers (100s of people) or the linux masses (millions)?
> I suppose Debian includes it, but RedHat 5.2 does not include bzip2, nor bzip2

What twaddle. What tripe.

[summer@emu summer]$ locate /*bz*rpm
/mnt/cdrom/RedHat/RPMS/bzip2-0.1pl2-1.i386.rpm
/u03/5.2/i386/RedHat/RPMS/bzip2-0.9.0b-2.i386.rpm
/u03/incoming/starbuck/pub/linux/redhat/ftp.redhat.com/starbuck/i386/RedHat/RPMS/bzip2-0.9.0b-3.i386.rpm

What's that on my RH 5.1 CD?
What's that in my RH 5.2 download directoru?
What's that in my RH 5.9 download directory?

tar has an option to specify an alternative compression program: I've not
tried it, but I expect it works. Certainly you can bzip2 -cd ... | tar xf-


-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.


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

Re: EventQueueListener not found on JDK1.2

[Jesus Correas Fernandez]

>  I don't see any reference to java.awt.event.EventQueueListener
>  in the Sun JDK 1.2 docs (or in JDK 1.1.7 docs, for that matter).  If
>  its not a documented API, you probably can't depend on being
>  there...
>  
>  Russ

Hi Russ, i've already found where is the problem. EventQueueListener
appeared in the early JDK1.2 beta versions, but was moved from
java.awt.event to form part of the java.awt.Toolkit class after
JDK1.2beta4. So, you couldn't find it in your 1.1.7 version (too soon) nor
1.2 (too late). I'm working on Solaris with the 1.2beta3 version: this is
the reason of this problem.

i've just found this in the javasoft site:

http://java.sun.com/products/jdk/1.2/previous-changes.html

Jesus


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

Re: japanese font problem japanese redhat linux 5.2 & java2

[Haruhide Yauskawa]

hi, again

thank you mr. kazuki.
i could display japanese font correctly.

to display japanese correctly with java2 on linux,
it's neccessary to add fonts.
(see
http://java-house.etl.go.jp/ml/archive/j-h-b/024378.html,
it's just japanese)
I transrated it into English.

JDK1.2's JVM seems to have a lettering engine for TrueType font ( and Type1
font).
If the X server doesn't support TrueType font, it's possible to use TrueType
font.

So the following explains easily how to use free TrueType font and Type1
fonts on Linux JDK1.2.

1. get the fonts that is changed Ghostscript Type1 font and watanabe font &
wadakenn font to a TrueType font from the following:

ftp://ftp.cs.wisc.edu/ghost/gnu/gs510/ghostscript-fonts-std-5.10.tar.gz
http://www.linux.or.jp/~ishikawa/linux/X-TT/

2. extract and install the above font in a proper directory:

% mkdir $HOME/gs-fonts
% cd $HOME/gs-fonts
% tar xvfz ghostscript-fonts-std-5.10.tar.gz

% tar xvfz xtt-fonts_0.19990222-3.tar.gz
% mkdir $HOME/ttjp-fonts
% cp xtt-fonts-0.19990222/*.ttf xtt-fonts-0.19990222/fonts.*
$HOME/ttjp-fonts

3. copy the following 'fonts.dir' in the Ghostscript Type1 font directory:

% cp fonts.dir $HOME/gs-fonts

4. copy the following 'font.properties.ja' in JDK's 'jre/lib' direcotry:

% cp font.properties.ja $JAVA_HOME/jre/lib

5. set the environment variable 'JAVA_FONTS':

% setenv JAVA_FONTS $HOME/gs-fonts:$HOME/ttjp-fonts:$JAVA_HOME/jre/lib/fonts

6. run a Java example:

% cd $JAVA_HOME/demo/jfc/Stylepad
% java Stylepad

Note:
If adding '$HOME/gs-fonts' and '$HOME/ttjp-fonts'(in the case of X-TT) to
the font path of X, it's not neccessary to set the environment variable
'JAVA_FONTS'.
But Java2D can't run correctly.

% unsetenv JAVA_FONTS
% xset fp+ $HOME/gs-fonts
% xset fp+ $HOME/ttjp-fonts (in the case of X-TT)
% xset fp rehash
% java Stylepad  -> OK
% java Java2Demo -> Fail

PS.
It's recommened to use the commercial Japanese TrueType font, becasue the
quality of the free Japanese TrueType font is not good.
And there is Microsoft's "TrueType core fonts for the Web" for the free
European TrueType font. This font is available on Linux (Microsoft
comfirmed).
http://www.microsoft.com/truetype/fontpack/win.htm


For JDK1.1.1, to see the following:
http://www.asahi-net.or.jp/~nf6h-hsmt/java.html
http://www.mail-archive.com/java-linux@java.blackdown.org/msg03327.html

--- fonts.dir ---

14
n019003l.pfb -urw-nimbus sans l-regular-r-normal--0-0-0-0-p-0-iso8859-1
n019023l.pfb -urw-nimbus sans l-regular-i-normal--0-0-0-0-p-0-iso8859-1
n019004l.pfb -urw-nimbus sans l-bold-r-normal--0-0-0-0-p-0-iso8859-1
n019024l.pfb -urw-nimbus sans l-bold-i-normal--0-0-0-0-p-0-iso8859-1
n021003l.pfb -urw-nimbus roman no9 l-regular-r-normal--0-0-0-0-p-0-iso8859-1
n021023l.pfb -urw-nimbus roman no9 l-regular-i-normal--0-0-0-0-p-0-iso8859-1
n021004l.pfb -urw-nimbus roman no9 l-medium-r-normal--0-0-0-0-p-0-iso8859-1
n021024l.pfb -urw-nimbus roman no9 l-medium-i-normal--0-0-0-0-p-0-iso8859-1
n022003l.pfb -urw-nimbus mono l-regular-r-normal--0-0-0-0-m-0-iso8859-1
n022023l.pfb -urw-nimbus mono l-regular-o-normal--0-0-0-0-m-0-iso8859-1
n022004l.pfb -urw-nimbus mono l-bold-r-normal--0-0-0-0-m-0-iso8859-1
n022024l.pfb -urw-nimbus mono l-bold-o-normal--0-0-0-0-m-0-iso8859-1
s05l.pfb -urw-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
d05l.pfb -urw-zapf
dingbats-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific

--- font.properties.ja ---
#
# @(#)font.properties.ja 1.7 98/10/13
#
# Copyright 1998 by Sun Microsystems, Inc.,
# 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
# All rights reserved.
#
# This software is the confidential and proprietary information
# of Sun Microsystems, Inc. ("Confidential Information").  You
# shall not disclose such Confidential Information and shall use
# it only in accordance with the terms of the license agreement
# you entered into with Sun.
#

#
# Linux version derived from the version for SunOS 5.5.1 Notice that
# we use the ghostscript Type1 fonts.
#

# Serif font definition
#
serif.plain.0=-urw-nimbus roman no9
l-regular-r-normal--*-%d-*-*-p-*-iso8859-1
serif.plain.1=-watanabe-mincho-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-0
serif.plain.2=-urw-zapf
dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.plain.3=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific

serif.italic.0=-urw-nimbus roman no9
l-regular-i-normal--*-%d-*-*-p-*-iso8859-1
serif.italic.1=-watanabe-mincho-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-
0
serif.italic.2=-urw-zapf
dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.italic.3=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific

serif.bold.0=-urw-nimbus roman no9 l-medium-r-normal--*-%d-*-*-p-*-iso8859-1
serif.bold.1=-watanabe-mincho-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-0
serif.bold.2=-urw-zapf
dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.bold.3=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific

serif

JDK 1.2 Patch

[L. A. Guest]

Hello, I was wondering whether I could have a diff for the linux port
of the JDK1.2 against the Solaris reference platform?

Thanks.


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

Re: grrrrrr.....

[Matthew McKeon]

Thanks to everyone who answered my question. 

Hmmm... has anyone thought of precisely what it would take
to author an OSS java plugin? 

From my (admittedly naive) perspective, it doesn't seem 
that the issues involved would require proprietary javasoft knowledge.


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

JDK 1.2 won't run JFC demo

[Joe Lin]

Hi,

I have downloaded the JDK 1.2 from blackdown.org.  and I tried to run the
JDK 1.2 JFC demo (FileChooserDemo). But I got an Linker error as follows:

Exception in thread "main"
java.lang.UnsatisfiedLinkerError:/usr/jdk1.2/jre/lib/i386/libfontmanager.so:
libstdc++-lib6.0-1.so.2:cannot open shared object file:No such file or
directory
   at java.lang.ClassLoader$NativeLibraryLoad(Native Method)
   at java.lang.ClassLoader.LoadLibrary0(Compiled Code)
   ..
   ...
I checked my directory and the file
"/usr/jdk1.2/jre/lib/i386/libfontmanager.so" is indeed there.

At another instance I tried to run the tree demo and this time I got an
  java.lang.ClassNotFoundException: javax/swing/tree/DefaultMutableTreeNode

I'm using RedHat 5.2 but I'm a newbie on Linux. How to fix this?

Thanks

Joe


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

Blackdown JDK 1.2 won't run RMI application?

[Joe Lin]

Hi,

I downloaded the JDK1.2 for Linux from blackdown.org.

I tried to run a simple RMI application. There are basically two errors. 
1. I can't start RMIRegistry. The error message is:
   java.lang.ClassNotFoundException: sun/rmi/registry/RegistryImpl

2. I tried to start the application without RMIRegistry. The error message
is:
   java.lang.ClassNotFoundexception: java/rmi/RemoteException.

Am I missing something obvious?

Thanks.

Joe


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

Re: JDK 1.2 won't run JFC demo

[Haruhide Yauskawa]

no library, symbolic link libstdc++-libc6.0-1.so.2 to libstdc++.so.2.8.0.
it's ok.

> Hi,
>
> I have downloaded the JDK 1.2 from blackdown.org.  and I tried to run the
> JDK 1.2 JFC demo (FileChooserDemo). But I got an Linker error as follows:
>
> Exception in thread "main"
>
java.lang.UnsatisfiedLinkerError:/usr/jdk1.2/jre/lib/i386/libfontmanager.so:
> libstdc++-lib6.0-1.so.2:cannot open shared object file:No such file or
> directory
>at java.lang.ClassLoader$NativeLibraryLoad(Native Method)
>at java.lang.ClassLoader.LoadLibrary0(Compiled Code)
>..
>...
> I checked my directory and the file
> "/usr/jdk1.2/jre/lib/i386/libfontmanager.so" is indeed there.
>
> At another instance I tried to run the tree demo and this time I got an
>   java.lang.ClassNotFoundException:
javax/swing/tree/DefaultMutableTreeNode
>
> I'm using RedHat 5.2 but I'm a newbie on Linux. How to fix this?
>
> Thanks
>
> Joe
>
>
> --
> 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: japanese font problem japanese redhat linux 5.2 & java2

[Haruhide Yauskawa]

japanese redhat linux 5.2 already has fonts:
/usr/X11R6/lib/fonts/URW
/usr/share/fonts/TrueType



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

Windows PLAF hack?

[Matthew McKeon]

I don't suppose anyone knows of / can recommend a hack
to get around the windows PLAF block in v1.2 of the Linux JDK?
Is such a thing possible? Is the block integral to the VM
or is it located somewhere in the runtime libs?
I'm just looking to hack it to the point where
I can get it up and running on my dev box,
since my target client platform is Windows anyway.

Or is doing so illegal? :)


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

Re: Windows PLAF hack?

[charvey]

If I remember correctly, it's fairly simple (at least in 1.1.7).  There's
an OSTYPE environment variable that you can change.  I don't recall
exactly what it needs to be set to.  Windows, Win95?  

CYA: I do believe running it on a non-windows platform violates a license
agreement somewhere.

Chris


On Thu, 1 Apr 1999, Matthew McKeon wrote:

> I don't suppose anyone knows of / can recommend a hack
>   to get around the windows PLAF block in v1.2 of the Linux JDK?
>   Is such a thing possible? Is the block integral to the VM
>   or is it located somewhere in the runtime libs?
>   I'm just looking to hack it to the point where
>   I can get it up and running on my dev box,
>   since my target client platform is Windows anyway.
> 
>   Or is doing so illegal? :)
> 
> 
> --
> 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: Windows PLAF hack?

[Uncle George]

I think u will be placing your foot in the look&feel pool of muck. It may very
well be legal, and then again not.  I dont believe its a licence u'll be
violating, but rather copyright infringement. Does MICROSOFT exclusively own the
graphics used to present the graphical context. In either case, i suppose
Microsoft will defend their position, irrespective of it being a correct, or
incorrect position.

[EMAIL PROTECTED] wrote:

>
> CYA: I do believe running it on a non-windows platform violates a license
> agreement somewhere.
>


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

pre-v2?

[Will Koffel]

I hate to feel like one of those annoyancesbut  :-)

I haven't heard anything on an expected release of 1.2-pre2, and I'm trying 
to figure out how long I'll need to hold out.
I'm getting an error of

_X11TransSocketOpen: socket() failed for local
_X11TransSocketOpenCOTSClient: Unable to open socket for local
_X11TransOpen: transport open failed for local/ws24.akamai.com:0
SIGSEGV   11*  segmentation violation
stackpointer=0xbf1ff1d0

Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v1, native threads):
.
.
.
.


This seems to be the same error as bug 506, marked "done" and apparently fixed
in 1.2-pre2.  If this really is the case, it would be wonderful!

I have 14 Dual PIII 450's coming in tomorrow, and I'd love to add another 
14 linux boxes to the world.  If I can't run our software, I'll be back in 
WinBlowsNT.  Is there any word on when it might be possible to get a pre-release2
version of the JDK?

I've been very impressed by the way with all the hard work of Blackdown.  I have 
no doubt that it's only a matter of time before my applications will be running
smoothly under linux.  Things are looking great, even the Java2D stuff which we 
use extensively.  Thanks guys!  And I hope a pre2 makes it up in time.  ;-)
Keep up the great work.

-Will Koffel







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

How to make JDK1.2-pre-v1 as my default JVM

[Joe Lin]

Hi,

I have realized after many agonizing hours that some of my problem is really
due to Kaffe. I'm currently running RedHat 5.2 and I downloaded JDK preview
v1. I set the PATH variable to point to "/usr/jdk1.2/bin". However, this
does not prevent Kaffe VM to kick in if I simply type "java .." in the
command line. I have to type "/usr/jdk1.2/bin/java..", instead. I'm new
to Linux. Is there any way I can make the JDK 1.2 VM as the default? Thanks.

Joe


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