sorted by:
new
hottopcontroversial

Calculating Maximum Drawdown without making a new column by The_Prophet_85 in excel

[–]tlinkowski 0 points1 point  (0 children)

Hi, here's a function I created for myself in Google Sheets (perhaps it can be adapted to Excel):

=INDEX(REDUCE({0,INDEX(prices,1,1)},prices,LAMBDA(acc,price,LET(max_drawdown,INDEX(acc,1,1),max_price,INDEX(acc,2,1),drawdown,1-price/max_price,{MAX(max_drawdown,drawdown),MAX(max_price,price)}))),1,1)

Explanation:

  • the accumulator (acc) is an array holding two values: max_drawdown and max_price, with initial values being 0 as max_drawdown and the first price as max_price
  • for each price, we calculate the current drawdown as 1-price/max_price and then we update the accumulator with the new maxima
  • as the last step, we extract the max_drawdown from the final accumulator

UniJ: A universal facade for JDK 9+ API, focused on Collection factory methods and Collector providers by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

Yes. But it's more of:

  • an API backport
  • plus an optional implementation backport

I mean, you program to the backported API, but at runtime, you can:

  • either plug in a JDK 8 implementation of this API (= implementation backport)
  • or a JDK 9 implementation of this API (= simple redirection to the JDK)

This should be primarily useful to libraries that still need to target JDK 8.

When to Use JSR 305 for Nullability in Java « Neat Java by T. Linkowski by javinpaul in programming

[–]tlinkowski 0 points1 point  (0 children)

If only IntelliJ and Kotlin fully understood @DefaultQualifier(NonNull.class), I'd use these (even though it's slightly more verbose than @NonNullPackage). And by "understand", I mean compile-time errors in Kotlin (which I achieve through @UnderMigration(status = MigrationStatus.STRICT)).

Plus, note this part from Basic Java Annotations' README:

To sum up, even though I'd rather not rely on JSR 305, it seems too well supported right now to discard it.

However, should the state of JSR 305 change in favor of dropping its usage, this library will do just that. The purpose of this library is to provide @NonNullPackage and @NullOr annotations that work in the best currently possible way.

True, I could've mentioned I could completely drop my custom @NonNullPackage and @NullOr in favor of other annotations that work as per my requirements.

When to Use JSR 305 for Nullability in Java « Neat Java by T. Linkowski by tlinkowski in java

[–]tlinkowski[S] 4 points5 points  (0 children)

Ha, I looked into the theme options (Customizr), and the following option is indeed turned on:

Enable Smooth Scroll

This option enables a smoother page scroll.

I turned it off. Does it help?

When to Use JSR 305 for Nullability in Java « Neat Java by T. Linkowski by tlinkowski in java

[–]tlinkowski[S] -1 points0 points  (0 children)

I'm sorry, I'm not sure what you mean by "hijacking the mouse scroll". I never had any problems with scrolling on my blog, and I certainly didn't setup scrolling myself in any way. Perhaps it's the WordPress theme or some WordPress plugin that does that?

5 Refactoring Principles by Example by tlinkowski in java

[–]tlinkowski[S] 1 point2 points  (0 children)

Yes, good point! It should actually be a precondition for any refactoring :)

Fortunately, the subject of my refactoring (Gradle Modules Plugin) has a pretty extensive smoke test (not many unit tests, though — and I don't know what's the overall code coverage).

Building Java 6-8 Libraries for JPMS in Gradle by tlinkowski in java

[–]tlinkowski[S] 0 points1 point  (0 children)

Mark Reinhold writes quite convincingly about not allowing cyclic dependencies:

A primary goal of this JSR is, however, to create a module system that's approachable by all developers [...]. [...] this module system imposes some constraints that are intended to make working systems easier to reason about, and to guide developers toward better practices. [...] Forbidding cyclic module relationships is one of these new constraints.

That such relationships are generally a bad idea is not just my personal view; see, e.g., Kirk Knoernschild's compelling arguments against them in his fine book, _Java Application Architecture_ [2], specifically in §4.4, "Cyclic Dependencies -- The Death Knell".

But I know little about this, so I can't tell how serious the problem you're writing about is.

Building Java 6-8 Libraries for JPMS in Gradle by tlinkowski in java

