Win a copy of Create an Uber Clone in 7 Days: Build a real world full stack mobile app in Java this week in the Android forum!

Stephan van Hulst

Saloon Keeper
+ Follow
since Sep 20, 2010
Enschede, The Netherlands
Cows and Likes
Cows
Total received
168
In last 30 days
1
Total given
161
Likes
Total received
1834
Received in last 30 days
21
Total given
188
Given in last 30 days
4
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan van Hulst

For the second argument, use either word -> word or Function.identity().

Note that this collector will throw an exception if it encounters two Words with the same value. If that is a real possibility you need to supply it with a merge function as well.
14 hours ago
Yes, but I'm sure there is some way to configure it.
19 hours ago
Well, while this is really interesting stuff, I don't think you really need to know that much about it to be a good Java programmer. Every little bit helps though.
20 hours ago
Cookies are data that are sent by the client on every request and therefore not part of the server's state.
There's another very subtle but important consequence of making an instance field final. It acts as a memory fence when you access it after constructing an object. Consider this program:

What are the possible outputs of this program? It can be "Before reassignment" if the call to println() happens before the call to setItem(), or it can be "After reassignment" if the new thread manages to call setItem() first.

There's actually a third outcome. It's possible that this application prints "null". This happens because threads are allowed to reorder operations as long as the reordering of those operations is not visible to the code that thread is executing. However, the reordering of those operations may still be visible to other threads. Consider the operations that the new thread performs:

  • Create a new Container.
  • Assign the string "After reassignment" to its instance field.
  • Pass the Container reference to the setItem() method call.

  • However, without synchronization, the main thread may see the following order of operations:

  • Create a new Container.
  • Pass the Container reference to the setItem() method call.
  • Assign the string "After reassignment" to its instance field.

  • This means that the main thread may call println() after the new Container has been passed to the setItem() method call, but before the instance field has been assigned (and so has the default value null).

    Before Java 5 you had to fix this using a bunch of ugly synchronized blocks, but since Java 5 final fields are guaranteed to have the value you initialized them with when control returns from a constructor call.
    1 day ago

    Arun Singh Raaj wrote:As you said Transaction Manager takes care of ACID, does it mean that even if the application was stateful, the transaction wouldn't corrupt?


    The answer depends on what you mean by a corrupt transaction. The transaction manager makes sure that all data you send to and retrieve from the database will be consistent between many requests. It can't guarantee that the data you sent to it in the first place was the data that you intended to send. This data can easily get corrupted before it ever reaches the transaction manager if your application is stateful and not synchronized properly.

    Yes, you can write a stateful web application that handles requests correctly and doesn't corrupt data in the face of concurrent requests, but as soon as you start getting many concurrent requests it will grind to a halt as most of the requests are stuck waiting to enter some synchronized block and eventually time out.

    you have to send confirmation email to the customer and generate an invoice. These two tasks have separate classes and methods. So do they need synchronization?


    I'll elaborate on what Paul said. After the ticket booking transaction has committed, the web application can spawn separate tasks to generate the invoice and send a confirmation e-mail, and then directly return a response to the client. Even though these tasks may run in separate threads and use mutable objects, you don't have to synchronize between them because the tasks can be performed in isolation without requiring any shared data. Just remember to pass all relevant data to the tasks when you create them. If they have to access the database again that's a BIG NO NO.
    Static methods most definitely are inherited. They are also members of a subclass (which is why you can call them from a reference to the subclass). You just can't override them.

    You can easily answer your own question by trying it out.
    3 days ago
    I think for hobby projects I've used Travis in the past. That was a while ago though, and I'm embarrassed to admit I don't use CI all that often in hobby projects.

    At our company we use an on-premise Team Foundation Server instance, but that's neither free nor (obviously) online.
    3 days ago
    If your web application is stateless (that is, data in memory is either immutable, or is request-scoped and not shared between requests), there is nothing to synchronize. That means that multiple requests can be handled at the same time without affecting one another. This is important because:

    1) Synchronization does not scale well in web applications with many users.
    2) Lack of synchronization leads to incorrect results in stateful applications.

    The approach that is correct and scales best when more and more concurrent requests need to be handled, is to let the DBMS take care of synchronizing access to data that need to persist between requests (guess why the database code in the application is called the 'persistence layer').

    The database's transaction manager takes care of ACID, as long as you use transactions correctly. Write service classes that handle an atomic unit of work per method, based on a specific use case. It first starts a transaction, accesses one or more repositories of data (which all make use of the same database transaction manager), and finally commits the transaction. When in the mean time another service method call commits a transaction that conflicts with the current service method call (such as booking the same that is currently being booked), the current service method call will detect that (either because data from the repository indicates that it changed in the mean time, or because the repository threw an exception), and will finish the transaction without committing it. That will cause all changes made to repositories for the current transaction to be rolled back.

    Hibernate is a framework that wraps around database drivers. It implements transactions through calls to the underlying database driver, of which the transaction manager is also a part.
    Web applications should be stateless, and therefore have no synchronized blocks. All synchronization is done at the database level using transactions.

    When a transaction fails because another transaction occurred in the mean time, that's the time you let the user know that they have to try again.
    Why? As Paul said, any proper XML library will handle CDATA just fine.

    Why don't you just try it out? Then you'll know for sure.
    I know there has been lots of research into cyclomatic complexity, and I think that splitting methods figures heavily into this.
    4 days ago
    Yes, it's true, you might harm the poor worker because the shop has to shut down, but thereby you might also improve conditions for future workers in the region. It's a complex matter though. This discussion also reminds me of how heated the argument about tipping waiters in North America can become. In the short term, tipping is important for waiters to earn a living wage, but it causes some companies to shirk on paying out a living wage in the first place.

    I believe I stumbled upon a study once that demonstrated that poor countries that didn't receive aid from rich countries were quicker to improve their economies in the long term than countries that depended on aid.
    4 days ago
    I don't think they forgot to take out the assert. Remember that this is open source that can be compiled in debug mode and isn't necessarily a reflection of a particular 'build'. Before compilation the asserts might still be removed, or more likely, they're left in because they don't do any harm.

    It's important to distinguish the compiler from the standard libraries. While some classes of the standard libraries might be written in C/C++ and compiled to machine code, I believe the compiler itself can be written in pure Java (ignoring for a minute that it has to use classes from the standard library that might call native code) because it translates Java to Java Bytecode, which by its very nature is platform independent.

    The code for the JVM will likely make heavy use of native code though.
    4 days ago