This question already has answers here:
Java's Monetary and Currency Operation - JSR 354
(2 answers)
Closed 2 years ago.
Now that the transfer ballot has taken place and jsr354-api (Java Money API) is set for inclusion in the Java distribution, will its package remain as javax.money or move to java.money?
Is the intention of this module-info.java file to allow java.money to be used as an alias?
https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/java/money/module-info.java
As a module it already is declared as "java.money" but it won't be a mandatory part of the JDK, also see this related question: Java's Monetary and Currency Operation - JSR 354
Related
I have been using the module https://www.npmjs.com/package/json-schema and have the schemas for validations in JSONSchema6.I have read that JSONSchema6 is backward compatible with JSONSchema4. Is there any utility code to convert JSONSchema6 to JSONSchema4? I need this as AWS API Gateway supports only JSONSchema4 (as per https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html#models-mappings-models)
It's not difficult to do by hand, or write a program to do so, as the differences between the two versions are straightforward. They are itemized here: https://json-schema.org/specification.html (scroll down for the links to differences between 4 and 6 for the two specification documents).
This question already has an answer here:
How can we execute WebUI feature file against multiple browsers using parallel runner or distributed testing?
(1 answer)
Closed 1 year ago.
We have a requirement to run the entire test suite more than once considering different parameters.
Say, I have 5 feature files and each has 10 scenarios. I have a requirement to run these feature files twice one after the other.
There is a way to achieve this using Scenario Outline, which will execute each scenario for the number of parameters. But can we have all the scenarios run once for the 1st parameter and then all the scenario again for the 2nd parameter. Something like an Outline at Feature level.
Please suggest.
I think this should be done at the JUnit / Java runner level. Teams usually use tags to enable or disable features at run time.
Or you can create a "wrapper" feature that calls a second feature etc.
Otherwise please assume that what you want is not directly supported, you are welcome to contribute code to Karate if needed. My honest opinion is that this is not required in a testing framework, maybe you should just write code.
EDIT - see this answer, I think you will be able to figure out an approach based on it: https://stackoverflow.com/a/60387907/143475 - and keep in mind Karate supports a "dynamic" Scenario Outline.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Swift does make a distinction between designated and convenience initializers. The documentation, however, never states why this distinction is made.
From a programmer's point of view, it seems like an extra burden: I have to think whether some initialization mechanism is "designated" or "convenience" and there are even some practical inconveniences like that I cannot call a convenience constructor of the super class which might sometimes be totally appropriate. There have to be some advantages of this concept in return. Otherwise Apple would not have introduced this feature. So what is the reason for introducing this distinction in Swift? A references to an official statements would nice.
The distinction between designated initializers and convenience initializers is not new — it's been part of the Cocoa environment for a long time. The reason for this convention is to ensure that all the internal state managed by a class is configured as intended before a subclass, or code external to the class, starts trying to use it.
Explicit initialization is one of the "safety" features of Swift. Using values before they're initialized can lead to undefined behavior (read: bugs) in C. If you declare a variable in Swift, it has to have a value. (Optionals let you fudge this a bit while still being explicit about it.) Making Cocoa's initializer chaining convention into a requirement is how Swift ensures initialization safety on top of class inheritance.
But don't take my word for it. < /LeVar> There's a great explanation of this in the series of Swift talks from WWDC — check the videos.
Totally agree on the practical inconvenience, not being able to call a convenience constructor of the super class is a total PITA...
Though I don't have any "official" answer, the conclusion I've reached is that calling a designated constructor is the only future proof way to do so.
Convenience constructors always have the possibility of being changed in future API-releases, so making the initialization of your class depend on one is highly unsafe, while the designated initializer is always going to work, no matter what changes the API is going to go through along the way...
This question already has answers here:
Error-Handling in Swift-Language
(13 answers)
Closed 8 years ago.
Is it possible to catch exceptions in Swift? Given the following code:
NSException.raise(NSRangeException,
format: "Now you've gone too far!",
arguments: CVaListPointer(fromUnsafePointer: UnsafePointer()))
Is it possible to prevent the exception from crashing the entire program? That is, what is the Swift equivalent of the following in Objective-C:
#try {
[NSException raise:NSRangeException format:#"Now you've gone too far!"];
}
It doesn't have exception handling, and this discussion in the developer forum discusses why it may be so:
but keep in mind that Cocoa and Cocoa Touch traditionally don't intend
for you to catch exceptions; they intend for you to not cause them to
be thrown in the first place. Ordinary errors should be handled with
optional types and inout NSError parameters; you should address any
situation that causes an assertion to fail (which seems to be the only
exception-throwing mechanism in Swift) by writing better code.
I believe that, as of today, Swift does not support this. It will most likely be added on future betas.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
differences between 2 JUnit Assert classes
I have two junit-4.8.1.jars in my class path and my IDE's autocomplete is giving me the following two Assert classes:
junit.framework.Assert
org.junit.Assert
Which one should I use???
To quote a duplicate...
JUnit 3.X: junit.framework.Assert JUnit 4.X: org.junit.Assert
Prefer the newest one, especially when running JDK5 and higher with
annotation support.
I prefer org.junit package in all things JUnit. It's the source URL that the code comes from. The other is legacy that's left so it doesn't break old code.
Pick one and be consistent.
Niether, use MatcherAssert and Hamcrest with assertThat instead of assertTrue / assertFalse
MatcherAssert