@OnMessage handler throw a
RuntimeException, the JSR-356 implementation Undertow (used in WildFly) force-close the endpoint and doesn’t even call the
@OnClose method. Undertow then call the
@OnError method. But at this point in time, the application code can no longer recover or handle the exception. This practice violate the JSR-356 specification and effectively kill Java exception programming. GlassFish with his Tyrus implementation work like a charm, at least in this context. Otherwise, I must say WildFly outperform GlassFish in almost all other ways.
Filed a bug here: https://issues.jboss.org/browse/UNDERTOW-284
Wrote a test application here (the repository’s README.md file offer a workaround): https://github.com/MartinanderssonDotcom/websocket-exception-handling
One important component of my live chat is the queue system. If I’m not online or too busy, then web users are automatically put in queue and change of their positions in the queue are continuously reported on a best-effort basis.
Of course I am only one dude today, but the live chat software is built with utility in mind. It is a complete live chat solution that can handle a crazy amount of users on both ends of the server communicating in all directions. The domain model is centered around one key entity: the
Conversation. Of course the subject-based conversation is also a resource that a user can stand in line for, if there’s no more room for strangers. The live chat software can be deployed as a pure help desk solution for companies to lure customers in, or as a peer-to-peer chat application for friends and colleagues, or as an online chat service for strangers that want to hookup and participate in conversations based on subject. Or as any combination thereof.
One of the challenges that faced me was putting things in a queue, based on a magnitude of different resources. To solve that problem I wrote a
ConcurrentDequeManager that transparently manages deques so that client code doesn’t have to. The amount of deques grow and shrink on demand and elements (for example web users) can have their position automatically reported to them as the position changes. Best of all, it is lock-free and superfast. It’s almost a constant-time operation to lookup the size of a deque. In short, client code doesn’t have to worry one bit about concurrency anymore.
Read more and download: https://github.com/MartinanderssonDotcom/ConcurrentDequeManager
There exists a lot of confusion regarding the life-cycle of JavaFX property listeners and event handlers. For example, many believe that an added property listener must be explicitly removed or memory leaks. To illustrate, here is a quote from the book JavaFX 8: Introduction by Example chapter 3 (page 78):
One last thing to point out is that it is important to clean up listeners by removing them. To remove them you will invoke the removeListener() method [..].
The remove method referred to is
I tried to google all my books and the Internet for an explanation as to why it is “important”. All I could find is even more claims about how “important” it is to remove listeners. But knowing just a handful of Java memory management and reference types, I must conclude that the “importance” is a fallacy.
String goes out of scope and becomes unreachable, is it important to delete/nullify the
char contents that String wraps? No. Just as the String become unreachable and eligible for garbage collection, so to do the char contents (actually, sharing the contents across many String instances is not forbidden by JLS and was the cause of bug in the Oracle distributed JDK prior to 1.6). It doesn’t matter if the box know about the cat inside of it, if you throw the box into the ocean. If the box isn’t reachable, nor is the cat.
I spent some time reading through JavaFX source code and I have no reason to expect that malicious code that cause memory leaks has been applied. There is no reason to believe that the listeners of say a text field’s
textProperty works any differently than the char of a String.
The JavaFX library (which is included in Java SE since version 7 update 6) provide
WeakEventHandler as a necessary tooling for developers when they write listeners or event handlers with a different life-cycle than the target. I think that it is these types and a general lack of knowledge in how Java memory management work that has caused all the confusion. To add even more headache into the mix, literature often speak of JavaFX properties as some kind of a JavaBean superset and therefore imply that JavaFX properties work in a strange and unfamiliar sugar coated way, making developers nervous when using or writing them. However, it is wrong to say that JavaFX properties must be written in one or the other way. How they are written is a convention and not part of a specification. JavaFX properties do no magic.
I wrote a StackOverflow answer to bring some clarity.
I’m scheduled for teaching Java EE at my current workplace and for that (and future assignments) I developed an awesome platform:
Basically, it is a Maven project with Arquillian setup. The POM file includes two profiles for executing the code on GlassFish and WildFly. This project makes “live coding” almost as easy as the static main method in Java SE environments. Write code, then just execute the file as you would with a regular JUnit test!
The project include packages and test files to demonstrate the possibilities with Arquillian. Currently, pure server-side tests and client-to-server tests running in two different JVM:s is demonstrated. Core Java EE technologies such as Servlet, EJB and JPA with a real database are also demonstrated within these test suites. I like to believe that all my comments provided within the files is sufficient for any Java EE student to get up and running.
If you haven’t a favorite GIT client already, I use and recommend SourceTree which has integrated support for GitHub and Bitbucket. I also use it for other repositories on Gitlab. It works great!
Feel free to contribute and let me know what you think =)