Rob Spoor

Go has pointers, but the difference with pointers in C and C++ is that you don't have to perform the cleanup. Like Java and C#, Go comes with garbage collection. A side effect is that you can do a lot that's not possible in C or C++, like return a pointer to a local variable. In C and C++, that's going to blow up in your face. In Go, it will work just fine.

For instance, I needed pointers to constants. You can do that the hard way, or just simply use a helper function:
func stringPointer(value string) *string { return &value }

Whenever you're using StringBuilder (or StringBuffer), never ever ever ever use + to concatenate content inside calls to append. Instead, split it up into separate append calls. If possible, use characters instead of single character strings.

So, taking Carey's code:
public String displayRoster() {        StringBuilder teamOutput = new StringBuilder(teamName).append('\n');                for( Player player : teamList ) {            teamOutput.append(player).append('\n');        }

When starting with Spring, it helps if you have some background in Java EE. Spring uses similar concepts (e.g. CDI), and in some cases even the exact same APIs (e.g. JPA). However, it's not necessary: you can learn Spring without ever having done anything in Java EE.

Mike Simmons wrote:

Tim Holloway wrote:and since I'm pretty sure that "int.class" isn't valid

It is valid - it's how we talk about parameter types and return types with reflection, allowing us to distinguish between int.class and Integer.class.  There's even a Void.class just to allow us to know that a method returns void.

Void.class is not the same as void.class. The first is a representation of class Void, which only exists to deal with void in reflection, and has only one possible value - null. The second is the actual representation of void.

Regarding int.class, I'm pretty sure that used to be invalid because otherwise there wouldn't have been need for Integer.TYPE (which is the same as int.class).

You can also use ULID instead of UUID.

Technically the documentation is not wrong; Collectors.toList() does use ArrayList. However, that's an implementation detail that shouldn't be exposed like this.

(That's basically what Campbell already said in other words...)

To be able to use toList() instead of Collectors.toList(), you have to use a static import for Collectors.toList:
import static java.util.stream.Collectors.toList;

Or nothing at all. Piet's suggestion will show you which is the case. I tried it myself, but I'm not going to spoil anything

@Jessica: if you take a look at the documentation, do you think you can already cross off some of your possible answers?

I'm guessing here, but maybe Kishori was using EA (early access) builds?

It's not that hard to keep track of the actual API changes, but getting them printed takes a bit more time than posting them online like I do.

Vaseem Mohammed wrote:With the new licensing policies would there be challenges in adopting Java?

Unlikely. Although Oracle's JDK licensing is (IMHO) a step in the bad direction, OpenJDK is stepping up in a major way. It's very easy to get a version that's not as limited as Oracle's JDK. A lot of major players like Amazon, Pivotal and RedHat have their own OpenJDK distribution, so getting (paid) support without having to go to Oracle isn't hard either. (I'm using AdoptOpenJDK on Windows myself.)

CORS is only needed if your web application needs to perform AJAX calls to different hosts. If all of your AJAX endpoints are on the same host as the web app itself, then you don't need CORS at all.

I'm guessing it's option 2. %2e means ., so the path is the URL encoded version of ../../../../system/autoexec.ncf. In other words - go back 4 times (which will go to the root if the current directory is at most 4 levels deep), then go into system, then try to access autoexec.ncf. I quick search shows that this file belongs to NetWare, so I'd be surprised this is caused by an I/O issue or botched Windows update.

It should only be an issue if the other side uses terrible XML parsing based on prefix names and not on the actual namespaces. If the other side does their job well, the name of the prefix shouldn't matter at all. So let's try it out first, and only try to fix the issue if it really is an issue.

miha zoubek wrote:right now my request looks like:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"><env:Header>

I need to change this to:

<Soap:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"><Soap:Header>

No, you need to change it to <Soap:Envelope xmlns:Soap="http://www.w3.org/2003/05/soap-envelope"><Soap:Header>
The prefix and namespace need to match. Whether that's env or Soap shouldn't matter, but some clients are unfortunately not smart enough to check for the namespace but check the prefix instead.

Why did you remove your code that uses multipart/related? That's exactly what you need to inline images in HTML emails.