Rob Spoor

The default toString format (if it's not overridden) is <class name>@<hash code as HEX>, and that's exactly what you're seeing here. The class name in this case is [B. The [ indicates it's an array; the B indicates the element type is byte. So what you're getting is a byte[], and you need to do something with that.

Why have the id fields if that's not your actual id (primary key)? I'd either drop the id field, or make it your @Id and add a unique constraint on the combination of the other two fields.

If you read your error page, it's actually very clear. On line 12 through 16 there is a call to getparameter which, according to the error message, does not exist on HttpServletRequest. That's true - the name is getParameter, with a capital P. Remember that Java is case sensitive, and that also applies to JSP files.

That said, Dave is right. JSP files should only be used for rendering responses, and servlets should be used for processing. The servlet can forward to a JSP to do the necessary rendering when it's done with the processing.

You're welcome

So what you need is not a boolean or Boolean, but something that returns a boolean / Boolean every time it's checked. Fortunately, such a thing exists since Java 8: BooleanSupplier.

In your case:
public void doWaitMethod(BooleanSupplier condition) { long startTime = System.currentTimeMillis(); while(!condition.getAsBoolean() && (System.currentTimeMillis() - startTime) < 7500) { System.out.println("not true, sleeping..."); auto.sleep(500); } }
And you call it like this:
doWaitMethod(() -> auto.getNpcs().visibleOnScreen(shark));

ExecutorService has three submit methods:
* submit(Runnable)
* submit(Runnable, T)
* submit(Callable)

Unlike Runnable, Callable can a) return a result, and b) throw checked exceptions. The lambdas in forEach are Callables, the one at the end is a Runnable.

That's because fixtures does not contain Integer but String[] elements. You can't use toArray with an incompatible type and expect an automagic mapping. You could use streams, but then the question is how to map String[] to Integer.

Example:
Function<String[], Integer> function = ... // what exactly? Integer[] bar = fixtures.stream()        .map(function)        .toArray(Integer[]::new);

Basic authorization doesn't work with cookies (for as far as I know at least). I know two ways of sending it:
1) In the URL as Tim said.
2) In the "Authorization" header. The header value should be "Basic " followed by the result of base64-encoding "username:password". For instance, if your username is "puspender" and your password is "mypassword", you base6e-encode "puspender:mypassword", and the entire header value would be "Basic cHVzcGVuZGVyOm15cGFzc3dvcmQ=".

You're welcome.

One more change you may want to make, and that is to remove the http://localhost:8080 part from the form action. That causes the form to only work on your local machine. If you deploy your application somewhere, the form will still try to redirect to localhost:8080 - the user's own machine.

Three options:
* Absolute within the same host: /Appweb/Appweb. If you change your context path it will break though.
* Relative to the current page: Appweb (note: no leading /).
* Change hello.html into a JSP file and use ${pageContext.request.contextPath}/Appweb. This is like the first option but if the context path changes, the form action changes with it.

A link for project Amber: https://openjdk.java.net/projects/amber/

It may still be an experimental feature, which means it needs to be enabled at both compile and run time. But yes, project Amber is coming up with a lot of interesting stuff.

For those wondering why Ron's first example doesn't need a default clause - that's because the compiler can tell that all enum constants are present in the switch (there will be an exception if the enum has extra constants added without recompiling this class).


One other enhancement from Amber I'm looking forward to is JEP 305. Basically this means you can combine instanceof and assignment into one:
// old style 1 if (myVar instanceof MyClassWithANameThatIsQuiteLong) {    // let's use Java 10's var to not have to type the thing twice    var m = (MyClassWithANameThatIsQuiteLong) myVar;    m.doSomething(); } // old style 2 if (myVar instanceof MyClassWithANameThatIsQuiteLong) {    ((MyClassWithANameThatIsQuiteLong) myVar).doSomething(); } // new style - notice the m at the end of the instanceof check if (myVar instanceof MyClassWithANameThatIsQuiteLong m) {    m.doSomething(); }

Unfortunately, JEP 326 (raw string literals) has been dropped from Java 12, because of the ambiguity of what `` could mean - an empty string literal, or the start of a string literal. I was quite disappointed by that decision...

Daniel Russell wrote:Two Appweb? the folder and the name of the class?

Technically speaking the context path and the servlet path. (Note that I said the same except I used the term "war". That's how web applications are usually deployed.) But your servlet is mapped to /Appweb, not /Appweb/ or /Appweb/*. Try using http://localhost:8080/Appweb/Appweb (no trailing slash).

As for your error when you submit the form, that's because it's still trying to open http://localhost:8080/Appweb/. Unless you have an index.html, index.jsp or a welcome file in the root of your application, that URL simply does not exist.

shashank dwivedi wrote:        if(null != children && children.length > 0)

That line alone should be enough reason not to use File.list or File.listFiles. Instead of throwing an exception, they return null. You have no idea why though. And it also doesn't return an empty array so you have to add the null check. When using Files.walk, Files.walkFileTree, Files.list or Files.newDirectoryStream, you get a proper exception that tells you why the files can't be listed / traversed.

Daniel Russell wrote:The url in the browser is this one: http://localhost:8081/Appweb/.

That's missing the context path, which is the name of the WAR file (minus .war). Unless you deploy a WAR as the root application, you need to use its content path.

Interesting. It seems that this method indeed causes the string "welcome" to be returned, but it's called from a different /welcome page. You need to figure out where the other one comes from.