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

An Opinionated Guide to Modern Java, Part 3: Web Development

blog.paralleluniverse.co

Post reply on HN
Print view View original

151–160 of 168 posts

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#151

Post by MrBuddyCasino »

xxs wrote: post #148
MrBuddyCasino wrote: post #146

Earlier quoted context omitted.

Ok, now I'm curious: what is a good implementation? Also, whats wrong with ByteBuffers? I was under the impression that they are usually memory-mapped and should be 0-copy.

There are 2+1 major types of ByteBuffers: Heap- backed by byte[] (or char[], int[], etc) Direct: backed by C memory allocated via mmap (on linux). mmap can map to the RAM or a file. Memory mapped files are not an interesting case for NIO impl that works with sockets (On a flip note: FileChannel.transferTo(SocketChannel) doesn't involve memory mapping when the kernel supports it. Windows never supports it, though) Mos…

Ok, I was aware of the difference between Direct vs. Heap ByteBuffers, and I guess I understand the argument about poll/epoll. Now what I don't quite get is why most open source projects chose to use the slower implementation. Don't they know any better? Is it a portability issue? Bugs in certain JVM/OS combinations? Netty.io claims to be 0-copy capable, so I guess that this must be one of the good ones that are available?

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#152

Post by haddr »

jshen wrote: post #82
twic wrote: post #77

Earlier quoted context omitted.

You can, and usually do, do exactly that with app servers. It's true that app servers were originally conceived as a way of hosting multiple apps in a single JVM, but it quickly became apparent that this was a terrible idea, and nobody does it. You run one instance of the app server per app. The app server is really just a great big bundle of useful libraries and a web framework.

so why separate the two if there is always 1 app per app server?

this in general leads to an even worse practice: creating one huge standalone app instead of several specialized web apps. when you develop a service with an embedded server, your endpoint will have an unique port (as each app will have to allocate its own unique port number) and all the idea of restful URI gets broken.

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#153

Post by xxs »

MrBuddyCasino wrote: post #151
xxs wrote: post #148

Earlier quoted context omitted.

There are 2+1 major types of ByteBuffers: Heap- backed by byte[] (or char[], int[], etc) Direct: backed by C memory allocated via mmap (on linux). mmap can map to the RAM or a file. Memory mapped files are not an interesting case for NIO impl that works with sockets (On a flip note: FileChannel.transferTo(SocketChannel) doesn't involve memory mapping when the kernel supports it. Windows never supports it, though) Mos…

Ok, I was aware of the difference between Direct vs. Heap ByteBuffers, and I guess I understand the argument about poll/epoll. Now what I don't quite get is why most open source projects chose to use the slower implementation. Don't they know any better? Is it a portability issue? Bugs in certain JVM/OS combinations? Netty.io claims to be 0-copy capable, so I guess that this must be one of the good ones that are avai…

After seeing the message I've decided to check netty.io's code and I am pleasantly surprised. It has been ages since I checked the project. They use almost all tricks in the book - CAS around selector.wake(), handling the zero returned keys,ref. counting buffers allocator, even a SC/MP queue.

Only couple of downsides: 1) there appears to be the lack of bounded queues and it's a non-trivial one. Bounded queues are important to ensure proper back-pressure on 'producers' and/or killing slow peers. 2) encoding pipeline may require serializing the same message multiple times when sending to multiple clients even if the serialization results into the same byte stream. However this is really a minor issue.

Like I've said I'm pleasantly surprised.

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#154

Post by eip »

zmmmmm wrote: post #125
eip wrote: post #81

Earlier quoted context omitted.

I've been stuck using Vert.x for a year and half. I recommend using something else. It's a questionable framework mashed together with a poorly though out messaging system. I would rather use Spring Integration, Quasar, or Akka.

Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).

Non-standard build/deploy/run.

Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox

Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do.

Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast is hard and inefficient.

Message bus is tightly coupled to application cluster through Hazelcast.

Messaging is missing the most useful features of AMQP like wildcard topics and queues. Only possible to do very basic message routing. Many messages have to be sent multiple times to mimic advanced routing.

