The programming language is, most likely, not going to be the stumbling block. The JVM’s mandatory memory management may be a disadvantage in some performance-critical parts (e.g. memory hunger; but then, Java’s GC might actually be better at preventing memory leaks than anything you could roll yourself), and there are a few extra security concerns, but other than that, I see no obvious show stoppers.

However.

A web browser on the scale of Firefox or Chromium is a massive undertaking, and both projects have a huge body of experience behind them – Mozilla builds upon decades of browser building (and some famous failures), and Chrome/Chromium has both Google and Apple (a major force in the development of WebKit) behind it and absorbed a lot of knowledge and experience from KDE and other large rock-solid Open Source projects. Both additionally make use of dozens of battle-proven libraries, not only render engines, but all sorts of things. Vector graphics, font rendering, parsing, XML DOM Tree manipulation, networking, caching, cryptography, the list goes on and on, and you don’t want to reinvent all those wheels yourself, because they are hard to do and easy to get wrong.

In short, building an industry-strength web browser is pretty damn hard, and that’s the reason there is only a handful of success stories in this arena. The programming language has relatively little to do with it, although C and C++ are at an advantage, both technically and socially.

In theory, it could undoubtedly be done. From a practical viewpoint, however, it seems a bit more questionable. lobo isn’t even close to the first time it’s been tried. In fact, one of the early showcases of the superiority of Java was supposed to be the HotJava browser — which was going to change the world, and render the “Mosaic generation” browsers obsolete.

Of course, we all know pretty much the opposite is true: HotJava is dead, and was never really a serious competitor in the browser wars (in fact, if you search for “HotJava browser”, some of the top hits are for bug reports about how it didn’t work quite correctly, even for Sun’s own web apps).

Personally, I think wondering about whether it’s possible or practical is (mostly) looking and thinking in the wrong direction. The question is not whether Java carries such massive penalties for such a project to be impractical. The question is whether Java has enough advantages to justify such a project.

The simple fact is that webkit (to use your example) is a big, complex piece of code. Even if we assume that Java is so much more wonderful that we could do the same with, say, half the size and complexity, the result is still a pretty big, complex piece of code (likewise V8, etc.)

I think before duplicating that amount of work, most people would want a little more assurance than: “we think our product is likely to be fairly competitive.”

If you start from a set of user-visible features for a browser, and then try to determine the most efficient way to produce a browser with those features, “Java” probably won’t be part of that answer, except as part of “Javascript”. If history had worked out differently, there’s probably no reason it couldn’t (at least theoretically) be part of the answer, but given current circumstances, it isn’t.

Furthermore, I see very little likelihood of that changing. I can barely see it happening if Oracle (or possibly IBM) decided it was useful to maintain Java’s competitive stance vs. (for an obvious example) Microsoft .NET, but that seems doubtful unless .NET starts to threaten Java’s core market.

Outside of that, any set of features you can imagine (outside of “written in Pure Java” as a feature in itself) can almost certainly be achieved quicker and easier in other ways than by writing a browser entirely in Java.

I honestly believe that a dedicated, knowledgeable team could create a performant web browser in Java. The real question is, why? Having the browser written in a specific language is not really a feature. People will use Chrome because it is fast or Firefox because it is extensible, but they will not use JBrowser just because it happens to be written in Java. So the real question becomes, what problem are you trying to solve?

The next question, assuming you have a reason to write JBrowser is, “does using Java make the task easier or harder?” Google, when making Chrome, wrote it primarily in C/C++ despite the fact that they are a very pro-Java shop. It seems quite likely that they believed that the benefits of Java were not going to bring in a net gain on time.

With Nashorn (The Javascript on the JVM replacing Rhino) coming to the JVM as part of Java 8, this is eminently doable. However, as others have noted – there’s an awful lot to a modern web browser and it does just seem easier to embed WebKit if you need to host browsing capabilities within a Java app :-).

The current top answer is excellent. I’ll add, though, that one doesn’t need to totally recode something into Java. There are tools that convert native source to Java bytecodes with varying degrees of interoperability. They often create an interpreter of sorts or use a JVM-like representation such as MIPS as a stepping stone. One might break a Java browser development into many steps by converting key native libraries into Java bytecode, integrate them with pure Java browser source, and gradually implementing more library code as pure Java source.

