Tag Info

New answers tagged

2

Found this on Stack Overflow: What's the difference between an “engine” and a “runtime”? tl;dr from the accepted answer: Engine usually refers to a higher level software component. We almost think of the JRE as the processor. Instead of a physical CPU running machine code, we have a virtual CPU running bytecode. Again using the database example: A ...


0

You can name a method according to the action like doSomething() , takeBackUp () . To make it easy to maintain you can keep the common contracts and validation on different procedures . Call them as per use cases. Defensive programming : your procedure handles wide range of input including (Minimum things those are use cases must be covered anyway)


13

A method's behavior should be clear cut, intuitive, predictable, and simple. By trying to be more "forgiving," you are introducing a lot more edge cases than is generally worth it. Preprocessing the string to make its format valid is something that another portion of the program should be doing. Here, you just need to validate the requirements of the method ...


3

You mention some of the context from which this question comes. Given that, I would have the method do just one thing, it asserts the requirements on the string, let it execute based on that - I wouldn't try to transform it here. Keep it simple and keep it clear; document it, and endeavour to keep the documentation and code in sync with each other. If you ...


4

As others have said, making the string matching "forgiving" means introducing additional complexity. That means more work in implementing the matching. You now have many more test cases, for example. You have to do additional work to ensure there are no semantically-equal names in the namespace. More complexity also means there is more to go wrong in the ...


19

There are a few points: Your implementation must do what the documented contract states, and should do nothing more. Simplicity is important, for both contract and implementation, though more for the former. Trying to correct for erroneous input adds complexity, counter-intuitively not only to contract and implementation but also to use. Errors should only ...


43

Your method should do what it says it does. This prevents bugs, both from use and from maintainers changing behavior later. It saves time because maintainers don't need to spend as much time figuring out what is going on. That said, if the defined logic isn't user friendly, it should perhaps be improved.


0

Is there a name for splitting interfaces by accessors and mutators into separate interfaces? There is a name, it is called "overdesigning things" or "overcomplicating things". By offering a mutable and an immutable variant of the same class, you offer two functionally equivalent solutions for the same problem, which differ only in non-functional aspects ...


0

The separation of a mutable collection interface and a read-only-contract collection interface is an example of interface segregation principle. I don't think there is any special names given to each application of principle. Notice a few words here: "read-only-contract" and "collection". A read-only-contract means that class A gives class B a read-only ...


3

The short answer is that Java web developers, as a whole, seem to be happy with the tools/frameworks they currently have, and do not prefer the Rails way of working enough to make such an effort worthwhile. Feel free to start a project if you think it would help. The Java platform has many frameworks for doing web development, some provided by Sun/Oracle, ...


0

Because java it self providing some technologies for servers like JSP, Servlet. but in ruby no such technology exist. It does have Networking capability it up to us how we use it. That what Ruby on rails developers did. Java developers does not require any framework but ruby developers do for FAST Development's And Oracle itself providing support for JSP and ...


0

Memory dumps can be obtained in a variety of ways, depending on what exact type of system your application runs on. Typically, creating a memory dump would require access to run processes on either the server your application runs on, or if it's a VM it could also be done from the VM host. Blanking passwords is a mitigation measure to reduce the amount of ...


0

It uses more resources simply because it has more features. An EE server comes with a whole lot of bundled libraries. There's no advantage to using an EE server if you're not going to use these libraries, so you won't gain anything straight away by moving an app from plain Tomcat to Glassfish or TomEE. As for performance, there's no innate reason why an EE ...


0

Encapsulation and Data Abstraction are related, yet different concepts. Encapsulation is about designing a class. Data abstraction is about designing an algorithm. An easy explanation would be: Encapsulation asks the question: What are the legal ways of interacting with this implementation? Data Abstraction asks the question: What is the set of ...


0

