Stephan van Hulst

Wow, apparently this was fixed by a feature implementation in Java 11: http://openjdk.java.net/jeps/181

I'm guessing that direct access to private members of nested/enclosing classes was implemented through bridge-methods before Java 11. Bridge methods are added by the compiler, so it doesn't account for reflective access.

Java 11 added special access scopes that allow access to these private members without using bridge methods, which would also work for when using reflection.

[edit]

From the JEP I linked to above:

JEP 181 wrote:
A further consequence of the lack of JVM support for private access within a nest, is that core reflection also denies access.
A reflective method invocation (using java.lang.reflect.Method.invoke) from one nestmate to another throws IllegalAccessError (unless access control has been disabled).
This is surprising given that reflective invocations should behave the same as source level invocations.

This is the code that works, Campbell. I asked for it so we could give a review. :)

F Lucas, can you provide the Getter and Setter interfaces please?

The error message tells you exactly why it can't create an instance of NewInstanceTest1$Dog: It has the private access modifier.

That's neither void, nor a method. It's a global character array.

The problem is that you're adding up characters. Java treats characters as numbers, and the + operator returns an integer.

Declare codedMessage as a StringBuilder and use the append() method to append characters.

Use a return type of String, and return the value of the StringBuilder.toString().

It just implies that most of the heavy lifting would occur in native libraries, and that Java libraries would be written that select classical or quantum algorithms automatically.

It doesn't imply whether Oracle is working on any of this.

I guess it kinda depends on what kind of information you require the user to enter in the dialog. One way to do it is have the dialog return a DataSource, which you can then pass from your frame to the persistence layer.

You should break up the input string in parts depending on how they're delimited. For instance, the time at the start (including the milliseconds) is delimited by whitespace, So you first want to match as many non-whitespace characters as possible, followed by at least one whitespace character. Use capturing groups for the parts that you're interested in, and use non-capturing groups for delimiters or fluff. That means that the regex for the first part could look like this:
(\S*?)\s+?
This means: capture zero or more non-whitespace characters, and then match one or more whitespace characters.

For parts of the input string that are enclosed in braces, you would do something like this:
\[([^\]*?])\]
This means: match a '[' and then capture zero or more non-']' characters, and then match a ']' character.

Then you have to compose your entire regex of patterns like this, and then escape all the characters that have a special meaning in strings. I can promise you this will become incredibly messy and unmaintainable. Instead, you will probably want to use java.util.Scanner to process the input string in bits. Have you already looked at its API documentation?

You would use a regex to get specific information out of a string. What information are you looking for? Do you want to get EVERY piece of information out of the string, or just a few particular parts?

I'm assuming that by the crosses in the input string you mean ANY character, but you just censored out the actual characters.

I don't think what I'm saying is contrary to your point Tim. Accessors are better than direct field access. I was saying that people shouldn't blindly add accessors for every field of an object, if the outside world doesn't need access to those properties at all.

It sounds like you already dove into it. Are there particular things that you were wondering about getting into?

You are very welcome, and congratulations on working it out!

F Lucas wrote:FIX: I had to extract the authentication tag (16 bytes in the end of the ciphertext) and use .doFinal
with it as parameter to make it verify the tag.

I don't think that is correct. The authentication tag is automatically extracted by the GCM algorithm. I think what you meant was the initialization vector (or salt, as you call it).

Can you show us your final code? We might suggest some more improvements.

F Lucas wrote:When to use getters and setters? almost always.

You mean, almost never, unless you meant "always access fields through methods, rather than directly". Simple getters and setters don't really add a lot of behavior to a class. Getters usually are fine, but only add them when you need them.

You can make a class npc that has his move() method replaced by an AI, and a class player
that uses the input scanner of his class to move.

You can achieve the same thing with composition and the strategy pattern. For instance, you could create an NPC with a MovementStrategy where one strategy is implemented by entering input through a keyboard, and another is implemented as an AI. Actually extending a class should mostly be done if you want to add new methods.

Welcome to CodeRanch!