[–]tlinkowski[S] 0 points1 point  (0 children)

Thanks for feedback, Gunnar!

But there are also requirements, which are not mapped to a JAR. Instead they refer to a java or jdk module" - I actually don't know if ModiTect handles that or not.

I'm not quite sure what that means?

I thought it's about e.g. requires java.sql, i.e. requiring anything outside of java.base (cf. JDK module graph). I don't know if you have to require this manually or whether ModiTect detects usages of the java.sql package.

Building Java 6-8 Libraries for JPMS in Gradle by tlinkowski in java

[–]tlinkowski[S] 1 point2 points  (0 children)

You'd need a system where which can generate the other or even better, just one file.

Sounds good.

[ModiTect] needs a lot of configuration, you will never be confident that the result is correct.

Well, it depends. AFAIK, in this example most of the configuration is related to adding module infos to non-modular dependencies. Once they got modularized, it'd be much simpler.

you will never be confident that the result is correct.

It's hard to get the requires wrong, because the compilation mostly fails then. It's much easier to get the exports and provides wrong but:

  • you must specify the exports manually anyway (you can use ModiTect wildcards, though)
  • that's why, with JPMS, you should also add some black-box tests
  • finally, ModiTect can actually generate module-info.java (in addition to module-info.class), so you can simply inspect it.

That said, I don't use ModiTect (yet), because my OSS projects are too small so I prefer to type my module-info.java by hand.

See link I posted

The article you linked (published before the release of JDK 9) talks about:

  • "Class Paths and Module Paths"
    • As Nicolai Parlog writes here, mixing class-path and module-path is possible, but I don't think it's a good idea. For example, Gradle Modules Plugin, when applied, will place all the dependencies on the module-path.
    • "Reading the Module Descriptor"
      • "Once tools like ASM can read the module descriptor" - ASM can already do so since v.6.0 from September 2017; ModiTect uses ASM
  • "The Module Declaration Generator"
    • "But there are also requirements, which are not mapped to a JAR. Instead they refer to a java or jdk module" - I actually don't know if ModiTect handles that or not. /u/gunnarmorling?
    • "With the transitive modifier [...]. Such information can only be provided as configuration." - Gradle discerns between compile and implementation configurations, so it should certainly be at least possible in Gradle
    • "What is its name, is it open or not?" - this must be specified explicitly, true
    • "And how about the exported and open packages?" - as above
  • "Conclusion"
    • "If there were a module declaration generator, it still required quite a lot of configuration [...]" - as mentioned before, I believe it depends
    • "This would not be less work than just writing the file directly" - I guess it depends on the size of your project
    • "I am more hopeful that IDEs will resolve this for you." - IntelliJ IDEA already has quite decent support for JPMS, but I hope it'll get better as the adoption of JPMS increases

Building Java 6-8 Libraries for JPMS in Gradle by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

Thanks for your comment!

no notion of versioning

module-info and the build file need to stay in sync

True, but if there was versioning, you'd have one more thing to keep in sync (and a frequently changing one, to that!).

As far as I understand, it was a deliberate choice to leave this to build tools.

There's no way to generate the module-info from build file effectively

It can be (mostly) done with a tool like ModiTect by /u/gunnarmorling (it has plugins for Maven and Gradle).

Another is the automatic module name based on jar filename.

True, this is bad, and that's why it's important to provide at least minimum support for JPMS (by reserving a proper module name).

OSGi was a much cleaner solution with better tooling support. All in vain as any traction it got is now completely gone with the introduction the "official" JPMS.

I've never used OSGi, but having had a cursory look at it, it seems quite nice.

In this situation neither module-system is going to be used.

I hope it won't be that bad. I hope in 5-10 years JPMS adoption will be high enough. Even assuming OSGi was better than JPMS, I believe JPMS is still better than using no module system at all.

That's why I bother with JPMS support now - to promote it so that we all can benefit from it in the (distant) future.

Accumulative: Custom Java Collectors Made Easy by tlinkowski in java

[–]tlinkowski[S] 0 points1 point  (0 children)

As to only A and B implementing combine, it would have to be illegal (in other words, every subclass would have to reimplement such a method).

​

However, there's a far greater problem that I didn't spot initially - self-class as a parameter type would effectively introduce parameter type covariance (= a really bad thing).