I learnt from my teacher that, Data abstraction is the methodology to enforce barrier between representation and interface. No, abstraction is not just having public and private methods in a class. Abstraction is having just an interface and implementing one or more classes against this interface. An example: public void printAll(List<String> ...


0

I think requirement #3: "Users can have access to resources/permissions" is a little vague. Until you're more specific in your requirements, it cannot be answered. Here is how you can look at your two scenarios and make a decision. In scenario #1 a user can only have access to a resource by having a permission that is linked to a specific resource. That is ...


0

(This is just a personal opinion, not a concrete answer.) This depends on the framework or architecture. In a lot of frameworks and architectures, the cause and effect are no longer carried by the call stack. Instead, commands became data, queued up and distributed to workers far away - another thread, another process, another cluster on the other side of ...


2

Please don't follow the advice in that article. The author is correct to advocate immutable objects. But to get the advantages of immutable objects, the object should be transitively immutable. That is, it should only keep references to other transitively immutable objects. It shouldn't be referencing data providers, and it certainly shouldn't be keeping ...


0

Yes you can pass in the derivative, however, it must be the derivative of your activation function. N.b. the network will fail if the derivative isn't actually the derivative of the activation function. The options you have are: statically define your activation function and its derivative statically define a list of activation functions that can be ...


0

It depends on the intent of your code and avoiding repeating yourself. If the intent is to rely on the return value of a method to be the same in both instances, assign a single variable. This way, another developer does not have to determine whether or not both uses of the method will always return the same value. In this example, every developer should ...


2

When should I instantiate a variable rather than grabbing it through a method? When the value returned in the method has meaning or will be use past the name of the method, then get the value and assign it to variable with the appropriate name. If metadata.getColumnCount() is constant during the loop, then you can get it and cache it in a local before ...


3

According to Wikipedia: [The carriage return] commands [...] to move the position of the cursor to the first position on the same line. You are in right to expect the behaviour you describe. However, relying on a control character implies relying on your system rather than on your code. It will mostly depend on how your display system will interpret ...


6

BigInteger and BigDecimal are immutable objects. Once instantiated, if you want to do something with it, you create a new object. This isn't a problem per say, and actually avoids many other problems (especially when threading), and numbers tend to be things that are constants - you don't change them. It is very common for code that is working with ...


0

What matters the end-user? Performance Features / Functionality Design Case 1: Optimized bad code Hard maintenance Hardly readable if as an open-source project Case 2: Non-optimized good code Easy maintenance Bad user experience Solution? Easy, optimize performance critical pieces of code e.g.: A program that consists of 5 Methods, 3 of them ...


0

You can write ugly code that is very fast and you can also write beautiful code that is as fast as your ugly code. The bottleneck will not be in the beauty/organization/structure of your code but in the techniques you chose. For example, are you using non-blocking sockets? Are you using single-threaded design? Are you using a lock-free queue for inter-thread ...


0

The challenge with the alternative is that it makes adding/changing/removing optional features more difficult. For example, if we add a new optional feature, we now have to change the base class, and then change all of the subclasses to add the feature or the non-feature. This can be somewhat mitigated if there is a reasonable default, such as a no-op, so ...


4

Possibly. "Classic" existing consumers do not expect a value to be returned, thus would simply ignore the string being returned. By "classic", I mean something like this: public void DoSomething(Contract contract) { contract.update(); contract.delete(); } Now, there's a possibility that there is some functionality in Java that expects a method ...


5

If you only change the interface as outlined here, then yes you are breaking the code. Because every implementation of the interface must now return a String, and before the change none of them does. Assuming you make each implementor actually return a String, then no, this cannot break the code because no caller of any of these methods is using the return ...


0

You're going to find a variety of links between Java and X industry. Recall that a lot of sold-state and integrated circuits run Java in a "baked-in" approach. So most of the semiconductor industry jobs are having you write Java for chipsets, circuits, etc. It's still Java, just different frameworks and whatnot that you will have to adapt to; you'll be fine. ...


0

Kilian Foth's answer is excellent, so please upvote it, accept it, go by it. This answer is simply meant to show the fallacy of trying to shoehorn patterns into everything. First of all, you will need inversion of control. Your main application logic should not go out there on its own to access the filesystem and query files, it should be passed some ...


0

The unchecked cast warning is one of the most problematic, annoying, and ultimately useless warnings issued by java. I say "ultimately useless" instead of just plain "useless" because it is not entirely without merit, it is good to know that you have an iffy conversion somewhere, but it just so turns out that if you do any work whatsoever with generics in ...


0

It is a sort of catch 22, I agree. However if you know that only instances of type T are added to the list, then you can surpress the warning without repercussions. The compiler isn't intelligent enough to derive this information on its own. However, also know that should you create another method that allows the insertion of instances of type ...


0

The only working solution is to suppress the warnings. That's what the existing generic collections also do. So it doesn't mean there's anything wrong with your design - if there is anything wrong, it's with the design of Java generics (which had to make some compromises to achieve downwards compatibility).


11

You shouldn't. Design patterns are named, recurring solutions to recurring problems that involve complex workflows, typically involving many classes with systematic relationships to each other. What you have here is a simple task that calls for a loop or two and a simple list data structure. Ask again when you have to write a complex system with dozens of ...


0

What would be a canonical example of logging at the TRACE level? ENTRY/EXIT logs from a method. These logs help you trace the flow of the program and tend to be very useful when: The program abruptly crashes - you know exactly which function it crashed in by looking at the last line of the log Some rogue function silently fails by absorbing an ...


1

You pretty much nailed it with your comment Maybe I should not be thinking about this question now because the tutorial hasn't brought it up It looks like you're on or near lesson 5, What is an Interface. I think your answer may be found on or near lesson 67, Interfaces. (I'm looking at the Table of Contents & just counting each line) Quoting ...


0

Been there. What I did was as follows: In the file repository class that implements FooRepository: try{ // try to store } catch (IOException e) { throw new CouldntStoreFooException(e.getLocalizedMessage()); } try{ // try to retrieve } catch (IOException e) { throw new ...


0

Your approach is correct and if you need that your repository client could differentiate between repository exceptions, maybe for showing different kinds of errors, you could also create a tree of Repository Exceptions (always inheriting RuntimeException) like Spring does. public class IntegrityConstraintViolationextends RepositoryException { } public ...


1

This is easy. Walk down the tree (quad tree or R-Tree, etc) until you find the lowest node that contains the “search point”. Then look at the parent of that node, and check all points that is contained within the parent (including sub notes) If you have not found enough points, then move on to the parent’s parent etc. Remember That the nearest point ...


3

Your solution is correct: repository should throw a generic RepositoryException-type to signal that something went wrong. You wrap the actual exception in that RepositoryException so your logging can get access to the data it needs and your consumers can trap the generic exception and handle it somewhere down the line. Wrapping the actual exceptions hides ...


1

I think your strategy is correct (and I accept opinions may vary as to "best"). The client should not care if the underlying repository is a file or a DB server, they care that the commit failed - they need to know that first and handle it. Following on from that, if they wish (e.g. require user intervention or detailed logging) try deal with the underlying ...


3

First let's clarify something: You mention that after assigning null to the variable you could forget to initialize it, but by assigning null to it you are in effect initializing it. public static void main (String args[]){ String s; System.out.println(s); // compiler error variable may not be initialized } vs public static void main ...


3

In general you want to keep declaration and initialisation as close as possible to minimise exactly the type of problem you're talking about. There is also the issue of redundant initialisation where the value null you're assigning is never used which is extra code that harms readability even if the redundant assignment is optimised away by the compiler. ...


2

If you remove the try block completely then you don't need the rethrow or the throw. This code does exactly the same thing as the original: public Configuration retrieveUserMailConfiguration(Long id) throws MailException { return translate(mailManagementService.retrieveUserMailConfiguration(id)); } Don't let the fact that it comes from more seasoned ...


6

The throw new RuntimeException("cannot reach here"); statement makes it clear to a PERSON reading the code what is going on, so is a lot better then returning null for example. It also make it easier to debug if the code is changed in an unexpected way. However rethrow(e) just seems wrong! So in your case I think refactoring the code is a better ...


33

First, thanks for udpating your question and showing us what rethrow does. So, in fact, what it does is converting exceptions with properties into more fined-grained classes of exceptions. More on this later. Since I did not really answer the main question originally, here it goes: yes, it is generally bad style to throw runtime exceptions in unreachable ...


51

This rethrow(e); function violates the principle which says that under normal circumstances, a function will return, while under exceptional circumstances, a function will throw an exception. This function violates this principle by throwing an exception under normal circumstances. That's the source of all of the confusion. The compiler assumes that this ...


4

I don't know if there's a convention. Anyhow, another trick would be to do like so: private <T> T rethrow(Exception exception) { // or whatever it actually does Log.e("Ouch! " + exception.getMessage()); throw new CustomWrapperException(exception); } Allowing for this: try { return ...


7

The throw was probably added to get around the "method must return a value" error that would otherwise occur - the Java data flow analyser is smart enough to understand that no return is necessary after a throw, but not after your custom rethrow() method, and there is no @NoReturn annotation that you could use to fix this. Nevertheless, creating a new ...


11

I'd also say, you mostly answered the question by your own. I wouldn't implement it that way because it is brittle. When having that code as part of the enum class itself, it is certainly better because the problem is isolated to the implementation detail of the enum. For the problem at hand I think that solution would be 'good enough' and therefore ...



Top 50 recent answers are included