Implementation of STACK in java.

I think your article needs a lot of cleaning up.

Your first paragraph doesn't say much, and it confusing. I don't think your use of "axioms" or "semantics" are appropriate there, because they have precise meaning in CS and you don't actually give enough detail to justify the use of the technical terms here.

Constructors create an instance -- crucially, you are able to make multiple instances of a data structure, and the defining characteristic of a constructor is that you did not have one before, which isn't explicitly named.

Integers are a confusing example of a data structure. You left out a mutating example (because most integers are treated immutably), which is correct but detracts from the clarification you just laid out!

More importantly, you left out the constructors of integers! This*is* a significant omission, because a structure with no ability to be constructed can't be used! The integers are also a bad example here because defining their constructor is not straightforward (the "pure" way night be to just define the constructor of 1, but this is not intuitive).

I think laying out a more familiar, less formal example would be better:

Consider a shopping cart.

• Construction: you can get an empty shopping cart from the front of the store
• Mutation: you can add an item to the cart whenever you pass by a shelf
• Mutation: you put an item back on the shelf from your cart whenever you return to where the item belongs
• Mutation: you can checkout your cart, resulting in an empty cart and a car full of groceries after paying the total price of all items in the cart
• Query: you can check the value of any item in the cart when you pass by a price check kiosk

Drawing a static picture with two arrows and saying it is "easily understood" what is meant is fairly low effort. If you want to show how it operates, you need to show the structure changing over time. Try showing different "versions" as things are placed and removed from the stack.

"We can say the top of the stack is pointing to -1" -- no you can't, and you shouldn't. It's empty. It's invalid to ask a stack what's at the top if it's empty; if anything it should have a special return value necessarily distinct from all of the objects that your allowed to put in it, like epsilon.

"Not possible to remove it" -- that's not true; it's not possible to remove it without first removing the other values. Precision is important in these kinds of subjects, otherwise you could confuse your reader who is trying to learn something new and doesn't already know what you mean.

"Creates a new stack" if imprecise. What it does is creates an empty stack.

Unclear why use the term "support methods" but didn't use this term when you classified the types of members of data structure at the beginning of the article. Neither size nor isEmpty can be implemented (without a lot of extra space and computation time) in terms of the other operations, so they really should be defined as part of the main interface of the stack. In particular, in a language like C you could easily implement a stack that doesn't track them, leaving programmers at the peril of misusing it but squeezing a bit of extra performance out.

Your exceptions should not be checked exceptions, because they are the result of programmer errors rather than valid uses of the class. They should extend from RuntimeException so that correct callers are not required to handle them.

It's also a little strange to implement a stack with a fixed capacity, but does fit the specification you outlined at the beginning.