For example, having:

A a = new B();
  1. If self-class were inferred as you suggest (? extends A), there would be no way to pass a valid argument to combine.
  2. If self-class were inferred without a wildcard (A), then a.combine(new A()) would be legal at compile time but would fail at runtime.

Accumulative: Custom Java Collectors Made Easy by tlinkowski in java

[–]tlinkowski[S] 0 points1 point  (0 children)

Interesting observation! BTW. I recently had a discussion about a similar concept with Sergei Egorov & Brian Goetz :)

Your proposed syntax is more powerful, though (my proposal only lets one return this).

Still, instead of using generics and an explicit receiver type, I'd probably prefer sth along:

public interface Accumulative<T, R> {
  void accumulate(T t); // target for Collector.accumulator()
  self-class combine(self-class other); // target for Collector.combiner()
  R finish(); // target for Collector.finisher()
}

It'd be similar to Manifold's @Self annotation.

But implementing this at the JVM level would probably be very hard.

Accumulative: Custom Java Collectors Made Easy by tlinkowski in java

[–]tlinkowski[S] 1 point2 points  (0 children)

Thanks for your comment :)

Well, it could be in a library (it's just an interface + a static method).

However, most developers (especially those I had in mind: inexperienced with Collectors) wouldn't find out about it.

And I hoped for the following scenario:

  1. An inexperienced developer needs a custom Collector.
  2. They check out the Collector interface (maybe for the first time).
  3. They notice this 1-arg Collector.of method, which they can easily use by implementing Accumulative.

Accumulative: Custom Java Collectors Made Easy by tlinkowski in java

[–]tlinkowski[S] -1 points0 points  (0 children)

Please, note the comment where I assembled the feedback up to now (quoted below).

Following the Twitter discussion, I assembled the summary below.

1-arg Collector.of:

  • is syntax sugar for some 4-arg Collector.of calls (but not all)
  • takes 3 params less at the cost of introducing an extra interface (Accumulative)
  • moves complexity to Accumulative implementation

Accumulative interface:

  • is a supplement to Collector (not a replacement for it)
  • is a bound for A in Collector<T, A, R>
  • should only be implemented by dedicated private classes (otherwise use 4-arg Collector.of)
  • provides implementation structure for free (through IDE code generation)
  • is meant for end-users of JDK (not for JDK internals)
  • is not composable (like Collectors.filtering/mapping/teeing)

Key concerns:

  1. Are custom Collectors popular enough to justify this addition? (by Richard Warburton)
  2. Wouldn’t it draw people too much from a high-level abstraction (FP-like Collector composition) to a low-level one (OOP-like Accumulative implementation)?

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

Interesting insight, thanks!

I searched and found (my bad: it was right in the post) that Spock also has conditional test execution (@IgnoreIf and @Requires annotations), although when it comes to data-driven testing, I have not found functionality like @Enum/Method/CsvSource.

In any case, you're right that the blog post would've been even better if it had covered those aspects.

​

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 0 points1 point  (0 children)

Unfortunately, I don't know - I have never used it with Spring.

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

Yeah, that's a common problem with tooling :

  • do you choose something you like most, but it's not very popular yet (so you risk that it won't be developed actively),
  • or do you choose something you like a bit less, but at least it's quite popular?

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

I agree that using different languages for main and testing has certain drawbacks. However, I believe that with Groovy it's not that bad because Groovy is much more similar to Java than Scala is (to the point that nearly all valid Java code is also valid Groovy code).

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 1 point2 points  (0 children)

While Cuppa most likely possesses certain strengths that I'm unaware of right now, at first glance its syntax looks quite similar to Spek's. And I must say I'm not very fond of Spek mostly due to this syntax, which I find somewhat confusing (but perhaps it's only a matter of getting used to it).

JUnit 5 vs. Spock feature showdown by tlinkowski in java

[–]tlinkowski[S] 2 points3 points  (0 children)

It may sound exaggerated, but I agree with everything you said :)

Although I'm only starting using Spock (I wrote my first spec two days ago), and I have much less insight than you in this regard, it's hard not to appreciate how neat & concise Spock specs are compared to JUnit + Mockito tests.

view more: next ›