If you're using Go and working with Semantic Versioning you'll sometimes need to compare versions. Here we take a look at two community packages that do this.
Wondering how you can map a complex JSON structure to another JSON structure using Java? Read this awesome tutorial on mapping complex JSON structures.
Yeah, they don't really exist, but we can use polymorphism, method overloading and default methods instead to make it a bit more convenient to use our APIs. As an example, here's an event bus implementation where I can register event handlers with an optional header parameter. Bus bus = new Bus(); bus.register(event -> System.out.println("I gots an event")); bus.register((event,header) -> System.out.println("I gots an event w/ header")); Here are the dirty details on how you can do this (and - when dispatching - events, use default methods to avoid type coercion.
I’ve built a small example of running a standalone Java application that both serves static HTML, JavaScript, CSS content, and also publishes a REST web service.
Casting an instance to a type reeks of bad design. Still, there are situations where there is no other choice. The ability to do this has always been part of Java.
Mockito-Java8 is a set of Mockito add-ons leveraging Java 8 and lambda expressions to make mocking with Mockito even more compact. At the beginning of 2015 I gave my flash talk Java 8 brings power to testing! at GeeCON TDD 2015 and DevConf.cz 2015. In my speech using 4 examples I showed how Java 8 – namely lambda expressions – can simplify testing tools and testing in general. One of those tools was Mokcito. To not let my PoC code die on slides and to make it simply available for others I have released a small project with two, useful in specified case, Java 8 add-ons for Mockito. Quick introduction As a prerequisite, let's assume we have the following data structure: @Immutable class ShipSearchCriteria { int minimumRange; int numberOfPhasers; } and a class we want to stub/mock: public class TacticalStation { public int findNumberOfShipsInRangeByCriteria( ShipSearchCriteria searchCriteria) { ... } } The library provides two add-ons: Lambda matcher - allows to define matcher logic within a lambda expression. given(ts.findNumberOfShipsInRangeByCriteria( argLambda(sc -> sc.getMinimumRange() > 1000))).willReturn(4); Argument Captor - Java 8 edition - allows to use `ArgumentCaptor` in a one line (here with AssertJ): verify(ts).findNumberOfShipsInRangeByCriteria( assertArg(sc -> assertThat(sc.getMinimumRange()).isLessThan(2000))); Lambda matcher With a help of the static method argLambda a lambda matcher instance is created which can be used to define matcher logic within a lambda expression (here for stubbing). It could be especially useful when working with complex classes pass as an argument. @Test public void shouldAllowToUseLambdaInStubbing() { //given given(ts.findNumberOfShipsInRangeByCriteria( argLambda(sc -> sc.getMinimumRange() > 1000))).willReturn(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } In comparison the same logic implemented with a custom Answer in Java 7: @Test public void stubbingWithCustomAsnwerShouldBeLonger() { //old way //given given(ts.findNumberOfShipsInRangeByCriteria(any())).willAnswer(new Answer() { @Override public Integer answer(InvocationOnMock invocation) throws Throwable { Object[] args = invocation.getArguments(); ShipSearchCriteria criteria = (ShipSearchCriteria) args[0]; if (criteria.getMinimumRange() > 1000) { return 4; } else { return 0; } } }); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } Even Java 8 and less readable constructions don't help too much: @Test public void stubbingWithCustomAsnwerShouldBeLongerEvenAsLambda() { //old way //given given(ts.findNumberOfShipsInRangeByCriteria(any())).willAnswer(invocation -> { ShipSearchCriteria criteria = (ShipSearchCriteria) invocation.getArguments()[0]; return criteria.getMinimumRange() > 1000 ? 4 : 0; }); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } Argument Captor - Java 8 edition A static method assertArg creates an argument matcher which implementation internally uses ArgumentMatcher with an assertion provided in a lambda expression. The example below uses AssertJ to provide meaningful error message, but any assertions (like native from TestNG or JUnit) could be used (if really needed). This allows to have inlined ArgumentCaptor: @Test public void shouldAllowToUseAssertionInLambda() { //when ts.findNumberOfShipsInRangeByCriteria(searchCriteria); //then verify(ts).findNumberOfShipsInRangeByCriteria( assertArg(sc -> assertThat(sc.getMinimumRange()).isLessThan(2000))); } In comparison to 3 lines in the classic way: @Test public void shouldAllowToUseArgumentCaptorInClassicWay() { //old way //when ts.findNumberOfShipsInRangeByCriteria(searchCriteria); //then ArgumentCaptor captor = ArgumentCaptor.forClass(ShipSearchCriteria.class); verify(ts).findNumberOfShipsInRangeByCriteria(captor.capture()); assertThat(captor.getValue().getMinimumRange()).isLessThan(2000); } Summary The presented add-ons were created as PoC for my conference speech, but should be fully functional and potentially useful in the specific cases. To use it in your project it is enough to use Mockito 1.10.x or 2.0.x-beta, add `mockito-java8` as a dependency and of course compile your project with Java 8+. More details are available on the project webpage: https://github.com/szpak/mockito-java8
When you first learn to develop you see overly broad statements about different features to be bad, for design, performance, clarity, maintainability, it feels like a hack, or they just don't like it. In this post, I look at some of the feature people like to hate and why I think that used correctly, they should be a force for good. Features are not as yes/no, good/bad as many like to believe. Checked Exceptions I am often surprised at the degree that developers don't like to think about error handling. New developers don't even like to read error messages. It's hard work, and they complain the application crashed, "it's not working". They have no idea why the exception was thrown when often the error message and stack dump tell them exactly what went wrong if they could only see the clues. When I write out stack traces for tracing purposes, many just see the log shaped like a crash when there was no error. Reading error messages is a skill and at first it can be overwhelming. Similarly, handling exceptions in a useful manner is too often avoided. I have no idea what to do with this exception, I would rather either log the exception and pretend it didn't happen or just blow up and let the operations people or to the GUI user, who have the least ability to deal the error. Many experienced developers hate checked exceptions as a result. However, the more I hear this, the more I am glad Java has checked exception as I am convinced they really will find it too easy ignore the exceptions and just let the application die if they are not annoyed by them. Checked exceptions can be overused of course. The question should be when throwing a checked exception; do I want to annoy the developer calling the code by forcing them to think a little bit about error handling? If the answer is yes, throw a checked exception. Was Thread.currentThread().stop(e) unsafe? The method Thread.stop(Throwable) was unsafe when it could cause another thread to trigger an exception in a random section of code. This could be a checked exception in a portion of code which didn't expect it, or throw an exception which is caught in some portions of the thread but not others leaving you with no idea what it would do. However, the main reason it was unsafe is that it could leave atomic operations in as synchronized of locked section of code in an inconsistent state corrupting the memory in subtle and untestable ways. To add to the confusion, the stack trace of the Throwable didn't match the stack trace of the thread where the exception was actually thrown. But what about Thread.currentThread().stop(e)? This triggers the current thread to throw an exception on the current line. This is no worse than just using throw exception you are performing an operation the compiler can't check. These are only two worthless features but if you want to read full and detail then check Geek On Java - Hub for Android and Java
Introduction Here in this article we are trying to discuss about the finding reference object within stored procedure and also finding the calling procedure references. Hope you like it and it will be informative. What We Want Developers are writing several stored procedure almost every day. Sometimes developers need to know about the information such as what object is used within the stored procedure or from where (SP) the specified stored procedure call. This is the vital information for the developer before working on a particular stored procedure. Here we are representing a pictorial diagram to understand the nature of implementation. Now we have to answer some question 1. What are the DB Object used in Stored Procedure1 and there type. 2. In case of Store Procedure3 which procedure calls the Store Procedure3 So we are not going to read the Stored Procedure to find the answer. Suppose the each procedure have more than 3000 line. How We Solve the Answer To solve the answer first we take the example and create an example scenario to understand it. -- Base Table CREATE TABLE T1 (EMPID INT, EMPNAME VARCHAR(50)); GO CREATE TABLE T2 (EMPID INT, EMPNAME VARCHAR(50)); GO --1 CREATE PROCEDURE [dbo].[Procedure1] AS BEGIN SELECT * FROM T1; SELECT * FROM T2; EXEC [dbo].[Procedure3]; END GO --2 CREATE PROCEDURE [dbo].[Procedure2] AS BEGIN EXEC [dbo].[Procedure3]; END GO --3 CREATE PROCEDURE [dbo].[Procedure3] AS BEGIN SELECT * FROM T1; END GO Now we are going to solve the question What are the DB Object used in Stored Procedure1 and there type. sp_depends Procedure1 In case of Store Procedure3 which procedure calls the Store Procedure3 SELECT OBJECT_NAME(id) AS [Calling SP] FROM syscomments WHERE [text] LIKE '%Procedure3%' GROUP BY OBJECT_NAME(id); Hope you like it.
CORE
