Windowing System
I've written a complete Windowing System in Java . The top layer is the Swing. It contains a hardware driver a bootstrap awt driver, And a driver using XTC a all java XLIB. It is available at http://www.fdc.co.uk/jos/src/graphics.tar.gz I hope some members of this group are intrested. I'm currently seeing if the JOS group wants it. Mike
Java Awt/Swing is fatally flawed
Hello I've been working for a while on and all java Windowing system. My current version is written on top of the Swing toolkit. Which is practically all Java. Well it turns out even Swing is flawed. The problem with Swing is the attempt to reuse Graphics context and not being thread safe. Plus it is removed from the hardware by the underlying windowing system and is hacked to run at a higher level of abstraction. You get hosed sooner or later. I've have come to some conclusions tonight. One if you wish to use any native graphics above the level of basic device drivers and a drawing package you will not e able to do it in a generic manner. There are too many places were inconsistencies cause basic problems. Second if you move to the swing model things get better but you still suffer inconsistencies from trying to save multiple graphics context's i.e. SwingGraphics does not really work. I think the guys at Id software or any other game developer could attest to this. It's well understood in the gaming community but ignored by the commercial GUI resellers. In my opinion there are only three choices for a GUI in java. 1.) Allow each platform to expose its native interface this is akin to the approach taken by Apple, Sun and Microsoft. This results in continuos problems that can in my opinion never be resolved. 2.) Try a middle ground this is the approach taken by Swing and previously Apple/Next in Openstep. This approach works a lot better but still results in some fairly basic problem mainly resulting from not having direct graphics hardware access across platforms and dealing with native windows. This approach simply reduces the number of problem which result from using the first approach. I does not eliminate them. The real problem results from graphics code having to go from very high level draw object methods to low level blitting ops. There is no way to support this on top of platform which contain even simple differences. Swing in my opinion will fail just as Openstep would have. 3.) The last resort is to support java directly at the primitive graphics layer. This turns out to be the only viable solution. This is the path I took and it works well. I did it not because I originally though it would be the best solution but simply because I wanted to build it. Now I feel its the only viable solution. This is the approach taken by the Game developers. They do it for speed for the most part but it turns out to be the only way to build a stable consistent GUI system. In reality a GUI is nothing more than a basic game. The main reason I'm writing this is to one hope the Linux community explores adding low level Java graphics support to Linux. I believe that with ggi Linux could become one of the few platforms were Java graphics work correctly. You can continue to support X but Java graphics object must be first class citizens with the native graphics. This is not really a language issues but a simple matter of true java support. To forget java for a moment. I for one would not want to write some hybrid which supported both KDE and Gnome but this is exactly what the AWT is today. Next the Swing is again much better but is akin t supporting Gnome inside KDE which leads to some interesting problems. I don't think anyone would whant to solve theres problems in C/C++ why would you expect them to magically go away in Java. As another example Exceed is a fine X windowing solution for Windows NT but is suffers numerous integration problems. Most people don't worry about them because it offers a solution but it will never be as good as native Win32 or native X period. This bring up a basic problem with Linux. It's intel centric. Although linux runs on a multitude of CPU's it is still centered around the intel cpu. It's offered e quit a bit of freedom in choosing a free OS. but try finding binaries for the alternative platforms. The percentages of Linux running on various cpu's closely mirrors that of commercial offerings. Within the Linux community few have left the intel dominated computer market. This is a big problem IMHO. Although Linux likes to represents a challenge to Windows it's actually more threatening to the Intel side of the monopoly. Once you chose and alternative OS moving to and alternative CPU is not a big issue. Considering the number of seats of Linux accumulating over the next few years and the fact they can easily switch cpu designs. Then Linux could represent a viable platform for a secondary cpu manufacture. This is one of the unrecognized powers of linux. I suspect that Linus may have realized this otherwise why is he working for Transmeta I think the only real problem is Linus is a systems programmer and does not understand all the needs of applications programmers nor should he. Its up to the application programmers to express those needs to Linus and the other systems programmers. Once th
Re: Java Awt/Swing is fatally flawed
Dan Kegel wrote:
> Michael Emmel wrote:
> > Hello I've been working for a while on and all java Windowing system.
> > My current version is written on top of the Swing toolkit. Which is
> > practically all Java.
> > Well it turns out even Swing is flawed.
> >
> > The problem with Swing is the attempt to reuse Graphics context and not
> > being thread safe. ...
>
> Could we pause for a moment here, and have you explain
> the problem in greater detail? In particular, what is
> the problem with not being thread-safe?
>
> It seems to me that the Swing architects came to
> a conclusion about how to write thread-safe programs:
> thread safety is difficult. The best way to achieve
> it is to carefully segment programs such that the
> interfaces between threads are particularly well understood.
> For instance, rather than allowing lots of threads to call the
> many methods of a Graphics or other complex object,
> and attempt to have all these methods lock all
> the resources they reference in a way that avoids deadlock,
> only allow simple objects like queues to be used by
> multiple threads. That's why Swing is not thread-safe:
> they expect you to segment your program so that only
> one thread manages the user interface, and communicates
> with the rest of your program through a carefully
> designed thread-safe interface (e.g. a queue or two).
>
> I happen to have helped fix a bunch of deadlocks in
> a complicated Java user interface by doing just that,
> so I trust their judgement.
Well that illustrates my point. A developer should not have to do that.
The Swing team should provide the queue interface it should not have to be
cobbled together by every developer that wants to write a complex graphics
program.
I never had any problems with Display Postscript under Nextstep. The
interface was
very easy to use and multi threaded drawing was much easier to implement.
Just fill a message buffer and send it. The locking is at the message level.
Pretty trivial.
Real time drawing can be done by allowing direct access for a screen portion
and requiring
that a window painting in this mode is alway it the highest layer so it
cannot be coverd up.
The Windowing system simply enforces clipping. You could also "lock" its
position or throw away the feed while moving.
Javasofts callback model is non-intutive and easy to screw up. Your right
that a drawing queue
should be used but it should be provided by Javasoft. Plus translation and
current paint mode should be exposed and thus reversible. A simple reset to
default for graphics contexts would be quit useful.
As far as the graphics reuse I found a bug with Swing when it has a lot of
graphics context's it seems
it does not correct for translation correctly but since they play games with
clip rects and translations.
The SwingGraphics state does not match the underlying native graphics state
so I finally gave up
and decided to spend my time doing something more useful like bitching about
Java's drawing model.
Although I think trigger a bug there stuff is so screwed up I can't decide
who has the bug.
Also the decision to not make SwingGraphics public should be reviewed.
Drawing should not be this hard IMHO.
give this a try in a Swing subclass with a few widgets on it.
For me I dont trigger a bug until sevberal object try to share a Native
context.
public void paint( Graphics g ) {
super.paint(g);
g.setPaintMode(); // makes the context un reusable.
g.dispose();
}
This code should have no effect at all except to cause the graphics to really
dispose;
Now maybe I don't know what I'm doing but it seems to blow the Swing up when
it gets several
objects sharing a Native graphics context. Like I said I looked and gave up
trying to figure it out.
The games they play becuase of underlying design problems are difficult to
trace.
What really irritated me not the bug but even with the code in front of me
It's so
hacked I can't trace it.
>
>
> You go on to write:
> > The NT thread model is flawed it allows race conditions.
>
> I thought NT implemented threads fairly well-
> and that's why Java code that runs on other Java ports
> sometimes has race conditions on NT Java, because
> those other platforms don't do preemptive multithreading,
> and therefore hide race conditions.
>
> This is an interesting discussion, but it probably
> deserves to be split up into a few pieces- the
> Swing discussion should probably move to comp.language.java.gui.
Okay I'll drop it but I find NT will switch from thread A to B before
A enters a lock. Thus B runs and deadlock is avoided.
I guess I should say thread starvation also
which I lumped into race condition. Anyway from experience I find that code
which runs
on NT locks up tight under Unix I've never experienced the reverse. And on
investigation there is a bug in the code.
But this disccusion should not be here it happens with Green threads to.
I just figured if I was complaining I might as well say it all : )
Re: Swing and Threads
Gerald Gutierrez wrote: > > > Well that illustrates my point. A developer should not have to do that. > > > The Swing team should provide the queue interface it should not have to be > > > cobbled together by every developer that wants to write a complex graphics > > > program. > > > I never had any problems with Display Postscript under Nextstep. The > > > interface was very easy to use and multi threaded drawing was much > > > easier to implement. > > > Just fill a message buffer and send it. The locking is at the message level. > > Are you sure ? The UI libraries of NeXTSTEP are not threadsafe, and it > was strongly encouraged that the UI be accessed by only one thread. > Interaction with the UI via multiple threads often yielded strange > results. This is the primary reason why there are so many > "MultiThreadedApp" objects around. These things used to buffer UI > requests from child threads, and release them to be executed when the > main thread is scheduled and executing so that conflicts would not > occur. > > To clarify, I mean NeXTSTEP in terms of the 3.x versions, not OPENSTEP. Short answer the UI used a single DPSContext you were free to create as many as you wanted. Thre creation is expensive I never used more than two. The Contexts were individually thread safe. So you can eather create a new Context or manage your default one. You were gasp given a choice. Alos to Dan Kegel I noted privatley that invoke later allowed my stuff to at least work. Unfortuntley when you drag a window wich uses invokelater from drawing the Components can be drawn before the window so its just a work around not a fix. Having the Window chase its panels is only mildly amusing. Mike
Re: JDK for 21064?
Uncle George wrote: > u have my permission to post all those emails on this list. i'd like to see them >myself. I > think the previous offer was " who would u like to support ( with regard to the linux > porting project takeover ) u or the guy from javaworld ( i think ), i beleive my ans >was > neither. The previous dialog was with karl asha over my subscription to > java-linux-porting, some many years ago. Nothing has changed since then. Its ok to >have a > private porting club, but just dont expect me to join. > gat > > Steve Byrne wrote: > > > > > > > I think either your email is broken, or you have been deliberately ignoring > > us. We've asked you time and again to join the group; you've said nothing. Ok, > > so we quit asking > > I actually agree with Uncle george I've been working on and experimental Java windowing system http://adric.home.mindspring.com/shark/ This Windowing System is between one too two years from public release. Unfortunately I need tight integration between 1.2 and the O.S. I personally did my best to try to get 1.2 support for Linux including e-mail directly to Scott. 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 love what you guys are doing but Uncle George represents Java in the 64 bit world and I'm looking a Java if you wanted to write a GUI today. You're ignoring these fascinating opportunities. I suspect George's biggest problem is with your narrow "company" style approach to the JVM. This is a result of Suns lack of foresight to the true capabilities of the java platform. Look at there pitiful restrictions to Jini. Java is way beyond a company and even the basic computer problems faced today. To solve the future which is coming soon (Intel). We need Uncle Georges 64 bit JVM and need to know what is required for 64 bit support. This is NOT trivial My stuff is more esoteric but Linux Java must support RD efforts. Forget about 1.2 on Linux today where will we be in 2/4/8/16/32/64/128 ... Mike
A Scenerio
5 years from now you walk up to a street corner and a guy in a dirty coat approaches you. He say hey man I've got all the sources for JDK 1.2 for sell. How much would you give him How much is 1.02 worth today... Mike
Re: diffs for i386/non-comm 1.2 sources.
This is funny when I worked on the 1.02 JDK port to NextStep I wrote a driver that allowed you to do DPS calles from Java. I felt it was th "way to go" Looks like Sun is moving in that direction. I suspect this is for Graphics2D support. The driver is Mach based so not that useful. But if Sun is using DPS then tak a look at gnustep http://www.gnustep.org They have a free DPS engine on X. I'm waiting for the Community license. Uncle George wrote: > As i said i dont know ( knew ? ) about DPS. The call that uses DPS has > been edited out ( ie no shared link undefines ) when this font/shared > lib is loaded in. So now i know, so i'll see if its avail. > gat > > Nathan Meyers wrote: > > > Gnu announced in May (http://www.gnu.org/bulletins/bull24.html) that > > they're working on a Display GhostScript -- I don't know how far along > > they are or how compatible it will be with traditional X-server-resident > > DPS servers. I gather from the announcement that you can locate the DPS > > client library (the missing DPS*.h files and associated library) in > > GhostScript source distributions. > > > > Of course, I also expect that anything Sun is implementing with DPS will > > also be implemented in non-DPS ways, since they license to many vendors > > (and render to X servers) that don't have DPS. > >
Swing 1.1.1b1 does not compile under Linux
Hi I need to add patches to Swing to fix show stopper bugs but
the new 1.1.1b1 does not compile under linux using jdk1.1.7
Jikes also fails.
Anyone have any luck. The problem seems to be in BasicTableUI.java
The private inner class access seems to fail. Under both Jikes and
javac.
Anyway Jikes failed in many other places too.
I wish Sun would tell us whow they compiled it.
I suspecting it was done under 1.2 ??
Mike
BTW Heres my patch but javasoft hasnt done anything about it.
You can't show a internal frame inside another : (
in javax.swing.DefaultDesktopManager.java
WAS
public void activateFrame(JInternalFrame f) {
...
else if (currentActiveFrame != f) {
// if not the same frame as the current active
// we deactivate the current
if (currentActiveFrame.isSelected()) {
try {
currentActiveFrame.setSelected(false);
}
catch(PropertyVetoException e2) {}
}
.
PATCH ...
else if (currentActiveFrame != f) {
// if not the same frame as the current active
// we deactivate the current
if (currentActiveFrame.isSelected()) {
try {
if( !currentActiveFrame.isAncestorOf(f) ) {
currentActiveFrame.setSelected(false);
}
}
catch(PropertyVetoException e2) {}
Re: HotSpot (was Re: Linux jdk 1.,2 Jit )
f all and I fear that Sun will not open up the hotspot technology for research use and thus hinder my future research goals. Hopefully I'm mistaken. If there is any interest at Sun in my Windowing system its called Shark Windows It freely available via CVS at www.gjt.org cvs directory java/org/gjt/shark. Thanks for your time. Michael Emmel Oliver Fels wrote: > > Sorry but that whole "hot spot" thing looks like vapor ware. Besides > > even if Sun is able to get "something" out the door they have already > > stated that it will be given to "paying customers only". Instead of > > Easy answer on this: Let´s wait and see. > > > waiting and hoping that Sun will do us a favor why not help out with > > the free JIT projects like TYA? I have already found a bug in TYA > As I said, if there is a JIT for Linux which overruns all benchmarks > and which comes close to what HostSpot is promised to do, I will > be glad to use it. > > > and I plan on making a small test case so that I can track down > > the problem or send it to the TYA folks. If you help out with the > > free Java projects then free Java will get better than > > "paying customers only" Java that Sun wants you to buy into. > Sun does nothing for pure charity reasons, this is absolutely clear. > JAVA Linux has to compete with other platforms to be accepted > and I am not sure if it can do it by relying on free teams only. > >From my point of view, I am managing projects which heavily rely > on performance and would love to pay for a Linux HotSpot like > runtime. > > In the meantime, we will give TYA a try as standard JIT for testing > purposes. > > Oliver > > ___ > Oliver Fels| e-mail: > Neurotec Hochtechnologie GmbH | [EMAIL PROTECTED] > Team Manager JAVA-/IT-Security | Phone: > Friedrichshafen, Germany | +49 7541 3012 351 > --- > > -- > 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: A Java VM that uses svgalib?
I've already done it : ) I've written a java windowing system called shark windows. The AWT peers are implemented on top of the Swing. I have a driver written on top of a Java device dirver for the Cirrus Logic 5430 it's currently not functional I haven't upgred its api. One on top of a XLIB replacement called XTC. And one which bootstraps off the AWT for graphics calls. It has a portability layer at the graphics api level. Basically implement the Graphics class and it just works TM : ) Anyway I plan on a GGI driver as soon as I get around to it. Can someone give me the email adress of the person who is writting the AWT/ggi driver since if he has the graphics class working I'm 100% java from there up. Shark is very close to a stable release it's currently it's only avialable via CVS at www.gjt.org CVS java/org/gjt/shark I hope to have a release in the next week or two. Anway its almost complete I'm actually working on the File Viewer/application launcher right now. I've been able to succesfully run several apps to date. Mike Moses DeJong wrote: > A guy involved in the GGI project is working on a GGI version of the > AWT. Such a port would run on SVGA, on the linux console, on X and > all the other graphics targets that GGI supports. More info on GGI > can be found at www.ggi-project.org and you can read about the GGI-AWT > stuff on the GGI mailing list archives. > > Mo DeJong > [EMAIL PROTECTED] > gimme multimedia group > > On Wed, 3 Mar 1999, Rick Graham wrote: > > > Hi Guys > > > > We're tossing around the idea of creating a linux JAVA port that does > > not require X. There would be several advantages to such a system, thin > > clients for one, Bill Gates would probably lose sleep over it, theres > > another (hehe). > > > > Since you are the experts I was hoping to get some useful feedback > > regarding this idea. > > > > Do you think it would be a prohibitivly enormous undertaking to make the > > vm work with svgalib? > > What resources could we get from blackdown? > > Would you be interested in any involvement in such a project? > > > > A veritable multitude other questions, later... > > > > Also thanks for your work guys. :) > > > > -- > > Rick Graham, Senior Developer > > BitFlash Graphics Inc., Ottawa, Canada. > > [EMAIL PROTECTED] > > http://www.bitflash.com/ > > > > > > > > -- > > 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JDK 1.2
Last ! Where is JDK 1.2 Just I joke I wanted the honor of posting the last of the WHERE JDK 1.2 messages : ) No rush I'll be on vaction this weekend : ) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE PLAF
Andreas Rueckert wrote: > Hi! > > Somewhat OT(?): > Since I don't like the other PLAFs, I've started to create a KDE PLAF. Far from > completion, but some stuff already works (on JDK 1.1.7 + Swing 1.1B3 + > KDE 1.0). If you are interested in contributing or testing, please drop me a > p-mail. > > Ciao, > Andreas Hi Andreas I've rewritten the AWT to work on top of Swing I'd love to be able to distribute a LGPL look and feel I'm very intrested. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non mofit AWT.
Ulli Kortenkamp wrote: > > "Jeff" == Jeff Galyan <[EMAIL PROTECTED]> writes: > > Jeff> That's a question you should pose to Sun. Matthew Panetta > Jeff> wrote: > >> Given that there are a few good windowing toolkit out now for > >> linux (GTK, QT, JX) could the JDK be proted to these instead of > >> useing mofit? > > I did this, since I asked for a non-motif-based AWT some month > ago. The answer by Sun was: It exists. It is called Swing. And I have rewritten the AWT to run on top of Swing so I don't use Motif. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non mofit AWT.
Jeff Galyan wrote: > AWT on top of Swing sounds pretty interesting... > > Netscape's IFC basically do everything on top of a Panel (faster than > Swing for many uses), so that's another alternative. Way back when I started with the IFC on NeXT's(RIP) Display postscript engine. Then JFC came out. IFC is much faster so I think one day JFC will be there. I'n the long run the JFC is a better toolkit and is being actively developed. THe IFC is still under a restrictive license and is not being actively developed. IT would be nice if Netscape released the IFC under LGPL. THis would Help Classpath a lot on a JFC implementation. The use of a Panel in IFC is not the reason for it being fast IMHO. I haven't put Optimize It on JFC but I suspect there problem is the event loop get's stalled in real applications. Also maybe drawing requests/mouse event's are not getting correctly coalecsed. Nothing that can't be fixed in time. The next thing I did was write a driver in Java for the CirrusLogic 5430 and got IFC then JFC running on it. It wasn't much slower than Swing on top of a Windowing system and this was on a fully interpeted. I unrolled the blit loops and it helped a lot. I would not suggest you try that at home but it showed me that it was feasible with todays jit's its proabably usable. If Sun ever decided to really release Hotspot. Swing + Hotspot+ low level graphics lib is probably faster than todays native windowing systems. But I don't think Sun wants Java to have it own windowing system. IMHO Mike > > > --Jeff > > Michael Emmel wrote: > > > > Ulli Kortenkamp wrote: > > > > > >>>>> "Jeff" == Jeff Galyan <[EMAIL PROTECTED]> writes: > > > > > > Jeff> That's a question you should pose to Sun. Matthew Panetta > > > Jeff> wrote: > > > >> Given that there are a few good windowing toolkit out now for > > > >> linux (GTK, QT, JX) could the JDK be proted to these instead of > > > >> useing mofit? > > > > > > I did this, since I asked for a non-motif-based AWT some month > > > ago. The answer by Sun was: It exists. It is called Swing. > > > > And I have rewritten the AWT to run on top of Swing so I don't use Motif. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non mofit AWT.
Nigel Gamble wrote: > On Sun, 4 Apr 1999, Michael Emmel wrote: > > The next thing I did was write a driver in Java for the CirrusLogic 5430 and > > got IFC then JFC running on it. > > It wasn't much slower than Swing on top of a Windowing system and this was on > > a fully interpeted. > > I unrolled the blit loops and it helped a lot. I would not suggest you try > > that at home but it showed me that > > it was feasible with todays jit's its proabably usable. > > If Sun ever decided to really release Hotspot. > > Swing + Hotspot+ low level graphics lib is probably faster than todays native > > windowing systems. > > But I don't think Sun wants Java to have it own windowing system. > > Actually, Java 1.1 does have it's own windowing system. It's called > TinyAWT, which has a Java implementation of all the AWT peers. And > it is used on a currently shipping Sun product - the JavaStation. > The JavaStation uses Java for everything - including the windowing > system, the OS (JavaOS) and all the device drivers. And the Java Community referenced so often in ther new Open Source License get's too play with how much of this cool code ?? Nada, Zip zilch Oooh your not worth a 100 milliion dollar contract please go away... What really funny is they had a big talk on thre web site about how to start a new Java based comapany but they keep the technology that matters hidden. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I have a big problem with Sun
It seems that Sun will not support bug reports that occur in the platform independent parts of Java since I'm using Linux. If you report a bug and say your on Linux they say its not a supported platform. Even though I've been reporting bugs in the Swing. I can't believe Sun forces me to use NT ! Anyway just though I'd warn everybody on the list that if you report a bug don't let them know your on linux they will drop it. Pissed off. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non mofit AWT.
[EMAIL PROTECTED] wrote: > "Java to have it own windowing system" > > H ... Well I think it needs to write a some new API calls like below: > > void java.awt.Frame.iconifyWindow() > " java.awt.Frame.deiconifyWindow() > " java.awt.Frame.raiseWindow() > java.awt.Frame.lowerWindow() > java.awt.Frame.raiseToFrontWindow() > java.awt.Frame.lowerToBackWindow() > > int java.awt.Frame.getStackingOrder() > > Non of these programmatics exists (yet) to support the native window manager. > > Peter I my system JIntenral frames are first class components the can be added to the desktop just as Frames can. So if you want it then you add JInternal frames not Frames. Plus you could get the peer and cast it to get at theJInternal frame api. My first goal is to unify the Swing/AWT api. At that point one can look at the whole api and reconsider the design. Maybe Sun will consider Shark in Java3-4. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I have a big problem with Sun I retract !
Dimitris Vyzovitis wrote: > Rob Nugent wrote: > > > Mike, > > > > In my experience the Sun bug reporting system does not work well. I stopped using >it > > since I was just burning cycles and getting annoyed. > > > > I even had a generic defect returned as 'user error' which the Blackdown folks > > has already diagnosed and fixed and supplied the defect line number for me to > > put into the JavaSoft bug report. > > > > I also tried to report some bugs once, but all I got was ignorance > Perhaps sun pays attention only to commercial partners ;-} > > Dimitris > Funny I started working with a engineer on a bug at Sun and he was more than helpful the bug turned out to be in my code. This is the first time I recieved any real suppor from a Sun engineer. In this case it was my bug but maybe next time. This is the first time in over three years that I've gotten any real response from Sun. Maybe its a start of a trend ?? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status updates [Was: Re: ...]
Wes Biggs wrote: > > All your arguments are factually right. But pyschology is at work here, and > > especially in an extremely important project like JDK porting (from my > > perspective, it is the second most important project after the kernel and at > > times more important), you have to account for psychology, whether you're doing > > work on a voluntary basis or not. It just makes things much smoother. > > You're confusing the Blackdown port of Sun's sources with truly free software. Sun > has paid lip service to GNU/Linux support to gain media attention and developer > chic, but their supposed support of Java 2 on GNU/Linux seems to be more > javax.swagger than javax.swing, and from a developer point of view, they've > *increased* Blackdown's time-to-market by requiring JCK compatibility (I'm not > arguing that this should be eliminated, just that this is the effect it has had). > > If you're interested in contributing to a free project, consider Japhar > (http://www.japhar.org/), Kaffe (http://www.transvirtual.com/), both free JVMs, or > the GNU Classpath project (http://www.gnu.org/software/classpath/), which is > providing a clean-room class library implementation. Most java developers who have worked for any time are probably "tainted" by Suns sources. I'm very careful about what I work on for free software. If I had known three years ago what I do today. I would have ignored java and stuck with Objective-C. I'll continue to program java today but am silently waiting for its successor. I wish I could contribute to those project but I'm not able too and I think many are in that boat. I've traced way to many bugs over the past three years into Sun's sacred JVM. > > > IMO, if Sun does not come through on their promise of support for GNU/Linux, it's > futile to complain to Steve, Juergen and the other folks working on the Blackdown > ports, because there's only so much they can do with Sun's proprietary sources > without Sun's explicit support. Linux has distinguished itself as the premiere > operating environment for free software. Your assertion that the JDK is equivalent > in importance to the kernel may have some meaning to you, but while the folks who > are doing the GNU/Linux port may be more involved with Sun than you or I, they're > still not the ones calling the shots. No but He is expressing the sentiment I suspect of the vast majority of Linux/Java programmers ! And there does not seem to be another avenue. No one is unhappy with the work that the porters have done the problem is Sun's tied there hands. I don't see being very very unhappy with Sun's approach to java an java on linux in particular to be and attack on those who are doing there best to make it a success. I would join the porters but my interest lies in novel JVM implementations not the current way java is implemented. But I think that allowing research work on the JVM is so far from Sun myopic view of java that it's not even worth trying to get them to understand the possibilities which java holds. Many people who use Linux understand this and I wholly agree that Java on Linux is second only in importance to the kernel itself. The fact that a company which likes to talk about WORA but ignores and open platform which runs on hardware which I personally have never heard of is astounding, and even scary. I hope that Gnu can soon provide a stable java platform so that Java can be freed from people capable of such behavior. It makes me wonder how many important advancements is Computer Science have been destroyed by mindless corporations. Java is a concept not a implementation. Sun controls a implementation the Gnu world will control the concept. > > > I'd rather see the efforts being expended here complaining that API foo has been > released yet go into developing a free implementation of foo. If you want software > with definite release schedules and true support, you shouldn't be relying on > GNU/Linux in the first place, and psychological or not, whining isn't going to > change that. Given the opportunity I'm sure someone would be happy to support 24/7 java on Linux for commercial use. Many people are paying for Linux support today. I would be willing to pay for commercial support Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possible Java Bug ?
This generates the following output ..
Parent2 Foobar null
I understand why but it compiles and fails at runtime.
Thus if you subclass a class with and inner class any method used is the
parents consturctor cannont
acces the Outer class.
Of course I may be doing something stupid but I know the instance.super
stuff and this is the referse case.
It seems a bit pathalogical and also it compiles fine even though it
will never run.
The null pointer excetion if you access OuterClass.this is not exactly
helpful either.
Any thoughts ??
Mike
class Parent1 {
public Parent1(){
callFooBar();
}
public void callFooBar(){
System.out.println(" Parent1 Foobar");
}
}
public class OuterClass {
class Parent2 extends Parent1 {
public void callFooBar(){
System.out.println(" Parent2 Foobar " +OuterClass.this);
}
}
public OuterClass() {
Parent2 p2 = new Parent2();
}
public static void main( String[] args ) {
OuterClass test1 = new OuterClass();
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What could happen if Sun opened up Java ?
Well now that the Sun "Bashing" is back. Let me give you my dream of what would be possible if Sun opened up Java. First the spec for a server side Java implementation would be completed rapidly. second work begins on a distributed server side VM. WHat does this mean ?? Think about Java based server which have cluster support built in. Sun could provide a simple PCI add on card that supported firewire. This card would covert any PC into a high speed cluster node supporting a JVM Cluster. This cluster would be CPU independent allowing you to mix and match cluster nodes from available hardware. Sun could then make a PC card like device which supported a administrative cluster client this replaces the current tty concept. Servers would then ship without any direct support for console input but instead have a ports where you could either plug in a another cluster node or a console node. This is stuff Sun could sell. Java frees you from the OS/User space design. Since server side programs must be robust the best place to make use of this technological freedom is on the Server not the client (JavaOS). This system is a Server Interface Computer (SIC) If Sun opened up Java today this sort of platform could be a reality in less than a year.. Think about seamless fail over cluster support on the server using any available hardware. And since this card would ignore the keyboard and graphics input it is simple to boot and OS on any PCI based system. The GUI is handle by a Console node or a Human Interface Computer (HIC). Also consider apis for advanced agent programming with and open process research could really take off on agent style client server systems. Java provides the ability to have mobil code. The cluster provides a reason for it to move. These cluster could also continue to use low band with network connections for extended Beowulf type clusters. Plus the best clusters would consist of high end boxes like Sun sells. But now we always write code that is designed to scale. The bottom line is a distributed VM would be very very good for Sun's bottom line. And open source initiative would make it possible. Sun works on the hardware we work on the software. Second by seperating the HIC from the SIC we can explore various ways to build a HIC's in the past have been severely restricted by the lack of network support and the requirements that all processing is local. Plus the current controller of the HIC interface has no reason to make it interoperate well in a distributed environment. Sun by opening up java and working toward a toward a industry standard SIC interface also allows the HIC to specialize in its primary purpose interface with a Human. Using off the shelf technology a passive back plane box could be constructed which allows you to plug in and arbitrary number of HIC's and SIC's too build what today is considered a work station. It would be very easy to make a disk drive become a simple specialty SIC. Or a router or printer or The creators of Jini saw this but Sun destroyed it. This is a future that's possible the fact that almost everyone is blinded by Sun's short range approach to java including Sun itself really saddens me. If Sun truly believed in there slogan that the Network is the Computer they would be working towards a goal like this but instead there hobbling the java platform to the point that people can only look at Sun's narrow vision for Java(tm) that no one is talking about what java could become. I was very exicted about Jini but Sun managed to close it off. In a world full of HIC's and SIC's Sun the company would do quite well. Sun should be selling HIC and SIC hardware not closing off the required java software. This is why I'm personally not happy with Sun. It would be nice if other's shared there vision of what's possible in a world where java was open. I think that maybe if Sun saw what we would be willing to do with and open platform they would reconsider. What if ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Bashing 2
Matt Welsh wrote: > I usually can't stand flame bait like this but I wanted to point out one > thing. > > Sun has clearly recognized some of the advantages of the Open Source model, > which is the entire reason why they have adopted the 'Sun Community Source > License' for a large number of their products -- including the JDK. > > This link is the paper 'Sun Community Source License Principles' which does > a fair job at explaining the motivation behind the license: > http://www.sun.com/981208/scsl/principles.html > It would behoove one to familiarize oneself with this before ranting on > about everything Sun is doing wrong -- there is a lot they're doing right, > too. > > Sun is very concerned with the potential 'splintering' of Java > standarization efforts. The idea is that if many offshoots of Java are > propagated, this seriously weakens the overall adaptation of Java technology > and would become a weak spot in Sun's desire to make Java a universal > standard -- thereby allowing stronger market forces (such as Microsoft) to > essentially destroy Java once and for all. I think we can all agree that > this would be a Bad Thing. Well take a good look at some of the interesting research surrounding Kaffe I just download a complete Java OS based on Kaffe. Plus there are other very interesting projects ongoing. This has not weakened STANDARD Kaffe in the least. What I have suggest to Sun is they provide the standard implementation and a clearing house for Research implementations. They certainly have made several mistakes in the standard implementation. The lack of a Process concept and System.out plus no way to kill a thread and reclaim its monitors... People who side with Sun confuse these issues repeatedly. There are three basic situations. 1.) The STANDARD Java 2.) Porting the STANDARD to a new platform. 3.) Creating new Java non commercial non standard implementations which investigate some new OS feature or Java extension. Sun need only require that the research implementations be marked as such and that they are Open Source. Sun understands the difference between standards, porting and research. Only by confusing these issues does Suns stance look reasonable. And Sun does so routinely to support there position. I don't think anyone feels that not having a STANDARD Java is a good thing but that doesn't mean you ignore other issues. Sun's approach to java reminds me of the military saying where they destroy a village to save it. Well the SCL doesn't even let the village begin. > > > So, there is a clear tension between the desire to make Java truly Open > Source and the desire to prevent it from fragmenting to the point where its > market penetration is weakened. Clearly, as supporters of Java, we should be > supportive of both goals. Otherwise it will be all too easy for someone else > to come along with a "Java killer" which ends up dominating the market in > its place. See above its Sun FUD that this is the case. Its a simple matter of licensing. The problem is Sun severely restricts the distribution of the porting and research implementations. The very ones which should be widely accessible, free and open to interested parties. This sort of thing can easily be handled if Sun worked with people to ensure that non-standard JVM's are open source. The GPL is famous for its viral like nature Sun could require such a license for any non standard VM. And if per chance people really really like some feature of a non-standard VM then request it be made part of the standard. It's not that hard. Sun is trying to prevent any hint of non standard implementation via a scorched earth policy. It funny how closely Java relates to the vietnam war. Sun the big stupid americans and us the poor little viet-cong fighting a guerilla war. Well we know who won that one. What is interesting is it took twenty years for america to lose the vietnam war. It took twenty years for Linux to finally open up Unix. It will be very close to twenty years before Linux completely destroys Microsoft. Do you want to wait twenty years for Java ? > > > So, give Sun a little slack. They are making an honest effort to do the > right thing. It is far more constructive to work within the framework which > they are trying to build, and to provide useful feedback on that framework, > than simply "jumping ship" on Sun altogether. That approach can't do anything > good for Java in the long run. > Why ?? At the very least set aside one person at Sun to handle our issues. I would very much like to see someone support Suns current position from the viewpoint that Sun must provide a way for open research to be done on the VM and allow porting efforts to adopt the best development strategy to make the best VM for a given platform and finally how this relates to Java standardization. They have been very very accommodating to commercial entities porting issues allowing them to keep any improvements they make. To
Re: Possible Java Bug ?
To extend my own question I think this is a bug since thre is no way
for a programmer to intialize the enclsing instance variable.
I think that Object should have a methos added.
getEnclosingInstance()
Then you coud do ..
public void callFooBar(){
if( OuterClass.this == null ) {
OuterClass.this = getEnclosingInstance();
}
System.out.println(" Parent2 Foobar " +OuterClass.this);
}
My point being that the subclass should alwas be able to access its enclosing
class.
The probelm is thre is no way for a prgrammer to init the instance variable
that I know of.
This does not work either
class Parent2 extends Parent1 {
Parent2( OuterClass outer ) {
outer.super();
}
public void callFooBar(){
System.out.println(" Parent2 Foobar " +OuterClass.this);
}
}
Anyway I think it is a bug.
Michael Emmel wrote:
> This generates the following output ..
>
> Parent2 Foobar null
>
> I understand why but it compiles and fails at runtime.
> Thus if you subclass a class with and inner class any method used is the
> parents consturctor cannont
> acces the Outer class.
>
> Of course I may be doing something stupid but I know the instance.super
> stuff and this is the referse case.
> It seems a bit pathalogical and also it compiles fine even though it
> will never run.
> The null pointer excetion if you access OuterClass.this is not exactly
> helpful either.
>
> Any thoughts ??
>
> Mike
>
> class Parent1 {
>
> public Parent1(){
> callFooBar();
> }
>
> public void callFooBar(){
> System.out.println(" Parent1 Foobar");
> }
>
> }
>
> public class OuterClass {
>
> class Parent2 extends Parent1 {
>
> public void callFooBar(){
> System.out.println(" Parent2 Foobar " +OuterClass.this);
> }
>
> }
>
> public OuterClass() {
>
> Parent2 p2 = new Parent2();
> }
>
> public static void main( String[] args ) {
> OuterClass test1 = new OuterClass();
>
> }
>
> }
>
> --
> 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: Possible Java Bug ?
The problem is that you can initialize the local var in the subclass in this
situation since you
have a handle to them but you cannot initialize the outer class instance viable
your self since you cannot get
a handle to it.
If you hand a instance variable
String myString
in the Parent2 class
You could initialize it like
public void callFooBar(){
myString="I set this "
...
}
I suspect this is what your referring too.
The bug is you have no way to init the outer class variable since even though it
exists
you don't have a handle Someone else mentioned that is is set in the byte code and
should be since the outer class is already initialized
so the JVM has a handle to its instance. But you don't have access to this since its
generated code.
I guess I wasn't clear on the Bug its not the initialization In my first post I said
I understood what was happening
but that they don't provide access to the outer class viable via a method call akin
to super.
InnerOuter.this = ?
I think Object should be enhcaned to provide acess to this viarlbe via
getOuterInstance()
This method would return null unless your and inner class.
So I think its a bug.
As far is to why I'm reporting it here. Well for political reasons.
Javasoft has this nice little disclaimer on there bug tracking page..
http://java.sun.com/cgi-bin/bugreport.cgi
Before you start:
This web page is for reporting bugs in products distributed on java.sun.com.
.
I find it a bit offensive that Sun is pushing NT on me.
But this is a diffrent issue so don't respond to my rant below.
Technically Linux users cannot even make bug reports or requests.
Even though I've accepted the "Open" SCL I'm excluded.
I don't care much for Sun's caste system even India is getting away from it.
It seems linux users are members of the new high tech untouchables caste as in
definition 2a.
>From Websters on nextstep snif ...
1:
one of the hereditary social classes in Hinduism that restrict the occupation of
their members and their association with the members of other castes
2a:
a division of society based on differences of wealth, inherited rank or privilege,
profession, or occupation
b:
the position conferred by caste standing
3:
a system of rigid social stratification characterized by hereditary status,
endogamy, and social barriers sanctioned by custom, law, or religion
4:
a specialized form (as the soldier or worker of an ant) of a polymorphic social
insect that carries out a particular function in the colony
Mike
Not a political bone in my body : )
Rick Kiss wrote:
> Hi Michael,
>
> I suppose the other folks that didn't respond were, rightly, concerned that the
> question is not a Linux-Java issue but I will try to addess it anyway since you
> brought it back up.
>
> Your example, if I remember right from when I took the Java Certification test
> last year, is a varient of a question on the test. If you built a slightly more
> extended test you would have noticed that your call to "callFooBar()" in Parent2
> from Parent1 occured before Parent2 was initialized. This means you were trying
> to talk to "InnerOuter.this" before the inner class had an initialized pointer to
> it.
>
> This isn't a bug but part of the language spec. Since it will always be there one
> has to plan for constructor issues like it.
>
> I suspect that language design issues fit better in Java programmer groups.
>
> Have fun,
>
> Rick Kiss
>
> Slightly more informative example.
>
> class Parent1 {
>
> public Parent1(){
> callFooBar();
> }
>
> public void callFooBar(){
> System.out.println(" Parent1 callFoobar");
> }
> }
>
> public class InnerOuter {
>
> // Inner class
> class Parent2 extends Parent1 {
> public Parent2() {
> callFooBar();
> }
>
> public void callFooBar(){
> System.out.println("Parent2 callFooBar - - - " + this);
>
> try {
> System.out.println(" Parent2 Foobar " + InnerOuter.this);
> } catch (Exception e) {
> System.out.println(" Parent2 Foobar " + e);
> }
> if (InnerOuter.this == null)
> System.out.println(" InnerOuter.this == null - class not
> initialized");
> else
> testOut(this);
> }
> }
>
> public InnerOuter() {
> testOut(this);
> Parent2 p2 = new Parent2();
> }
>
> public void testOut(Object ob) {
>System.out.println("TEST OUT: "+ob);
> }
Re: Swing never waits?
Nathan Meyers wrote: > Ted Neward wrote: > > Because Swing is a fully lightweight library, it can't rely on any of the > > operating-system-specific constructs underneath the JVM to more efficiently > > make use of the CPU. Instead, it spins off a daemon thread to (basically) > > poll the OS for the mouse position and information and broadcast that > > information to the Swing JComponents under the mouse pointer at that > > moment. > > This sounds suspicious. Is this conjecture or based on analyzing the Swing code? > There's always an AWT window under a top-level Swing window, and I would expect > Swing to be using AWT events to be tracking input devices. > > Not that there aren't a lot of CPU-sucking details buried in Swing (or > lightweight components in general)... I just question whether this is one of > them. > As a member of the unfortunate cwrod who spends his life in the bowles of swing I can say this is not true. What is probaly happing is there is some code in the demo which responds to and event and then generates and event ... It may be the blinking text cursor but mine never shows up anyway and I think its on a timer. But I do see a lot of gui code wich generates event loops by accident. And I write my own share : ) Often when I've had a gui app eat cpu sitting thre its becuase of a event loop. I wish java soft would provide a simple debug switch for the EventLoop heres what I do take the instance and event class as args Toolkit.getDefaultToolkit().getSystemEventQueue().debug( myFrame, MouseEvent.class ); //add more agres if needed like a type for mouse etc You coud do it external using peekEvent but I'm lazy. I just add it to a working copy. The nice thing is when I move out of debug nothing compiles till I remove or comment out the debug code keeps it out of production. You can figure out what debug does. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Call To Action on Java Lobby
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. I urge all the members of this list to look at the request and join the Java Lobby in its efforts. The linux java platform has to date moved forward slowly this is your chance to voice your concerns. And guarantee and open standard java. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call To Action on Java Lobby
Hamdi Mohd Yusof wrote: > Sorry, but I don't quite understand what is needed here. What is the action that > JL members should take? If it's about voting on JL issues, that I do quite > often. If it's more than that, then what is it actually? > > hamdi I think the actual action depend on Sun. The most basic would be to be able to submit proposals to Sun concerning the future of the Java language. Personally I'd love to the the Java lobby responsible for Java along the same lines as the Mozilla organization with Sun employees initially responsible for java but the maintainence slowly turned over to responsible groups. Sun can still maintain its veto power over the java language. But there whole Java Community process would migrate under the control of the Java Lobby. This is what I would personally like to see but I do know that the java lobby has my best interests at heart. And I would be very happy to see and organization of Java programmers in control of Java as apposed to any Company. If you see a different solution to secure java's future and WORA ( I tend to be a bit of a radical ) then join the java lobby and make your voice heard as it decided exactly what its going to do. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call To Action on Java Lobby
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. Your assuming the two process are mutually exclusive when in fact there highly synergistic. > > > Once a complete, robust open source clean room VM is > available and competitive on many platforms, the rules > will change anyway. Commercial products will have to be > better, and developer's will always have that fallback. Not if Sun block's them in court because they don't meet the Sun controlled java standard. Sun does have a track record. I could see them protecting us from the scourge of uncertified free JVM's. > > > Sun's interests are different. No amount of lobbying will > change that, it's part of the business. In the end, it is > the code, not the petition, that makes the difference. The java lobby represents and organization which can collectively represent the needs of the individual. This is called a Union in other industries. This helps Sun by providing a single point of contact with developers. Also Sun envisions some sort of Java Community I think the Java Lobby membership represents the Java Community. Assuming Suns vision is not strictly a coalition of companies. To date the individual developer has had no route to get his/here voice heard Java Lobby provides this route. Sun can via and simple acknowledgment of the java lobby hear and respond to developers. This is a lot better mechanism than random usenet postings and the bug parade IMHO. You are also assuming that Sun will not listen I think we both will have to wait and see. > > > If there is no consolidation of Java's core (language, VM, > compiler, core classes, JNI, JVMDI), then a good deal of > its future might well be virtually non-existent anyway. > >b. Well first you say we should not work with Sun then you predict that fragmentation of the java language will dilute it. Your last statement is correct. Thus just working on the free VM implementation's will fragment java as surley as Microsoft's attack. For java to succeed its best that Sun and the Open Source community work together on a unified java. This opens java up to be implemented on any platform using a standard code base and does not fragment java. In the case of java the lack of coordination between the Open Source community and Sun is not a good for java. I think the Java Lobby provides a group which can allow Sun and the Open Source community to work together. I certainly do not see any way this can hurt java. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: position of java applications starting up.
Nelson Minar wrote: > >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? It may be in the spec but Java defaults to (0,0) if the bounds are not set. It happens in the java layer by default I'm pretty sure. If you want placemnt you will have to roll your own. Btw calling setBounds befor setVisible keeps the winow from showing at 0,0 before moving to Location. I think setLocation only works afte your visible Call frame.pack(); Dimension d = getSize(); int myX= ?? int myY= ?? setBounds( myX,myY,d.width,d.height); setVisible(true); Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Proposal: select ..
Per Widerlund wrote: > Michael Sinz wrote: > > MS> You may find out that it ends up being easier since you > MS> write your code to deal with one file and that one file > MS> only and just get multiple objects or different classes > MS> together to handle the whole combination. > > Yes, it is indeed a simple and elegant way to handle things, > but you waste a lot of precious resources. When you want to > handle hundreds of socket connections and must start up two > threads per connection you soon run into trouble. > > //Per Widerlund I think you should learn about some of the thread pools avialable. Java Worls www.javaworld.com hase and excellent article on thread pooling.Instead of a select call it would probably be better for the VMS to use native thread ppols internally instead of there current design. You could also emulate the select call if you wish using thread priorties. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sunwjit slows down JDK
Steve Byrne wrote: > Scott Murray <[EMAIL PROTECTED]> writes: > > > > > On Tue, 8 Jun 1999, Bob Cadenza wrote: > > > > [snip] > > > For images this is almost 5 times as slow in jdk1.2. You can even see > > > it, the benchmark even redraws itself noticably slow. > > > > You can chalk that difference up to the addition of Java2D in JDK 1.2. > > Check out the number 1 bug in Bug Parade, #4185726. Sadly, Sun seem to > > be dragging their heels on fixing this problem. > > Scott's right -- it's the integration of 2D that's causing the problem. I > don't know that "dragging the heels" is actually correct: I know they've > applied some very bright minds to the problem, and made quite a bit of > improvement (this was before 1.2 first came out), but that it was getting > harder and harder to find doable performance wins. I think that if I were to > design it, I'd try to make it so that if you weren't using any of the 2D > features, the overhead that you'd pay would be minimal, and only when you > started turning on matrix transformation or any of the other cool 2D effects > would you have to take a performance hit. > > Steve Well I think your only partially right. True java2D is everywhere but. Done correctly the rendering pipeline should have a small effect on aliased line drawing and solid fills. Plus trying to run two pipelines will be very very messy and end up hurting the performance of both. Second the root problem is if you want to run any sort of advanced graphics you need to have direct access to the frame buffer and any available acceleration. That the real problem it practically impossible to write a good high speed 2D graphics pipeline on top of "strait" X11. You should be using DGA for the backside of the pipeline. In the Sun sources they provide hooks for this but its not clear to me that there used I found no refrence to libsunwjdga.so in the 1.2v1 linux port. Until your running on DGA I would not even consider other options for java2D. I haven't looked at the latest release but I've pretty much given up on 1.2 on Linux. Maybe you can talk to Sun at Java One and get them to open up just a bit. Just being able to do a build off diffs would help a lot ! Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Something Special for Linux Developers on alphaWorks
Ulli Kortenkamp wrote: > Hi, > > I just got this announcement from IBM Alphaworks. Sounds > interesting. We should use the remaing time until Friday evening for > wild speculations, bets and guesses...: > > - > > Something special is being added for the > Linux Java Developers on alphaWorks > By the end of the day[left coast time] on Friday June 11th > alphaWorks will be releasing a technology that is very useful > and vary fast to the Linux developer community. I cant tell you > what it is right now without loosing my job, but believe me, it is > something excellent. > > http://www.alphaWorks.ibm.com/ > > - > > So, are they releasing the IBM VM for linux? Or VisualAge? Or both? > > -Ulli This is probably one of the meanest things that someone has ever ever done to me : ( If its the JVM party in the streets !!! I hope the word fast means it not the IDE it would be nice to have but a fast VM is more important now. Of course I don't see them porting there IDE without the VM either so maybe both. As my imagination runs wild IBM announces the JVM port to Linux under and Open Source License. Also there are numerous reports of strange meteorological events in Redmond Washington. These are reported to be related to a strange Solar eclipse occurring in California. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Swing Priority
BAZLEY Sebastian wrote: > In case anyone is interested, there is a useful description of such issues > in the O'Reilly book "Java Threads", chapter 6 "Java Thread Scheduling", > which discusses some popular scheduling implementations. > > A couple of suggestions (not tested): > > If you don't want to use MIN priority, you may be able to choose a priority > between MIN and NORM, if this is supported on your target system(s). > Unfortunately, although there are many different priorities in the JVM, > these may not all map onto different priorities in a real implementation. > [Indeed, even MIN and NORM may end up with effectively the same priority, > depending on the implementation.] > > Yield() does not guarantee that another thread will execute; it may be that > the next eligible thread is the one that is yielding. But if you can > sprinkle more yield() calls around your code you may get what you want... Umm if you need to control threads the same book also gives a way to make your own thread sheadular using a high priority thread to scheduale wich thread runs next. If its important to ou I would go this route. Note though that some platforms do indeed not have any notion of thread priority. I believe the Mac platform does not really support thread priorities. At that point I would suggest running the complex calculation in a diffrent process and using rmi or pipes to communicate. I would consider redesing your app into a client server style application just on general principals alone with 1.2 the rmi overhead can be removed if your in the same VM. Also as far as I'm concerned the whole lack of specification on thread behavior is a real probelm with the Java specification. The lack of cross thread exceptions ( signals ) is a real bummer. Java's exception handling mechanism has no understanding of threads. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoClassDefFoundError... argh!
Dustin Lang wrote: > Hi, > > An ammendment to my original post: > > The ClassNotFoundException is successfully caught and execution continues > (same as it would if a really nonexistant class name was given in the > config file), but immediately after it comes the error everyone loves, > Umm I find that I will get htis error for a class when a class it derives on is not present. Thus if you dervie JFrame and dont have swing in your path you get and error saying your class is not found arrgh. Are all the super classes accessible ??? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Segmentation Fault and 1024-bit reselotion?
Nathan Meyers wrote:
> Rob Clark wrote:
> >
> > For what it is worth, I see the same problem under xfree86 at 16bpp,
> > so I am not sure that it is an Xvnc problem.
> >
> > What is involved in adding support for new color depths? I would like
> > to drop support for older versions of JDK for an application that I am
> > developing that I would be willing to volunteer to help, if possible.
>
> If you can solve your immediate problems by running your X server in an
> 8-bit mode, do it.
>
> The JDK is not open source, and you'll need to jump through some hoops
> to contribute to the Blackdown port. If it's really, really important to
> your work that you fix the JDK, be prepared to dive into Java2D code
> that is, I'm sure, nice and hairy.
>
Well I did and extensive review of Java2D and yes its very hairy.
There are mutiple pipelines and its not very clear to me at least which one
gets
used when. Plus the are many cases where there is way to many object getting
created.
I think the Java2D implementation illustrates a basic weakness with the java
language
how do you operate on a "primitive" type such as color wich can be defined many
diffrent ways.
If the java language had the ability to define new primitive types based on the
current ones then
I think it would be much easier to implement Java2D.
If you could even just transform and array of ints into a array of bytes and
vice versa then it would be great!
Classes like this should compile in java.
public class byteInt[] extends int[] {
/**
* Provides a view of a int array as and array of bytes
* data is shared between int and byte view
**/
native byte[] asByteArray();
}
byteInt[] myInts = new byteInt[10];
byte[] myByte = myInts.asByteArray(); // views a byteInt as a byte array
"big endian"
You can do this by shifting and copying but its very inefficient. There are
many more "Array" operations needed for graphics that
there missing or impossible to implement efficiently directly in the java
language.
Some of these issues could be fixed by special optimizations for loops wich
perform operations on primitive data.
There is no reason such loops cannot run at native speeds.
Mike
But once you get through how it works adding yet another bit depth is not that
hard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working with many .java files jikes Compiler
> > 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. ) Using production rules, make will only compile a java file > when the timestamp on the .java file is later than the timestamp on the > .class. > I compiled some code with jikes ans a normally do then with thek jdk1.2 compilier I noticed that the code ran visibly faster with javac has anyone else seen this ?? It seems javac is a much better optimizing compiler. I like jikes for development but javac seems to be a better production compiler Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dead lock in Graphics setFont
Hi I'm dead locking in Graphics on a call to setFont It enters g.setFont and never ruturns theu funny thing is it succeeds many times and this is the only thread in the setFont call ?? I synchronized on the graphics but no luck. java version "1.1.7B" Good call 0 SET FONT CALLED java.awt.Font[family=Dialog,name=Dialog,style=bold,size=12] g=SwingGraphics(0x80ce783) [subGraphics sun.awt.motif.X11Graphics translate [x=0,y=0] clip [x=0,y=0,w=498,h=30] color [r=128,g=128,b=128] font [family=Dialog,name=Dialog,style=plain,size=12]] ENDk FONT CALLED bad CALL 0 SET FONT CALLED java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12] g=SwingGraphics(0x80cd79e) [subGraphics sun.awt.motif.X11Graphics translate [x=0,y=0] clip [x=0,y=0,w=498,h=30] color [r=0,g=0,b=0] font [family=Dialog,name=Dialog,style=plain,size=12]] Nothing ??? SwingGraphics just sets the Font and a instance var I looked. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dead lock in Graphics setFont
Michael Emmel wrote:
Well I figured it out. Swing was handing out the same native graphics context
twice.
It look like theres a race condition in Swing Graphics wich allows it
to hand out the same native graphics context twice in a threaded enviroment
The pain is it results in deadlocks when two threads are using the same
graphics context and
one calls dispose.
>From looking at SwingGraphics I'd say the bug is in there init method and
dispose.
One they should call creat and two they should lock acess between dispose and
init.
I think even more needs to be done but I personally dont like the whole shared
graphics design.
This whole method is not thread safe.
void init(Graphics g) {
if (g instanceof SwingGraphics) {
/* Clone an existing SwingGraphics object. The dispose method
* must be called to reset the shared sub-graphics object to
* the same state it was in when cloned. */
SwingGraphics sg = (SwingGraphics)g;
originalGraphics = sg.originalGraphics;
graphics = sg.graphics; // MIKE this should at least be
graphics=sg.graphics.create()
previous = sg;
If you some how let a two threads access a SwingGraphics object they share a
refrence to the
underlying native thread object. Which results in some intresting graphics or
in the case of dispose
deadlock..
The real bummer was if I turned on the debugger it never happens : (
Also something else I noticed I dont think clear rect works correctly for
lightweight components
Since it clears the rectangle and fills it with the background of the Native
component.
Thus if the lightweight component has a different background color from its
parent then trouble.
import java.awt.*;
import javax.swing.*;
public class JPanelTest extends JPanel
JPanelTest( String name ) {
super();
}
public static void main( String[] args ) {
try {
JFrame ff = new JFrame(" HELLO WORLD 2");
ff.setBounds(0,0,300,300);
ff.setResizable(true);
JPanelTest dis2 = new JPanelTest("Panel2");
// NOTE RED BACKGROUND
dis2.setBackground(Color.red);
ff.getContentPane().add(dis2);
ff.setVisible(true);
} catch ( Exception e) {
System.out.println(" ERROR:"+ e);
e.printStackTrace();
}
}
public void paint(Graphics g) {
super.paint(g);
// Should clear to red
g.clearRect(0,0,getWidth(),getHeight());
}
> Hi I'm dead locking in Graphics on a call to setFont
>
> It enters g.setFont and never ruturns theu funny thing is it succeeds
> many times and this is
> the only thread in the setFont call ?? I synchronized on the graphics
> but no luck.
>
> java version "1.1.7B"
>
> Good call
>
> 0 SET FONT CALLED
> java.awt.Font[family=Dialog,name=Dialog,style=bold,size=12]
> g=SwingGraphics(0x80ce783) [subGraphics sun.awt.motif.X11Graphics
>translate [x=0,y=0] clip [x=0,y=0,w=498,h=30]
>color [r=128,g=128,b=128] font
> [family=Dialog,name=Dialog,style=plain,size=12]]
> ENDk FONT CALLED
>
> bad CALL
> 0 SET FONT CALLED
> java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> g=SwingGraphics(0x80cd79e) [subGraphics sun.awt.motif.X11Graphics
>translate [x=0,y=0] clip [x=0,y=0,w=498,h=30]
>color [r=0,g=0,b=0] font
> [family=Dialog,name=Dialog,style=plain,size=12]]
>
> Nothing ???
>
> SwingGraphics just sets the Font and a instance var I looked.
>
> Mike
>
> --
> 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: Food for thought...
Mike Christiansen wrote: > Riyad Kalla wrote: > > > These are good points.. and I think the reason Sun doesn't support Linux so readily > > is simply because it would be shooting its self right in the Solaris-Foot. If it > > provides a high performance, solaris quality Java implementation... they may loose > > a bit of business. I don't know details of course about this, but that seemed the > > most readily availble answer. > > > > I don't think that Linux competes with Solaris in the server market. (at least not in > the short-term). I think that Linux will hurt NT far-far more. If anything, a Linux > application server that outgrows its platform is likely to migrate to the "big iron" > unixes, and with the Java connection, Solaris would be a natural progression. > > > > > Anyone else have input on this? > > > > Well Sun is the Company that cam up with the SCL so ... >From the perspective of the SCL Sun is bending over backwards to support the Blackdown port. It's us poor miserble Open Source guys who won't support and SCL product. I don't know. It seems the Linux Wave is going righ over Suns head. I always thought the java/linux connection was a no brainer. Maybe this is the downside to a company controlling a "vital" technology. If the requirements of a failry large group of users is not considered important. Tough. I suspect a very large percentage of Java developers use Linux workstations for development. But theres been no survey to my knowledge. There is no way to know Suns answers to these questions. I don't think there that Redmonian it's just Sun doesnt get Linux or Open Source from what I can tell. And with Baratz leaving it may be a long long time before Sun tackles any Java/Linux issues. Bummer. Personally long term I'm waiting for the Classpath group to get there stuff working. If I was to contribute to a project it would be classpath but I feel "tainted" by the SCL. I want that project as clean room as possible. Since I plan on switching to Classpath once its ready I'll simply stay out of porting for now. The bummer is it's starting to look like at least a year before something happens good for Java/Linux unless IBM keeps coming through for us. I think IBM is the best hope for Java/Linux today. Even though I love programming Java the current Java/Linux situation is probably the biggest failure of the promise of Java today. Having to suggest NT for java deployment really hurts somehow deep inside : ( BTW Gnome really mucks up Frame positions for java. setBounds fails to move a frame. At least for me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Food for thought...
Jacob Nikom wrote: > I have feeling that for Sun Java is more important than Solaris. > IMHO they are targeting quickly growing embedded market to sell > more of their hardware. This market is good place for Java and > Linux, not Solaris. > > A lot of embedded and "real-time" software developers are looking > into Linux+Java combinations to develop Intel-based systems. With > Intel you have only choice between Windows and Linux (sorry, forgot > OS/2). However with Windows you have very little control what is > going on in the system and hardware-closed programmer hate it. > > I think IBM prefers to run Linux, not Windows on their Intel and > non-Intel hardware. Intel is another interesting player in Linux+Java > combination. They developed JMF1.0 and look at Java favorably. They > run Linux on Merced and they have $250M fund for software development > for Merced. Currently they don't have too many applicants. > > Jacob Nikom Umm good points ! Running Java on merced will probbably be a big pain although I feel theres room on the merced die for one more instruction set decoder : ) VLIW and Java bytecode makes for and intersting combination. But I think any attempt to get a commecial sponser for the JDK for linux runs into problems with the SCL. I think a lot of compaines would be willing to contribute but I'm not sure they would want to follow the SCL any more than the Open Source Movement. Since they are prevented from sharing any work until it passes the JCK. The SCL to my understanding does not allow technology transfer between SCL licensee's. If we could get a sponser it makes more sense to follow a clean room design. Maybe with redhats millions from the IPO they could sponser the www.classpath.org to get and open class libarary and IBM and Intel could write the JVM. Japhar has a pretty good plugin api. If they use that we could "plugin " the JVM of our choosing. And open source one for hacking and hopefully some day production. A commercial one for deployment today. By splitting the JVM from the class libraries via a portable interface we gain a lot ! I think if development was split between multiple JVM's and a open robust class library we could get competative support from comercial and Open Source vendors. This would be good for everybody... Offhand I'd say 99% of Java bugs are in the Class libraries. About 30% of performance issues are in the CLass Libraries except for the AWT which contributes a 80% performance hit. Thus open class libaries would allow work on the biggest performance problem the AWT. If we have a stable good set of Class libraries with and open porting api then I think Linux will have as many good JVM's as X Window Managers : ) On the Sun side they should be able to certify the JVM and the class libraries via seperate JCK tests. Theres no reason they could not exercise a JVM via its plugin api. The JVM test suite at least if done correctly should not require a 20K set up fee. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Food for thought...
SHUDO Kazuyuki wrote: > Michael Emmel <[EMAIL PROTECTED]> wrote: > > > By splitting the JVM from the class libraries via a portable interface we gain >a lot ! > > I think if development was split between multiple JVM's and a open robust class >library > > we could get competative support from comercial and Open Source vendors. > > Even Sun seems to make their class libraries > (i.e. classes.zip) more portable by reducing native > methods. > > One of evidences of that is in source code of the object > serializer. In early JDKs, serialization routines for > array of primitive types were native methods. But now > those routines are entirely written in Java. I guess > that the purpose of the rewrite was improvement of > portability of the class library. > > If we decide to develop a JVM or a > Java-to-another-language translator, we must implement > native methods in a class library that we adopt. It is a > very hard work. That's part of the problem the class libraries extend the JVM via native code. Thus the JVM in itself is not enough to run java. In my opinion any native libraries should used should expose an well defined java interface to the the native libraries along with a JNI style C interface. I'm not the worlds best C programmer but Sun's JVM is not written in a portable manner IMHO. I think its important to move to a design which allows each part of the JDK to be tested as and individual unit. Each major subsystem should be individually certifiable. Thus you should be able to certify a JVM the Porting layer api for the classes and you class library itself. I think its funny that Sun has come up with this cool OO design and yet not be able to certify each module as meeting the specs. Tons of C code is written every year with well defined dependencies and porting requirements. Mozilla has pretty decent api and there are many others. X11 does a prety decent job in there sample server. Since Sun seems to be commited to WORA meaning Solaris and Windows its hard to move the JDK spec forward to give detailed subsystem level requirments. I think that its crazy for Sun to think that by publishing a high level api theres any chance that clean romm implementation would be fully compatible on such a complex piece of software. Todays JVM implement JIT's and other dynamice compliation stratgies theres no reason that the JVM cannot optimze out C function lookup tables at runtime. The JVM should be capable of inlining C function calls and bypassing the function pointers once the tables are intialized. Optimizations should not and need not be limited to native code produced from byte code. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Background processes?
> > > > Dustin Lang wrote: > > > > > > Hi, > > > > > > Can anyone tell me if there is a way to Runtime.exec() a process that > > > lives longer than the Java process that spawns it? C example deleted And simple way is to call on Unix nohup procname & Works in all shell that I know of. NT I don't know. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Popup Trigger
What is the popup mouse event trigger under Linux I tried a few combos nothing would set the popup flag ??? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swing and syntax question
berry wrote:
> Hi,
>
> I was wondering if anyone knows what this following
> code means?
>
> public Rectangle getBounds() {
> return JFrame.this.getBounds();
> }
That sort of code is used in inner classes.
One of the swing programmers seems to make a habit of it.
If you have a lot of inner classes I guess its a bit cleaner to qualify this
when you use it. Otherwise it can be confusing if there are several inner
classes
in a Class.
>
>
> >From what I can understand it is making an infinate series
> of recursive calls. I find this kind of code all over Sun's
> source.
Umm no its just a 1.1 qualified this the class qualifier is optional out side
of inner classes.
>
>
> Another question:
>
> With Swing classes, at what point is native code actually
> called to do drwing . If you could tell me, I am wondering what classes it
> happens in and what is specifically happening. In 1.1 it would be
> the peer classes.
I know that one : )
swing uses
Canvas
Frame
Dialog
Window
The native peers are called there.
The native graphics object can draw all over the window.
It's fairly trivial to get a lightweight component to
draw outside of its bounds or over its sub components.
At least is the current JVM. I consider it something of
a security hole.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swing and syntax question
berry wrote: > > > Another question: > > > > > > With Swing classes, at what point is native code actually > > > called to do drwing . If you could tell me, I am wondering what classes > it > > > happens in and what is specifically happening. In 1.1 it would be > > > the peer classes. > > > > I know that one : ) > > swing uses > > Canvas > > Frame > > Dialog > > Window > > The native peers are called there. > > > > I thought that the whole point of swing was that there were not any peers. Well you have to get access to the screen some where. Sun's swing implementation is integrated with the native system in the above AWT classes and through that there native peers. You have to access the native display or Windowing system somewhere. There are of course other ways to do it here was my approach. First I redid the AWT peers to use swing. After this I wrote several types of drivers one on the hardware one using a java Xlib client. And one running on top of the original AWT for access to Frame's and windows. For hardwareI got the native code down to a two hundred lines of c and assembler to allow java video drivers to work. For the mouse and keyboard you need irq support and would have to have a jvm running in kernel mode : ( I did write pseudo java drivers using kernel message queues. Works fine for slow devices. Linux tty drivers used to be butt ugly but I think there better now. I haven't done any work to port the low level stuff to the new driver api's in Linux 2.2. I'll hopefully do that before Christmas. But I want to get my vi in java project done first before I go full screen java agian. I just doing command line and vi key bindings for jEdit ad running it without the fancy menu bars as a shell. I did not like having to telnet to run the native vi. You would think Bill Joy would get vi going in java I think he wrote it originally : ) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java and Enlightenment
Peter Graves wrote: > The authors of the Enlightenment window manager have some > interesting comments today about Java: > > http://www.enlightenment.org/news.html > > Their basic point is that "Java under X (AWT) is Broken"; they > don't mention which Java implementation they're referring to. > > I don't think things are all that bad with either version of the > Blackdown port (or with the new IBM 1.1.8 implementation either, > for that matter), but I have noticed that dialogs (in particular) > tend to drift a bit under various window managers, even though > there's explicit code in the application to save and restore > their position. Both Enlightenment and Windowmaker seem to have > this problem, but icewm, last time I checked, did not. Windows > VMs don't seem to have this problem at all. > Actually java works well under KDE some bugs under Windowmaker major bugs under Enlightenment . Gnome seems to break stuff too. I wont except bug reports for linux unless there verified under KDE. Also java works under all the other Unixes Sun/SGI/HP that I've tested. I'd say its Enlightenment plus Gnome does not help. If your the only badly busted platfrom it aint X. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java and Enlightenment
Ron Yorston wrote: > Michael Emmel wrote: > > >Peter Graves wrote: > > > >> The authors of the Enlightenment window manager have some > >> interesting comments today about Java: > >> > >> http://www.enlightenment.org/news.html > >> > >> Their basic point is that "Java under X (AWT) is Broken"; they > >> don't mention which Java implementation they're referring to. > >> > [snip] > > > >Actually java works well under KDE some bugs under Windowmaker major bugs > >under Enlightenment . > >Gnome seems to break stuff too. > >I wont except bug reports for linux unless there verified under KDE. > > This is the sort of unhelpful attitude we've been seeing from Sun as well: > so long as things work under CDE there isn't a problem. Well, there is a > problem. People use window managers other than KDE and CDE and Java > applications don't work the same way as other applications under, say, fvwm. > > It's my understanding that the fundamental problem is as described in the > Enlightenment comments: Sun have made a (IMHO bad) design decision that > Java will attempt to subsume some of the functions of the window manager. > This requires Java to have much more knowledge about things like window > manager decorations than is reasonable to expect. Now your getting to the real problem. What gets me mad is Java application developers are caught in the crossfire of a pissing contest between Sun and X11 window manager developers. Instead of pointing fingers how about this. The Enlightenment team offers to work with classpath to provide a powerful open set of bindings for X11 window managers/ XServers these binding classes will at the minimum support implementing Java AWT Frame and Window peers using only there java api. Also enough support to implement various types of even filters for modal dialogs. At the minimum is would be really cool if the api allowed me to get a undecorated window with full keyboard and mouse support this would allow developement of Java desktops which work with the WindowManager and X applications. Other cool features would be support for "clear" windows alpha support would be even better were possible. These need not be the peers themselves. Hopefully this solution will be written on xlib and be highly portable but the only important part is the api guarantees a standard set of bindings. Now instead of Java VM developers having to create a compliant implementation. The burden is placed on the Window Manager developers. All they must provide is a set of classes and maybe a shared library. Here is a xlib implementation all in java http://www.cs.umb.edu/~eugene/XTC/ Plus there is The gnu classpath project japhar and kaffe. Thus there is plenty of open source code out there which can be used to implement such a library. It may even be best to put the java bindings inside the Xlib implementations. this would require the cooperation of a much smaller set of X Server developers. My point is I think the best solution for java and X would be to provide a set of low level java bindings with the Window Manager and or X11 server. The core library should be clean and simple and be enough to support the standard AWT cool extensions should be kept in other jars and shared libraries. Thus we have viable proactive open source solution to the X/Java problem instead of sitting around waiting for Sun. So to me the burden of java support under X should be upon the Window Manager and maybe the X server developers since they can provide the best java bindings for X. This is not the attitude taken by the Enlightenment teams answer to to issues with java. Instead they treat java as just another X application instead of trying to provide the best support for java.To me this means java bindings. Especially when you look at good support for Java2D which really needs OpenGL style support. I'm sure the blackdown guys would be amenable to such a solution and Sun would should be open to a set of standard low level windowing api's for java on X. Since these api's are for "porting" the JVM there development can be far more flexible. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Const in java
[EMAIL PROTECTED] wrote:
> On Wed, 13 Oct 1999, Robert Simmons wrote:
>
> > Since everything in java is passed by reference this becomes even more of an issue.
> > Therefore can I do the following to achieve the desired safety ?
>
> Well, everything is not passed by reference in Java. I believe primitives
> and immutable types are passed by value. Someone know the exact rules
> behind this? I always have to write a little test program to remember.
> Okay, I'll stop being pedantic.
>
> I think if you do
>
> public void myFunction(final SomeClass var) {
> .. whatever ..
> }
>
> Will do what you desire. Not positive though so some of the other wiser
> folks on the list might wish to confirm this.
Well that wont compile.
In reality const is just one form of programing by contract which java does not support
directly
to date.
Since reference arguments are passed as a reference copy in java you cant change a
reference.
example
public void foo( Object obj ) {
obj =foobar;
}
Has no effect on the external pointer obj;
Pointers in java are passed also by copy .
To simulate a pointer in java you need
public void foo( Object[] obj ) {
obj [0]=foobar;
}
Thus a pointer is really a index into a array which is gasp the same thing it is in C.
The only thing you don't know in java is you absolute address from the true offset in
memory.
JNI allows pinning if Java allowed you to pin the address of and array and allow byte[]
int[] etc to point to the same memory regions. And allow you to subclass say int[]
99.999% of the reasons to use C are gone.
The only reason you can't cast a int[] to byte[] is because java is big endian and
intel is little : (
Why you can't subclass int[] or byte[] I don't know.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Const in java
> > > Such is the problem there are times where I dont want the user to be able > to alter a returned object's state. > Thats easy just add a lock variable that take the ( Caller) as a prameter to set. Or its not public. Check that on each method invoction which effects state. I'm not sure of the utility of having and object wich no methods can be called on. This is nothing more than a more generic form of thread synchronization. In fact a quick and dirty way to do it is to grab the thread lock for the object in a method that never returns. i.e block on and I/O that never finishes. Or simpler force a deadlock. This will deadlock the calling thread forever though so it is very rude : ) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux JVMs
som ranting near the end but do not compile shipping code with jikes. Also do not make IBM slow jikes down for shipping code : ) Michael Sinz wrote: > On Tue, 19 Oct 1999 00:03:18 +0200, Ian Corner wrote: > > >You mentioned in a previous email the ibmjdk, is that Jikes? If not what is > >Jikes as I thought that was the IBM JVM. Do you happen to know what Java > >version Jikes is comparable to? > > Jikes is the IBM Research Java Compiler. It is *very* fast at compiling > Java Source Code into Java Byte Code. It also is very strict to the > Java Specification (or as strict as possible since the spec is not 100%) Also it produces the slowest bytecode on the planet. Great for development. And keep it that way. FAST. But it would be nice if someone besides Sun produced a killer but slow super optimizer compiler that was 100% java. Let it run all night who cares. > > > The IBM JVM (Java Virtual Machine) is a JVM just like the Blackdown port > of the JDK is a JVM. The IBM one is available at the alphaworks web > site from IBM. > > The IBM JVM is one of the fastest out there (if not the fastest) and > it has some rather nice technologies such as the better GC and a very > good JIT. Very very cool how is IBM on moving to and Open Source Model for there VM's In the long run JVM technology will change in step with hardware so the long term IP of JVM is practically nil. Fast java ---> fast java silicon. How man people are want for the next version of a particular C compiler ?? Or Objective-C /C++/Smalltalk run time ? A cool thing is the average differences between java technologies is getting much much better. Most are running the same order of magnitude which is very good 2X not 50X slower. Sun tends to forget about the critical importance of consistent performance for WORA. Good fast predictable performance of java on all platforms beats MS. Sun in particular has no clue. IBM does but there not open. If java runs the same and fast every where who needs MS ? This its jit vs no it. 4 years from now nobody will give a *** about jvm's just hardware support. The class libraries are a different story They can be optimized forever since its a design issue. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Partially OT] A Java parser - part 2
Kontorotsui wrote:
> Hello,
> first of all many thanks to all the people who kindly answered.
>
> I've collected many different advices on Java parsers, so maybe it is wiser to
> explain my purpose.
> I noticed that java performance decreases dramatically as more and more classes
> and object instances are created.
>
> From:
>
> class one
> {
> int number = 0
>
> void aMethod()
> {
>number++;
> }
> }
>
> To:
>
> class two
> {
>myInt number;
>
>void aMethod()
> {
> number.increase();
> }
> }
>
> class myInt
> {
> int n = 0;
>
> void increase()
> {
> n++;
> }
> }
>
> There is no semanthic difference, but if you call aMethod() many times (say
> 1) the second version is even twice slower.
>
> Yet, the latter version takes advantage of modularity and object structure,
> "good" coding implies that kind of structure.
>
> What I want to do is a tool that "flattens" the class hierachy to improve
> performance. In this way I'll be able to write properly structured code but the
> tool will cut away performance-wise useless classes and method before I compile.
> I know it is not always possible to do that and that the rules to change the
> program must always keep semanthic unchanged... I know this is not easy.
> But suppose I manage to write down a set of rules to do that, I'll need a parser
> to parse the Java code and provide the changed source code according to the
> rules.
>
> After I explained my goal, what would be the best parser to achieve it?
Well some work has been done there
check out
http://altair.parsecweb.com/~kbs/aboutjolt.html
A java to C translater in java .. ( it will I assume have to flatten the java .. )
Alos check out
http://www.geocities.com/SiliconValley/Orchard/5802/javago/ReadMe.htm
It already does what your wanting to do. Now it seems to break some things. I
havent played with it much.
Plus its in C-- : (
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Partially OT] A Java parser - part 2
Andreas Rueckert wrote: > Hi! > > On Thu, 18 Nov 1999 Paul Mclachlan wrote: > > > > >Having said that, if I wanted to do something like this, I would use > >JavaCC, or, specifically, the "jjtree" tool in JavaCC. jjtree will > >automatically parse the file into an OO structure ready for manipulation. > >(ie, you might set it up to create a "class object", a "method object", and > >a 'methodcall' object, among other things. You could then use this like > >any other tree. This will probably automate something you would have done > >anyway. > > I've used JJTree a while ago and had some problems. It started with the simple > fact, that the Java grammar and all derived work was copyrighted by Metamata, > so I couldn't include it in my work. Make sure this copyright has changed, if > you want to share your work. I sent and email to metamata regarding Open Sourcing JavaCC. Originally the argumnet for closed souce was okay for devlopment but the tool is very stable now. Maybe they will. If not I too will move to antlr. Maybe otheres intersted in JavaCC could get them to come too a decision on Open Source for JavaCC. I'd like to know. I rather use javaCC but only as Open Source. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Partially OT] A Java parser - part 2
Vincent Risi wrote: > Andreas Rueckert wrote: > > > Hi! > > > > On Thu, 18 Nov 1999 Paul Mclachlan wrote: > > > > The next problem occured when I wanted 2 parsers to use the same base classes > > for the AST. Never managed to do that, and I couldn't patch JavaCC, since there > > were no sources available. > > TLA's are fine if you know what they stand for, what is AST? Abstract Syntax Tree : ) Whats a TLA ? Umm yes I was looking at antltr it allows sub classing. It looks like I like the power of antlr and the syntax of Javacc : ) It should not be too hard to write a Javacc--> antlr preprocessor. Then antlr can accept Javacc grammers ... Anyone intrested What would be really nice god forbid is if there was some sort of standard syntax for java parser and lexer generators. Life would be cool if you could publish a "standard" grammer. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
