Slashdot Mirror
Jazilla Milestone 1 Released
mcbridematt writes "Many of the long time Slashdot readers will remember the Jazilla project to rewrite the Mozilla browser in Java. It went into hibernation in 2000 and I took it over last August. I have completely rewrote the browser which now follows a more Mozilla-like architecture. The Result: Jazilla Milestone 1 has been released. Download it from here. No prizes for guessing that it's Alpha software." Read on below for a list of what Jazilla can do, so far.
"Significant (implemented) features include:
- chrome:// support
- JavaScript implemented for the GUI thanks to the Mozilla.org Rhino engine. HTML Scripting coming.
- GUI in part, uses XUL and W3C DOM
- Written in 100% Java
- Open Source
- Uses the NetBrowser renderer, which is actually based on Jazilla-classic work."
Once you expand and extract this puppy, just cd into the folder it made and, assuming Java is properly installed on your machine, you need only run:
Good luck, and enjoy! The browser's still lacking in many obvious areas, but it does work on a lot of sites. Too cool -- props for all the hard wo\ rk. :-)
Java programs != Applets, I think you're getting the two mixed up.
Banaaaana!
Since half the comments so far seem to be "What is the point" I'll offer one justification.
There is still a serious lack of a good modern HTML browser for embeding in java applications. Swing provides an EditorKit which handles HTML3 reasonable well, but most of the other quality offerings are non free.
Major Java IDEs (Eclipse, NetBeans) have projects to implement something like this. Many other Java applications could potentially benefit. It's a good idea.
This means that when you go to the store to buy an application, you don't buy the "Mac version" or the "Microsoft Windows version." You buy the "Java technology version." And as long as you have the Java Virtual Machine--which is free, and available from a large number of vendors--you can buy the program without having to worry whether it's going to run on your particular computer.
Well I was able to start it with:
java org/jazilla/Jazilla
from the jazilla directory.
"You'll wonder why anybody uses Java at all."
Yes I sometimes wonder.
Java is not only a language for writing pretty
applets (which aren't the same as full applications
which run from the CLI) or just for platform independence. It is a language which has many good security features, makes coding things such as networking much easier, has a vast amount of existing code and is a language which is just generally safer to program in and more object-oriented. If there weren't other benefits to coding Java programs, why would compilers such as GCJ exist for compiling Java programs to native code? Also, the speed problems with Java are now far less as compiling on demand becomes more common in Java runtimes. Whereas a C program can cause a segfault in about five lines, major problems with Java are more likely to be due to the runtime, which can even be eliminated. Also, there is no reason that just because Mozilla is slow (mainly because the code has to do a lot of layering to make the platform-independence work) doesn't mean that a port has to be -- a port would take substantial work and even though the ideas are the same, the finished product won't include the same code and so doesn't have to be as slow!!!
Ok it was kinda a joke but I will address it more seriously this time.
1. Java is slow. This was true in 1.0 release of Java, but with todays JIT's the speed difference is small. I can point you to numerous sites, but at the end of the day it comes down to good coders. Your experience must be with some bad coders.
2. SWING is slow. This again use to be true with 1.18 + SWING and 1.2x JVM's the 1.3 and 1.4 have increased SWINGS speed considerably.
3. JAVA takes up too much memory. Yes it is true that the base JVM can take around 5-16MB of RAM per JVM instance. But with todays systems, on a lot of applications that isn't too bad. Now the core issue is that it takes up that amount for EVERY JVM that is used. So to your point: If I launch a Java calculator program, and then launch a Java notepad, I will have lost around 10-32MB of RAM in just JVM's. This is currently true, however it is being addressed and should be solved with the 1.5 release. Once this is done, then it would be possible to have ONE JVM running on the system for all Java applications. The JVM could launch at startup and then even the inital load times would be greatly reduced. I believe that this is the way Apple is handling Java (Can't confirm it though).
So, when this issue is resolved, running Java on a machine could mean only giving up a maximum amount of 16MB of RAM for the JVM and the rest for the application. To be honest that is what most Java programs are doing today. Most run as an application server and run Servlets and JSP's all day long.
Another poster mentioned that you use the correct tool for the job. I agree, but I will add that the issues for not using Java for speed has and is going away. The reasons for not using it for memory are going away on most computers.
We do agree on one point. Most people do have computer processors far greater than they need.
Lastly, if you are having so many issues running Java apps on your system you should look at newer JVM's. They make a huge difference.
The more I learn about science, the more my faith in God increases.
Actually Java applets are programs - they are just programs that run inside of a web browser as opposed to on their own.
;)
Java applications != Java applets
Java applications = Java applets + Java applications
I think you're confusing them.
Also, applets run on the JVM just like applications do. The only difference is that the JVM is invoked by the browser (you can think of the JVM running inside the browser, but this isn't really true these days). So, his question is perfectly valid - does Jazilla start a JVM (to run applets you're browsing to)that runs on the JVM the browser itself is running on? Or does is start a seperate JVM? Good question - although I bet I can guess the answer...
Lunix is the well known linux derivative for everybody who was into computing in the (early) 80's, namely the C=64 and C=128.
A little googling might have done wonders for your post. ;-)
Zaaf
---
"Multiple exclamation marks are a sure sign of a sick mind." (Terry Pratchett)
Hold on there skippy. Java applets ARE Java.
I think what our friend Exiler here is trying to say is that Javascript has nothing in common with Java except the name. And if I'm to believe the person who told me, Javascript had a different name while it was being developed but Sun exerted sufficient pressure on the neccesary parties to change the name to sound like Java.
Quick recap:
Java Applications - Java
Java Applets - Java
Javascript - Not Java
I hope this helped.
I used to bulls-eye womp-rats in my pants
2) Java will always be slower than a native, non-interpreted language, even if you compile it into a binary.
Not true. First of all, Java is compiled, except it's compiled into byte-code instead of machine-code. This is unlike languages such as PHP and Perl, which must recompile the text source code into machine-code or byte-code each time it's run. While not as fast as machine-code in most cases, byte-code is definitely much faster than interpreted.
One advantage of byte-code to machine-code, in addition to portability, is that it can actually run faster in some cases. My friend did a project for his super-computing class in which he tested a simple algorithm written in both C++ and Java to see what would run faster. He used every level of gcc optimization, as well as a few JVM's. As expected, the compiled C++ version kicked the pants off of the Sun and Blackdown JVM's, but the IBM J9 JVM was around 50% faster than the C++ version. This speed advantage is due to the fact that IBM's JVM is able to optimize the code at runtime, while gcc must do all optimizations at compile-time.
Most people's misconceptions of Java are due to two factors: An incredibly shitty MS JVM and the horrid Swing GUI toolkit. When Sun wrote JWT and Swing, they tried to stick to the write-once, run-everywhere philosophy as much as possible. Unfortunately, the different OS's have very little in common when looking at GUI functions, so they basically had pixel capabilities to work with - no widgets. This means that the widgets are all done in Java instead of using libraries available from the host system. This is why most Java applications look nothing like the operating system they are running on, and run very slow. The SWT GUI toolkit, which is part of the Eclipse Project, uses the host system's libraries to render widgets wherever possible. This leads to an application that runs much faster and looks just like any other application for that operating system. Of course, they have to implement SWT for every host system they want to support, but it still runs on systems where support is incomplete/missing, albeit more like JWT/Swing.
The stock layout managers suck ass, but there are better ones out there. If you're doing GUIs in Swing, check out TableLayout, HIGLayout, FlexGridLayout. These are all free and Free. There are probably other ones out there too.
I've been using TableLayout and although there are some little things I don't like about it, it does let me code Swing GUIs without the pain associated with the stock layout managers. Haven't tried the other two yet but they look interesting.
In fact I am posting this from Dillo.
Links 2 is rather impressive as well, in that is handles Javascript now, and runs under DirectFB.
My system is a P166 laptop w/ 80MB of RAM. This is low-end by today's standards, and it will run Mozilla, but for 90% of my browsing Dillo is more than adequate.
It may be true that people now have much faster machines, but there is just no excuse, for, say, the performance of Mozilla with text-boxes and the Mail composer.
It is just unbelievably slow, not really slow, not goddamn slow, but really, truly, unbelievably slow.
How do you spend so many years writing an app and end up with performance like this?
I totally agree and think that Dillo has a bright future, If it runs this well on a P166 I am quite keen to use it when I get something faster.
You might also want to check out Links 2, it does graphics, and Javascript now, and runs under DirectFB too which is kind of neat..
> Swing layout is one of the reasons Java GUIs seam to be broken. If you resize a window, you get a lot of grey boxes. Sure, Mozilla could use some double buffering on their resizing, but it doesn't leave me with a gray screen instead of seeing how the components will look after resizing.
) ; // not availble before 1.4
There is a new method in 1.4, the programmer needs to call this method before creating any windows....
try
{
Toolkit.getDefaultToolkit().setDynamicLayout(true
}
catch (NoSuchMethodError e)
{
}
This will fix the problem...
No. I've never encountered an open source JVM that fully supports AWT - let alone Swing. So they are useless for most desktop apps.
Let me know if you find one...
Female Prison Rape in NY