Live data from Hacker News

Java for Everything

teamten.com

111–120 of 344 posts

Re: Java for Everything

#111
post #10

I cannot keep my sanity when I use dynamic languages in fairly big projects. I just cannot organize my code and all the functionality good. So, I looked at the options at Java and most of them looked either very complicated(Spring) or insufficient. I am developing a very simple framework, insipred from Sparkjava and Play Framework: https://github.com/mustafaakin/WebOM It basically maps either HTTP requests or Websock…

I'm starting to put together my own Java web framework to make things easier to get started quickly and borrowing ( heavily) from other language frameworks. https://github.com/bluedevil2k/Jiffy

Try checking out Ninja Framework. It's pretty decent.

Re: Java for Everything

#112
post #71

Having literally deciding to learn java last week for no particular purpose other than having enough understanding to be able to comprehend our software (which is written primarily in java) and prevent brain deterioration, I'm encouraged by the fact that the comments in this thread (so far) don't appear to be very negative (like when reading about php). While I did buy a book, I wonder if anyone has any suggestions o…

Welcome to the Java world! Like some of the comments so far I think the Java world is actually a pretty cool place to be right now, the language and approaches are becoming a lot less verbose. I blogged about some of the best Java books, hope it'll help you out! http://scalabilitysolved.com/dont-hold-back-your-java/

Re: Java for Everything

#113
post #70

Earlier quoted context omitted.

While I do think Java is great I think that's an exaggeration, I'm sure there are quite a few deal-breakers for particular uses. Personally I've opted not to use Java before because it cannot compile to a self contained native binary.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.

gcj has been abandoned. It was last updated over 5 years ago. It's not clear to me why you would even mention it.

I'm a software developer that primarily uses and likes Java, and the lack of a good and free ahead-of-time compiler for Java that produces native binaries is what I miss most in the Java ecosystem.

Re: Java for Everything

#114

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

Java's start up time makes it pretty crappy for command line utilities.

Java's start-up time is on the order of tens of milliseconds:

http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start...

The 'Hello' program there takes a little over 100 ms for me. I guess my computer is even less of a powerhouse than the author's.

FWIW, the Python equivalent takes about 30 ms on my machine. So, you pay maybe 70 ms to use Java. I don't think many users will notice an extra 70 ms on their command line.

Java's notoriously slow startup is really about the slow startup of software written in Java. Application servers are probably the worse offenders - how can it take a minute and a half to start a fancy webserver? What's it doing in there? They've got a lot better, though; the current generation of app servers start in one or two seconds. Not that anyone cool uses app servers any more anyway. Big bloated GUI apps also deserve some shame here (although i will forgive Eclipse, because i like my IDEs with some meat on them). Language platforms like Clojure and Groovy also manage to take their time, but then they're doing some pretty amazing stuff, i suppose.

Re: Java for Everything

#115

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

IMO, being tethered to the JVM is both its greatest strength and its greatest weakness. The JVM really is a masterful piece of engineering, but it is optimized so heavily for the server that any use case that deviates requires huge hacks to get what you want. For example, running a JIT on Android was so sluggish that Android had to design an entirely new runtime(ART).

Well, Dalvik is a JIT and ART can also do JITC and is designed for newer devices. So not sure that's a great example. The main reason Android doesn't use the HotSpot JVM is memory usage and licensing, I guess. The JVM class/jar format is very inefficient in many ways. On the other hand Dalvik is a very weak JITC. ART is stronger because it has more time to work and is, frankly, better engineered. Dalvik had a lot of problems even quite late in its lifecycle with things like lock inversions and strange method count limits, etc.

Re: Java for Everything

#117
post #3

This is exactly how I feel about Scala now. I really wanted to like Java because of the ecosystem and the JVM, but there ARE a few warts that you will face everywhere - verbosity is one, all the Spring stuff using annotations to wire up dependency injection and AOP and whatnot is another. Scala has the whole JVM ecosystem, static typing and forget about DI/AOP/OOP patterns. Feels like best of both worlds for me.

I find Java much more pleasant without Spring; I much prefer Jetty+Jersey+Guava+Guice. It sounds like that's pretty similar to how you're using Scala.

If only you knew the power of monads.

Re: Java for Everything

#118
How do you even parse JSON in Java? I remember in the days of XML, there was a kind of specification standard for the xml (a specification for how to specify a specification?). From that you could generate Java classes that would correspond to the elements of the XML. But for JSON there is no such meta description, so you are stuck with manually parsing the JSON and hoping you catch all nuances?

Re: Java for Everything

#119

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

Java's start up time makes it pretty crappy for command line utilities.

Startup time on my Win7 box: 0.08 sec.

Re: Java for Everything

#120
post #113
post #70

Earlier quoted context omitted.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.

You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach. gcj has been abandoned. It was last updated over 5 years ago. It's not clear to me why you would even mention it. I'm a software developer that primarily uses and likes Java, and the lack of a good and free ahead-of-time compiler for Java that produce…

There's Avian. It can produce standalone, compact ELF files that have no dependencies. It's not an AOT compiler though. The problem with AOT in the Java ecosystem is quite a lot of modern frameworks and the like have ended up relying on the ability to synthesise code at runtime. Android has put a check on that kind of behaviour but it's still there.

There's also Excelsior, which is an AOT JVM, but it's for Windows only.

I agree that a really good AOT JVM would be very nice. It doesn't necessarily imply better performance however. I remember when GCJ compiled Eclipse for the first time, lots of people were surprised that it didn't magically fix every performance problems. GCJ engineers view was "HotSpot is an excellent compiler and it will take a lot of effort to beat it". When Sun Java became open source therefore, a lot of the incentive to develop GCJ disappeared. It was always primarily a licensing project not a performance project.

Post reply on HN