Dividing everything into 'verticles' encourages use of callbacks for everything. This increases code size and complexity which increases the need for testing. 'Callback hell'

Encourages polyglot programming.

Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'.

https://www.thc.org/root/phun/unmaintain.html

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#155

Post by elchief »

logn wrote: post #139
elchief wrote: post #35

Do you really need to write a controller and all its actions for each resource with Jersey?

For static resources you can load them like this: public class WebAppConfig extends ResourceConfig { private final String[] mimeTypes; public WebAppConfig() throws IOException { //load static resource from htdocs dir Collection files = FileUtils.listFiles(new File("./htdocs"), null, true); ArrayList mimeTypeList = new ArrayList (); for (File file : files) { final byte[] contents = FileUtils.readFileToByteArray(file);…

Thanks, but I was referring to say a dynamic database-backed resource.

With SDR, you have an @Entity, and a @Repository for that entity, and SDR handles the whole HTTP part, i.e. you don't need to write a @Controller to expose the repository.

Just wondering if Jersey has anything similar.

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#156

Post by runT1ME »

saryant wrote: post #96
runT1ME wrote: post #88

How does asynchronous futures end up being more complicated or in any way worse than the blocking threaded approach? for { user

His issue seems to be the potential for modifying or referencing mutable state where in the yield block (or map or flatMap or whatever). It can be a problem. In Akka actors, referencing sender() from a future will be unpredictable because sender() could've changed in the mean time. I think there are three strong solutions which address this problem: 1) Immutable state. Solves this problem completely but accidental ca…

You can (and should) use Futures independently of Akka actors. You're correct, hidden mutable state with Actors can be a problem, as with mutable state in general.

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#157

Post by vorg »

eip wrote: post #154
zmmmmm wrote: post #125

Earlier quoted context omitted.

Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).

Non-standard build/deploy/run. Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do. Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast i…

> Encourages polyglot programming.

Some of these "problems" aren't problems at all, e.g. what's wrong with polyglot programming?

> Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'.

Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference.

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#158

Post by zmmmmm »

eip wrote: post #154
zmmmmm wrote: post #125

Earlier quoted context omitted.

Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).

Non-standard build/deploy/run. Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do. Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast i…

Wow - thanks for taking the time to put those down.

Some of those I consider advantages - polyglot is the whole reason I looked into it, Groovy is the main language the app I'd be integrating it into is written in, callbacks are the mainstay of many other frameworks (try writing anything in Node.js without a callback!).

That the clustering is poorly designed is probably not an issue in itself since in my case it's a web server embedded in another app, but it's a concern that the framework isn't well thought out and I don't like that (it sounds like) the whole thing is heavily entangled with Hazelcast (which I have no need for, or interest in).

Thanks again for writing down your thoughts!

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#159

Post by jshen »

haddr wrote: post #152
jshen wrote: post #82

Earlier quoted context omitted.

so why separate the two if there is always 1 app per app server?

this in general leads to an even worse practice: creating one huge standalone app instead of several specialized web apps. when you develop a service with an embedded server, your endpoint will have an unique port (as each app will have to allocate its own unique port number) and all the idea of restful URI gets broken.

You lost me. How does embedding the app server break URIs?

Re: An Opinionated Guide to Modern Java, Part 3: Web Development

#160

Post by saryant »

runT1ME wrote: post #156
saryant wrote: post #96

Earlier quoted context omitted.

His issue seems to be the potential for modifying or referencing mutable state where in the yield block (or map or flatMap or whatever). It can be a problem. In Akka actors, referencing sender() from a future will be unpredictable because sender() could've changed in the mean time. I think there are three strong solutions which address this problem: 1) Immutable state. Solves this problem completely but accidental ca…

You can (and should) use Futures independently of Akka actors. You're correct, hidden mutable state with Actors can be a problem, as with mutable state in general.

Absolutely, but people make mistakes.

It's also somewhat unavoidable when you're dealing IO, unless you stick to .pipeTo(self)

Post reply on HN