This allows you to contain everything within the safer JVM. However, it will be a pain in the butt ensuring efficiency. There’s some precedent in gradually refactoring large, pre-Agile/OOP legacy applications. Plus, some of the components already have good Java implementations and those could be used too to reduce labor.

I have to say I’m a little biased here, but here I go. I don’t like the C/C++ preachers, I know there are some incredible good engineered applications out there but its just A tool, often I got the impression, many people only mentioning C/C++ for a solution miss more then A point (http://www.paulgraham.com/avg.html see bulb paradox).
I try to look at the facts: Java is as fast C/C++ but requires more memory therefore. Or let me rephrase you can write java code which is as fast as C/C++
but that program will consume more memory. I hope we can agree on this.

If you look at productivity, you can create java solutions for certain problems (say enterprise java) relatively easy, compared to C++ solutions.
A web browser is something completely different.
I see two/three mayor requirements:

• It has to conform to huge specifications, HTML, JavaScript, etc. This involves problems like 2D Drawing APIs. Or how do get from a OS system call (as a drawing primitive) to text or font representation (“rendering”). Have a look at libraries like cairo( C ) and other attempts like gezira (www.youtube.com/watch?v=P97O8osukZ0 , https://github.com/damelang/gezira )
• It has to “feel” fluent, which means certain operations only have ms to be executed.
• It has to form a UI Concept which form a unique experience, to compete in today’s ‘browser wars’ which is quite challenging.

To sum up: yes you could, you could create browsers in almost any programming language with nearly identical results compared today’s C++ steamships. But to do so you would need quite an extraordinary amount of effort. I don’t know how much ( in the millions) , I would not want to even guess at that. Maybe we could get this bottom line: people don’t like to optimize in high level languages, or maybe its cheaper to get people who like to optimize in C/C++ because there are so many (compared to other language experts who can optimize on a similar level).

About the feasibility of a Java web browser written in Java, maybe the wrong question was asked.

I see no need to re-invent the wheel and write a full-fledged browser when most of the existing ones are free and features rich.

That said what I (we?) should be looking for is “something” good enough to read web pages WITHOUT all the crap (re advertisements, videos, gifs) that gets piled on.

Google is the chief offender here with all their ads and such.

To address that I wrote a Java browser that uses the Java HTMLEditorKit with its HTML 3.2 implementation and reads a web page as text, strips all the javascript code, the style code, the links, the meta data (another source of irritation with its auto reload) and attempts to fix some special characters and image links set via javascripts. Hyperlinks and navigation work. For reading stuff like the LA Times, the NY Times, Il Corriere.it, ElPais.es, LeMonde.fr it delivers. Even Bing and Google searches come through. Eventually or when asked I will make it available for free. It is not much but it is a start.

It would be comparable to the concept in the Windows 9x days of running software OpenGL vs hardware-accelerated OpenGL. The problem with using Java for something like a web-browser is that you potentially use many extra clock-cycles to do something that may be possible in many-fewer in a more-native language. That was the concept with OpenGL as well – you could complete the task but it took much more processing to do it.

So, is it possible? Potentially. Would it be competitive? Unlikely – something in highly-optimized, platform-dependent code is likely going to have a significant speed advantage.

This is merely speculation though.

Sure it could be done.
And it would make sense too.
No browser supports the full w3c standards for unclear reasons.
On the part of css3 support the browser companies don’t support standards either.
-moz-* and -webkit-* will never be part of the standard.
So a full standards compliant browser should ignore them.
One of the biggest mistakes from w3c is the total lack of rendering specifications.
So the same standards compliant web page would look different in every browser, a graphical design nightmare.
Another w3c fail is the lack of speed.
5 years discussion and still only a draft standard for html5?
Then your organization is blocking any serious innovation.

I think we should ignore w3c, ignore their specs and make a community standard within a half year for a web application markup language WITH rendering specs and security in mind.
Remember HTML was never designed for web applications, because there were no web applications at the time sgml was used as the basis for HTML.