As Tim has pointed out, if your code uses the static keyword a lot, then your design is off. Static means that a field or method is a member of a class of objects, not an instance of an object. And since Java is Object Oriented, we want to try and make everything as much about instances of objects as possible.

Let's consider the 'Name' field, which hereafter I will call 'name' instead, as should you. When you make it static, you're saying "Every NPC that will ever exist, share the exact same name". Changing the name of one NPC will change the name of all NPCs. When you don't make it static, you're saying "Every NPC has their own name, which may or may not be equal to the name of another NPC".

Static fields should be used for one purpose and one purpose only: Declaring constants. A constant is a value that will never change normally. For the constant to change, the code itself must change. A good example is Math.PI. It's value will not change, it represents a fixed known value. The developers might change the code and recompile it to make it more accurate, but its meaning doesn't change. Usually constants are strings for fixed identifiers and keys, or numeric.

Static methods are used when you want to write behavior that doesn't depend on instance fields. While static variables are bad, static methods aren't bad in their own right, but if you have a lot of them it just means you are probably not using the language it was intended to be used. After all, we usually want our behavior to be based on fields of object instances.

Now let's get to your questions. When to use getters and setters? The answer is as little as possible. You want to keep information contained inside an object as much as possible, and let the object modify itself or interact with other objects in reaction to events. So try to reformulate methods that affect your object in a way that closer resembles events that might happen. For instance, instead of saying setDamage(int), you might want to say something like injure(Weapon) instead, and the NPC itself determines how much it is injured, based on what weapon it was hurt with and other private information it contains, which might include armor that the NPC is wearing or how nimble they are. Often, you will want to get rid of setters entirely. For instance, why would you want to change the name of an NPC after it has received one when it was created? Use constructors to give fields an initial value that can't be changed later.

For getters, only expose them when the rest of your application really needs them. If you want to display health bars in your application, then you obviously need to be able to get the health of an NPC. If you want to keep health a secret, then why expose the getter in the first place? Even then, expose accessors in steps: If they're only required in the current package, then don't make them public. Make them public if you want to be able to access them from everywhere.

I changed your class a little bit to demonstrate some concepts. Don't take it as a precise example of the code you must write. Programming is as much personal taste as it is science.
final class Creature {  private final String name;  private final int maxHealth;  private int health;  Creature(String name, int maxHealth) {    if (name == null)      throw new IllegalArgumentException("The name must not be null.");    this.name = name.strip();    if (this.name.isEmpty() || !this.name.equals(name))      throw new IllegalArgumentException("The name must not be empty and must not start or end with whitespace characters.");    if (maxHealth < 1)      throw new IllegalArgumentException("The maximum health must be positive.");    this.maxHealth = maxHealth;    this.health    = maxHealth;  }  String name() {    return name;  }  HealthIndication healthIndication() {    return HealthIndication.forFractionOfMaxHealth(health, maxHealth);  }  boolean isAlive() {    return healthIndication() != HealthIndication.DEAD;  }  void injure(Creature attacker, Weapon weapon) {    health -= attacker.strength() * weapon.power();    if (health < 0)      health = 0;  } }
I renamed the class to Creature, because it's usually better to write out acronyms, NonPlayerCharacter might be a bit verbose, and Character is already a class of the Java standard API. The class is final to prevent it from being extended. You should always make classes final unless you intend to extend them, and if so, you must really design them well for it. There are a lot of complex things you must take into account when allowing your class to be extended.

The class is package private, and so are its constructor and methods. Only make them public when you need to be able to access them outside of the package that the class is in.

The fields are all instance fields (non-static) and most of them are final to prevent them from being changed. Why would you allow the name or the maximum health of an NPC to be changed after they've been created? If you want to be able to change the max health, in response to events like leveling up or drinking some magic potion, you can always make the field non-final in a later version of the code. The initial values for these fields are set in the constructor, and can not be changed through setters.

