Thin client Java apps
Hi I am new to Java. However, I have an application which I intend to write in Java under Linux. This is an enterprise application, which means that many users will be accessing the main server from remote site through a virtual private network at on 64kps lease line. The number of records to be retrieved to the client will grow as well. The user will access the information through a thin client. I do not want the performance of my application to degrade as the volumn of data increases. The records are currently sitting on Microsoft Access database. What are the Java components that are needed to build these application? Ong Boon Wee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call To Action on Java Lobby
> > I know that Kaffe is primarily a PersonalJava implementation, which is > why it breaks several progs. Is it being extended now? > Contrary to what was stated earlier on this list, Kaffe currently supports most 1.1 applications. It also runs on RH 6.0, btw, because you can simply recompile it for its version of glibc. It does not support applications relying on those parts of the 1.1 API that it does not implement yet. In particular, those relying on packages such as java.security. In some cases, you can use Sun's classes.zip in addition to Kaffe and still run the application. If your 1.1 or 1.2 application does not run, please consider submitting a bug report at www.kaffe.org. Kaffe is being extended to provide Java 1.2 functionality, however, at this point, only few classes are up to 1.2 standards. Basically, classes are extended on a need basis if people want to run 1.2 apps that rely on them. Hope that helps, - Godmar ps: I think that both Bernd & Michael are right. First, without having an vendor-neutral open source implementation, Java won't become an open standard. On the other hand, having such an implementation is not enough for it to become open. > On Sat, 8 May 1999, Bernd Kreimeier wrote: > > > Michael Emmel writes: > > > There has been a request on the Java Lobby www.javalobby.org > > > To reform the java lobby into a grass roots campaign to allow > > > Java developers to take a lager role in the determination of > > > java's future. > > > > IMO the time and energy is better spent in supporting clean > > room implementations like Japhar or Kaffe, Classpath, TYA, > > or gjc. > > > > > * J. Mark Brooks, Attorney at Law * > * P.O. Box 39, Randleman, NC 27317 * > * [EMAIL PROTECTED] * > * ICQ# 33436248* > * http://www.jmbrooks.net/law.html * > > > > -- > 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: Thin client Java apps
On Sun, 9 May 1999, Ong Boon Wee wrote: > Hi > I am new to Java. However, I have an application which I intend to write in >Java under Linux. This is an enterprise application, which means that many users will >be accessing the main server from remote site through a virtual private network at on >64kps lease line. The number of records to be retrieved to the client will grow as >well. The user will access the information through a thin client. I do not want the >performance of my application to degrade as the volumn of data increases. The records >are currently sitting on Microsoft Access database. What are the Java components that >are needed to build these application? > > Ong Boon Wee > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Hey, to write such an application, you will need the jdbc interface. The is some java sql standards (this comes with jdk). The thing you will need to install is a Driver for your sql server, so java can access it. The problem is that I am not sure that access has any server capabilities. Maybe they say something about it at java.sun.com... Papi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java and Endianess
Daniel Dulitz writes: > I'm not sure why you think there's a redundant swap by JNI. Well, I didn't, until I got into the VMSpecs and read a few remarks. I didn't really expect the VM to use big endian internally on little endian hosts, but then, I have seen weirder things happening. > Remember, the JVM spec says the JVM appears **from the perspective of > the Java byte code** to be big-endian. There are very few Java byte > code operations where endianness matters, so "in all likelihood" Yep. No argument here. > > >From Jack Middleton @ SUN, OpenGL ARB/interleaved array > > > over JNI, stripped for this discussion: > > > intVal = r; > > > intVal = intVal << 8; > > > intVal = intVal | g; > > > intVal = intVal << 8; > > > intVal = intVal | b; > > > intVal = intVal << 8; > > > intVal = intVal | a; > > > > Which breaks for the same reason, incidentally. > > The problem here, it seems to me, is that OpenGL is *not* using a > packed integer, it is using an array of four bytes; yet the native > interface is trying to use a packed integer. Nope, that's Java. OpenGL does not consider this an integer, and for those who do, it actually defines a GL_ABGR extension to catch this situation. What happens is that I, Java side, want to drop byte[4] in favor of int, and would like to pass these values through to native code. So did this Sun engineer. He event went further using Float.intBitsToFloat to merge the RGBA value with float x,y,z in a single array - which will obviously fail for all but one NaN bit pattern. > - Pass a byte array and hope you can lock it without copying, >which you won't be able to do if the JVM has stored the byte >array internally as an array of integers, or if the GC >doesn't support locking. This is undoubtedly inefficient >for small array sizes. Yes. I set things up to have a single large array, but the copying is an issue. I didn't think of a JVM that expands byte to int in memory as well... not good. But then, on a JVM that does not support pinning and copies, I might as well bite the bullet and go down the call-intensive road. > - Pass a fixed number of distinct byte arguments and let your >native code arrange them. This is inefficient for large >number of bytes, Exactly. That's the JNI call intensive road, where the color array is located in native code, and I do an equivalent of a glColor(byte,byte,byte,byte) call. > - Encode the bytes into integers as Sun suggests, but call a >native method isBigEndian() to tell your Java method which >field should be in the Java MSB so that things will come out >right in the native representation. I've elaborated on this >in a private email. In the general case this is probably >the best option. It might be a problem to keep final boolean BIG_ENDIAN proliferating into all the color handling code, as I want to keep most color data as packed int, and only use Color objects where needed. > - Use a different interface to OpenGL, if there is one, that >encodes r, g, b, and a as a real integer with r in the MSB, >g in the next-MSB, b, in the next-LSB, and a in the LSB (or >whatever). That eliminates the endian issue altogether, Well, the API offers a lot of formats, but it doesn't really consider byte[4] an integer - it's not needed in C. For pixel formats, said GL_ABGR can do the trick, but for colors, especially as arrays, it is GL_C4UB, which has a set order. Interesting. I am tempted to say that chances are better the ARB might address this, compared to the chance this can be solved elegantly in Java. > If JNI has a problem here, it's not that it guarantees that its values > are in the endianness appropriate for the hardware, it's that passing > byte arrays is too slow. Right. Even more precisely - it's that byte[4] on the Java side has too much overhead (is an object, has a length, does bounds checking, the works). > You are asking for something very strange, used only with the native > interface, and even then used only when trying to pass *byte arrays* > as integers. True. My conclusion is that the best place to pursue this is actually with the OpenGL ARB (JavaGL bindings). It might be possible to add some EXTensions or recommendations to OpenGL in order to accomodate restrictions enforced by the Java language (not JNI, actually). b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thin client Java apps
[EMAIL PROTECTED] wrote: > > On Sun, 9 May 1999, Ong Boon Wee wrote: > > > Hi > > I am new to Java. However, I have an application which I intend to write in >Java under Linux. This is an enterprise application, which means that many users will >be accessing the main server from remote site through a virtual private network at on >64kps lease line. The number of records to be retrieved to the client will grow as >well. The user will access the information through a thin client. I do not want the >performance of my application to degrade as the volumn of data increases. The records >are currently sitting on Microsoft Access database. What are the Java components that >are needed to build these application? > > > > Ong Boon Wee > > > > > > Hey, > > to write such an application, you will need the jdbc interface. > The is some java sql standards (this comes with jdk). The thing you will > need to install is a Driver for your sql server, so java can access it. > The problem is that I am not sure that access has any server capabilities. > > Maybe they say something about it at java.sun.com... > > Papi > If you're dealing with Access, you'll also need an ODBC driver. There should be one on your Office professional CD, but it doesn't get installed during a normal installation. Basically JDBC will communicate with your Access database via ODBC. Or, you could convert your Access database to something like MySQL, whih would be more robust, and ou wouldn't need to worry about ODBC. In any case, here's the Sun page for JDBC: http://java.sun.com/products/jdbc/ Ed -- Ed Gomolka ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JDK 1.2 and SuSE 6.1
I've installed SuSE 6.1 and the JDK 1.2 now works somehow. Two questions: 1) Why does it say this: Font specified in font.properties not found [--zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] The JDK 1.1.7 never complained about missing fonts. When I run the old 1.1.7 binaries AND after recompiling them with javac, I still have this error report. The fonts appear, indeed, different from the JDK 1.1.7 ones. Beside this, anything works. Any fix or workaround? 2) Should it be S slow?? The graphics (swing heavily used) is at least twice slower than the 1.1.7. I hope there is at least a JIT to improve graphical performance (advices?) Thanks in advance for any feedback. --- Andrea "Kontorotsui" Controzzi - MALE Student of Computer Science at University of Pisa - Italy - E-mail: [EMAIL PROTECTED] My home page: http://www.cli.di.unipi.it/~controzz/intro.html Founder and Admiral of Hoshi no Senshi (italian Leiji Matsumoto's fan group). Creator of It.Arti.Cartoni (italian anime newsgroup) and proud member of... +-+ |. * . | | .__ . . | |oq |po _ _| | / #==>>>==#,-' (_)\ | | | ,-|~\\ ///_ ,() ,_} | | | |/|~]]] /// ,-~' .,~ / \| . | | |\_|_|_\_\~~~~' \ (/|. | | ./~ \___/ [m] \ \__// | | _bo..__ // `-,.~~ | | _-~ 0o.__( . | | \ o . | | . (_)00 | |. \~~~*,,,* ~00 | |~0 . | | ~~~---~~ | | .*| +-+ | An e-mail network of Space Cruiser Yamato and | | StarBlazers Fans | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: JDK 1.2 and SuSE 6.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > 2) Should it be S slow?? I think so. Unless you're on a P-III 500 mhz with 256 megs of RAM... (I'm guessing this has nothing to do with the Linux port, but rather with JDK 1.2 in general). > The graphics (swing heavily used) is at least > twice slower than the 1.1.7. I hope there is at least a JIT to improve > graphical performance (advices?) The JIT is on by default. If you do some experimenting, you'll notice that JDK 1.2 with JIT enabled is *much* faster than JDK 1.1.7+TYA when it comes to loops and stuff like that. But when method calls come into the picture, I've found it to be about as fast as, or a bit faster than, JDK1.1.7+TYA. Sadly, it's also a huge memory hog compared to 1.1.7, so on my machine any larger app is much slower on 1.2. / Peter Schuller - --- PGP userID: 0x5584BD98 or 'Peter Schuller <[EMAIL PROTECTED]>' E-Mail: [EMAIL PROTECTED] Web: http://hem.passagen.se/petersch Help create a free Java based operating system - www.jos.org. -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNzYHDMBfJ1FVhL2YEQKMPQCghnVX8fgBqmEdNrlLMrqULrj4TocAoJoW +h2bHcsDXh5W+ugqdK7Y23Lc =w/p7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.2 and SuSE 6.1
Kontorotsui wrote: > > I've installed SuSE 6.1 and the JDK 1.2 now works somehow. > > Two questions: > > 1) Why does it say this: > > Font specified in font.properties not found [--zapf > dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] > > The JDK 1.1.7 never complained about missing fonts. When I run the old 1.1.7 > binaries AND after recompiling them with javac, I still have this error report. > > The fonts appear, indeed, different from the JDK 1.1.7 ones. Beside this, > anything works. Any fix or workaround? JDK1.2 uses scalable fonts (only!) as part of the Graphics2D changes. It ships some TrueType fonts of its own, which it sets as the default fonts... unfortunately, those fonts have outrageous ascent and descent values, resulting in huge spacing between lines of text. However, the JDK can also used scalable fonts that were installed for the X server; if you peruse the archives for this list, you'll find some instructions for using different fonts. As for the missing fonts, that's also addressed in some past mail. Basically, you can install a Zapf Dingbat font or, if you don't care about those characters, you can ignore the messages. Nathan Meyers [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.2 and SuSE 6.1
Peter Schuller wrote: > > The JIT is on by default. > > If you do some experimenting, you'll notice that JDK 1.2 with JIT enabled is > *much* faster than JDK 1.1.7+TYA when it comes to loops and stuff like that. > But when method calls come into the picture, I've found it to be about as > fast as, or a bit faster than, JDK1.1.7+TYA. > This is hardly what I have observed here. The damn thing is slow - much slower than 117-tya, when coming down to computation (loops, recursive method calls) and file I/O. The performance is not even comparable ;-} Dimitris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Swing never waits?
Michael Durket wrote: > > I started up the SwingSet demo and noticed how slow it was. I ran > top and noticed that even when I was doing nothing (i.e. no mouse > moves, no selections, just sitting there) the demo was eating up > 16 MB of memory and 50-60% of my cpu. It seems as if the virtual > machine never waits (at least when running this demo). > One of the issues with Swing performance has to do with the Swing components not having native peers (unlike AWT). With AWT, the peering mechanism creates a native widget which handles all the drawing of the widget; Swing has to do all of its own drawing and so forth, which is why many people find Swing slow, and also may be related to the memory usage you're seeing in the SwingSet demo. -- Jeff Galyan http://www.anamorphic.com http://www.sun.com jeffrey dot galyan at sun dot com talisman at anamorphic dot com Sun Certified Java(TM) Programmer == Linus Torvalds on Microsoft and software development: "... if it's a hobby for me and a job for you, why are you doing such a shoddy job of it?" The views expressed herein do not necessarily reflect those of my employer. Sun Microsystems, Inc., has no connection to my involvement with the Mozilla Organization. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK117 problems
I think you did upgrade your glibc from 2.0.X to 2.1.X. If so, you need jdk 1.1.7v2 not 1.1.7v1. I had same problem as you and now corrected. >Does anyone know of any current problems relating to Redhat5.2 with kernel 2.2.6 >and javac? >I get the typical "how-to" when I type #java >I get a core dump when I type # javac geko.java >and this error when I type #javac_g >/usr/local/jdk117/bin/i686/green_threads/java_g: error in loading shared >libraries: > /usr/local/jdk117/lib/i686/green_threads/libjava_g.so: undefined symbol: >_dl_symbol_value > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please add the font files to 'known-bugs.html'
Hi,
Please add the attached files ('font.properties' and 'fonts.dir') and
links to them into the following html.
http://www.blackdown.org/java-linux/jdk1.2-status/known-bugs.html
Thanks.
Kazuki YASUMATSU
[EMAIL PROTECTED] (Quick Response)
[EMAIL PROTECTED] (Sloow Response)
http://openlab.ring.gr.jp/kyasu/
Hi,
In message <[EMAIL PROTECTED]>
Urban Widmark <[EMAIL PROTECTED]> writes:
> Is there anything that can be done to make the jdk1.2 fonts behave more
> like the 1.1 ones? Included is a small testprogram with output. Notice the
> difference in height of the fontmetrics.
You can use your favorite TrueType and Postscript Type1 fonts instead
of the TrueType fonts included in the JDK1.2 (jre/lib/fonts).
Here is an example to use the ghostscript Type1 fonts with JDK1.2.
(1) Downloads the ghostscript Type1 fonts from
.
(2) Extracts the ghostscript fonts on a directory.
% mkdir $HOME/gs-fonts
% cd $HOME/gs-fonts
% tar xvfz ghostscript-fonts-std-5.10.tar.gz
(3) Copies the attached 'fonts.dir' to the directory.
% cp fonts.dir $HOME/gs-fonts
(4) Copies the attached 'font.properties' to the 'jre/lib' directory.
% mv $JAVA_HOME/jre/lib/font.properties $JAVA_HOME/jre/lib/font.properties.orig
% cp font.properties $JAVA_HOME/jre/lib
(5) Sets the 'JAVA_FONTS' environment variable.
% setenv JAVA_FONTS $HOME/gs-fonts:$JAVA_HOME/jre/lib/fonts
(6) Runs a java program.
% cd $JAVA_HOME/demo/jfc/Stylepad
% java Stylepad
Now, you can get better looks with the ghostscript Type1 fonts than
the default.
Note:
If you add '$HOME/gs-fonts' to the X font path and you don't set
'JAVA_FONTS', you can get more better looks (rendered by X not by JVM)
but Java2D will not work.
% unsetenv JAVA_FONTS
% xset fp+ $HOME/gs-fonts; xset fp rehash
% java Stylepad -> OK
% java Java2Demo -> Fail
PS.
I don't know how to use the bitmap fonts instead of the scalable
fonts. Somebody knows anything about this?
Kazuki YASUMATSU
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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
#
# $Revision: 1.3 $$Date: 1998/12/21 23:07:58 $
#
# Copyright 1997 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=-urw-zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.plain.2=-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=-urw-zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.italic.2=-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=-urw-zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.bold.2=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific
serif.bolditalic.0=-urw-nimbus roman no9 l-medium-i-normal--*-%d-*-*-p-*-iso8859-1
serif.bolditalic.1=-urw-zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
serif.bolditalic.2=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific
# SansSerif font definition
#
sansserif.plain.0=-urw-nimbus sans l-regular-r-normal--*-%d-*-*-p-*-iso8859-1
sansserif.plain.1=-urw-zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
sansserif.plain.2=-urw-symbol-medium-r-normal-*-*-%d-*-*-p-*-adobe-fontspecific
sansserif.italic.0=-urw-nimbus sans
