Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Too bad it's written in Java.


Agreed. Not the language itself, but the way the runtime operates. One simply does not build reliable and fundamental abstractions over non-optimal enough abstractions and expect things to work long-term.


All the abstractions you build will eventually go over x86 bytecode instructions. And those aren't pretty, let me tell you.

The truth is that there is nothing important wrong with Java, and everything important wrong with Java programmers, which casues people like you to say things like that.


I guess you aren't aware of the dozens of 0-day exploits to the JVM that were released last year? Since Oracle took over, Java's security model is looking like Swiss cheese, Oracle's responsiveness to security flaws has been slow, and the fixes have introduced even more security flaws.

See here ( http://java-0day.com/ ) for some examples.


I am away against attacks against the java applet executor, not against Java itself.


The problems weren't with the Java Applet executor. They were with the JVM. Java WebStart and the JVM security model are the two places where most of the 0-day exploits came. Neither of these have anything to do with applets.


What are these magical "x86 bytecode instructions"? That phrasing itself means nothing. Are you sure you know what you are talking about?

I personally object by principle anything which is non-optimal by design because it means that everything built atop has to carry the penalties of the non-optimal design. Everyone suffers from the tradeoffs.


To be honest, this was the first thing I said when I saw the installing instruction.

Today's JVM are probably the fastest abstraction layer available, but still the programming language is not that beautiful.


how is this relevant to anything?


Despite what people say, I still don't think that Java has shaken the image of being bloated and slow and requiring a heavy VM and loads of RAM.


Currently running Freenet/Tor/I2P on a VM (KVM) with 1.5GB RAM allocated it. according to htop, java (Freenet and I2P) is using 985MB. Tor is using approximately 40MB.

The day someone takes up a rewrite of Freenet in C/C++ is the day I send money to the project.


Freenet by nature is an insane resource hog, that doesn't make the JVM look any better.


That's largely because the JVM still uses tons of memory and takes forever to boot.


I really like when I goto download some new app and see that there is a simple executable .jar I can get. They are still bloated and slow though.. just so happens that we have workstations with i7s and 32GB of RAM.

We finally caught up to where Java is reasonable, yay!


While Java may not be sexy nowadays, it's still tons better suited for the task at hand than Tor's choice of unsafe C.


People aren't always willing to sacrifice performance, ease of use, and beauty of software for the sake of using some secure web browser.


Although, as a Tor user, I sacrifice all of those each and every time I use Tor.


Tor is a C/C++ wrapper around Firefox. This is a Java Internet browser.


What do you mean when you say that Firefox is "a Java Internet browser"? Firefox wasn't written in Java. Java code only runs in Firefox through the use of the Java plugin, just like any other browser.


I meant to say Freenet is a Java browser, not Firefox.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: