Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java for Everything

teamten.com

Post reply on HN
Print view View original

121–130 of 344 posts

Re: Java for Everything

#121

Post by Teckla »

pjmlp wrote: post #64
untitaker_ wrote: post #20

The JVM is not usable for short-living processes such as command-line tools. Apart from the ecosystem and the language itself, it's often the reference (or only) implementation which makes it unsuitable for a particular job.

There isn't "The JVM", there are certified JVMs and quite a few of those allow for AOT compilation to native code.

...quite a few of those allow for AOT compilation to native code

Do you know of any good and free ahead-of-time Java compilers that produce native binaries without any additional dependencies?

I haven't been able to find any, but perhaps my Google-fu is weak. gcj is obviously not a good answer.

Re: Java for Everything

#122

Post by edwinnathaniel »

lmm wrote: post #62
justinsb wrote: post #3

Earlier quoted context omitted.

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.

80% of the problems with java as it's usually written are bad policy rather than fundamental language problems. But there are real cases where language limitations mean you have to either use an unpleasant framework or write unpleasant code. Jersey's annotations are pretty nice, but they're still annotations, not really part of your code. You can be bitten by silly errors like an implementation's annotations not quit…

So here's the thing about annotation and Jersey, I believe you can annotate the seralization of return type once at the top of your resource class, the rest, like http verb, needs to be repeated unless you take the convention one more level up a'la Rails. But that's Rails, a web framework that people said does not fit for microservice. Sinatra is.

But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once...

Let's take this further: exception mapping to http response code. In JAX RS, you can map application exception to certain WebApplicationException with specific http response code, I believe you have to handle them manually in Sinatra. You would have to catch the exception and convert it to the intended one per method on your controller.

Re: Java for Everything

#123

Post by Redoubts »

mike_hearn wrote: post #96
drivingmenuts wrote: post #35

Earlier quoted context omitted.

> Java is perfect also for client side. Unless you want it to look totally native client-side. The extra effort required to make a Java app look platform native is something that (near as I can tell) no one has ever attempted.

IntelliJ has historically looked pretty native on MacOS X. At least until Yosemite pointlessly reskinned Aqua to look more ugly. Now I find myself quite happy that IntelliJ is not a native Mac app because I preferred the old look anyway :) You can make the apps look native, if you really care. But in an era when web apps are the shizzle why would you even care? No web app even tries to look native. They just do their…

>IntelliJ has historically looked pretty native on MacOS X.

Because they require the use of Apple's hand-rolled Java 1.6

https://youtrack.jetbrains.com/issue/IDEA-117324#comment=27-...

Re: Java for Everything

#124

Post by peterashford »

saosebastiao wrote: post #106
mike_hearn wrote: post #98

Earlier quoted context omitted.

When did you last try it? Startup time was optimised heavily some time ago and nowadays I don't notice any real difference unless I wrote some toy app and used "time". The JVM starts fast enough that you can write command line utilities just fine.

It is certainly substantially better than it used to be, but it is still pretty far away from an AOT compiled native executable. And forget it entirely if you are running Clojure or Groovy code.

The class of tasks for which Java's startup time is an issue is very very small. I wouldn't use it for a device driver because of resource issues but there aren't many command line commands where 0.08s is an issue.

Re: Java for Everything

#125

Post by BenoitP »

chadrs wrote: post #93

This whole "expressive vs. performance" is a false dichotomy. Languages like Scala and Haskell are performant like Java and expressive like Python. Not to mention the work being done on JIT compilers by V8/HHVM/PyPy that are helping to close the performance gap for dynamic languages.

I am maintaining at the moment some Scala code I did not write. Sometimes you wish for less expresiveness.

Re: Java for Everything

#126

Post by jim_greco »

facepalm wrote: post #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?

There's plenty of libraries for this. Jackson being the best one I've used.

Re: Java for Everything

#127

Post by larrys »

scalesolved wrote: post #112
larrys wrote: 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/

Thanks for that.

Question though. The first book you listed (which got excellent amazon reviews as well) was published in 2008. Typically I've been biased into thinking that a book had to be somewhat recent. Obviously this isn't the case here though. (Do you agree with that in some situations btw?). I would have never purchased this book if you hadn't pointed it out so thanks it's in my cart.

Re: Java for Everything

#128

Post by allengeorge »

sgt wrote: post #24
minthd wrote: post #15

Earlier quoted context omitted.

Why not just use Groovy for everything instead of java ?

Speaking of - how is Groovy doing these days? I looked at the Groovy webpage and I saw ads splattered here and there - never a good sign, I also see that the mailing lists are pretty quiet. Is Groovy dying?

They're moving to a new site: http://beta.groovy-lang.org/

Re: Java for Everything

#129

Post by mytochar »

pjmlp wrote: post #58
desdiv wrote: post #47

Earlier quoted context omitted.

Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. Ctrl-Shift-R B A R No, not much effort at all. Just twice as many keystrokes. I wouldn't even mind the verbosity if…

F2 on my IDE. One key, no need for Ctrl-Shift-R

One hand position still over the keys and uses common fingers, and is easy for emacs users (Ctrl + Shift + R), versus leaving the typing keys entirely to climb to a command key that's used sufficiently infrequently that you have to look at where it is.

At least that's my experience.

Oh, and more fun. If you're on a modern keyboard, you have to type the function key since apparently volume up and down and expose are more important than function keys.

Long story short: what's faster and 'less' for some, is more for others. And this is why we have options! :D

Re: Java for Everything

#130

Post by cgh »

facepalm wrote: post #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?

Have a look at the Jackson library. There are many others.
Post reply on HN