With the healthIndication() method I gave an example of how you can query an object for information, without exposing all the internal details of the object through getters. HealthIndication is an enum (a finite collection of constants) that gives rough estimates of how much a creature was injured. This is what it could look like:
enum HealthIndication {  UNINJURED      (1.0),  BARELY_INJURED (0.9),  INJURED        (0.6),  BADLY_INJURED  (0.3),  NEAR_DEATH     (0.1),  DEAD           (0.0);  private final double fractionOfMaxHealth;  private HealthIndication(double fractionOfMaxHealth) {    this.fractionOfMaxHealth = fractionOfMaxHealth;  }  static HealthIndication forFractionOfMaxHealth(int health, int maxHealth) {    if (health < 0)      throw new IllegalArgumentException("The health must not be negative.");    if (maxHealth < 1)      throw new  IllegalArgumentException("The maximum health must be positive.");    var fractionOfMaxHealth = (double) health / maxHealth;    for (var indication: values()) {      if (fractionOfMaxHealth >= indication.fractionOfMaxHealth)        return indication;    }    throw new AssertionError("This line should be unreachable.");  } }
As you can see in both types, the non-private methods and constructors check their parameters to see if no invalid values were entered.

Because TraversableOnce is more natural to use in Scala, and Array implicitly converts to TraversableOnce.

Seriously though, for questions about the design you should probably turn to the developers of the Spark API.

If you want to address me formally, you can say 'Mr. van Hulst', but I prefer just 'Stephan'.

Don't be embarrassed. Spliterators are not intuitive and a lot of experienced programmers aren't familiar with how they operate exactly. Besides, I enjoy trying to answer your questions.

Operations aren't really performed in reverse order. They are initiated in reverse order, but they finish in normal order. You can compare it to how nested method calls work. The main() method of a program starts running first, and may call another method. Only after that method call returns, the main method can return.

In the example code that you gave, nothing happens at all because there is no terminal operation. But let's assume that you added the terminal operation .forEachOrdered(System.out::println).

The forEachOrdered() method would call the tryAdvance() method of the map operation, which in turn calls the tryAdvance() method of the filter operation, which in turn calls the tryAdvance() method of the source. The source takes the integer 2 and passes it to the Consumer that the filter operation passed to it. That Consumer checks that 2 is greater than or equal to 3, determines that it's not, and so does nothing more. Control returns to the tryAdvance() method of the source stream, which just returns the value 'true' to indicate to the filter operation that there are more elements remaining, which the filter returns back up to the map operation, which the map operation returns to the forEachOrdered operation.

Because there are more elements remaining, the forEachOrdered operation calls the tryAdvance() method of the map operation a second time. This will call the tryAdvance() method of the filter operation. This will call the tryAdvance() method of the source. The source passes the integer 4 to the Consumer that was passed in by the filter operation. The Consumer checks that 4 is greater than or equal to 3, determines that it is, and so it passes 4 to the Consumer that was passed in by the map operation. The map's Consumer then applies the toString() method on the 4, and passes the String "4" to the Consumer that was passed in by the forEachOrdered operation. The forEachOrdered operation's Consumer then calls System.out.println() on "4".

Maybe it's easier to visualize if I write this particular chain of operations as nested method calls:
void forEachOrdered() {  var elementsRemaining = true;  while(elementsRemaining) {    elementsRemaining = map_tryAdvance(nextElement -> System.out.println(nextElement));  } } boolean map_tryAdvance(Consumer<String> consumer) {  return filter_tryAdvance(nextElement -> consumer.accept(nextElement.toString())); } boolean filter_tryAdvance(Consumer<Integer> consumer) {  boolean elementsRemaining;  var nextMatch = new AtomicReference<Integer>();  while (nextMatch.get() == null && (elementsRemaining = source_tryAdvance(nextElement -> {    if (nextElement >= 3)      nextMatch.set(nextElement);  }));  var value = nextMatch.get();  if (value != null)    consumer.accept(value);  return elementsRemaining; } boolean source_tryAdvance(Consumer<Integer> consumer) {  if (index >= list.size())    return false;  consumer.accept(list.get(index++));  return index >= list.size(); }
Note that this is NOT what really happens. It's just a way you can imagine how the control is transferred between the different spliterators. You can see that even though the flow is initiated from the last stream operation to the first, the first stream operation will be finished before the last stream operation is finished.