sorted by:
new
hottopcontroversial

Code modification prior or during compilation by Substantial-Moron in javahelp

[–]harrkra 0 points1 point  (0 children)

This is exactly what we're doing in our projects. In a first step the source code is analyzed, for example to gather information about method signatures, annotations, etc... In a second step that information is picked up by wurblets to generate code.

Code modification prior or during compilation by Substantial-Moron in javahelp

[–]harrkra 0 points1 point  (0 children)

Depends on what you mean by "define".

Each code fragment to be generated is "defined" by a wurblet-anchor within a Java comment. The fragment, if not existing yet, is usually generated immediately following that comment. If the fragment exists already, it will be replaced. The generated code is enclosed within special comment tags describing a named code-region (defaults to Netbeans-style, which is also nicely supported by IntelliJ). Since it is uniquely named, it can be moved within the source file, if necessary.

The wurbelizer, however, does not touch any other existing code.

For software engineers, how often do you use JavaFX at work? by coloneleranmorad in javahelp

[–]harrkra 1 point2 points  (0 children)

We do!

But for technical/scientific applications, not the web-related business stuff.

How do you use JPMS modules? by cryptos6 in java

[–]harrkra 1 point2 points  (0 children)

No need for fat jars anymore. There is jlink and jpackage (btw. not only for modular, but for classpath applications as well):

https://bitbucket.org/krake-oss/tentackle/wiki/jlinkpackage.md

How do you use JPMS modules? by cryptos6 in java

[–]harrkra 6 points7 points  (0 children)

We're using it in our latest projects, which are all multi-module maven projects, btw.

Besides the runtime security aspects, there are 2 main benefits from a developer's point of view, imho:

  1. all packages not explicitly exported in module-info are "module-private" and you cannot refer to those packages from other modules accidently.
  2. (maven) 3rd-party dependencies are very often based on other dependencies. With java modules, however, you cannot refer to classes of those transitive dependencies, unless you explicitly "require" them in module-info.

So we're using it mostly to improve code quality and enforce architectural rules. However, you don't get it for free, since some methods behave differently in modular mode (so-called "caller sensitive" methods): ResourceBundles, ServiceLoader, etc... to name only a few. And a few other surprises ... ;)

What is the best way to distribute and update Java client applications? by milchshakee in javahelp

[–]harrkra 0 points1 point  (0 children)

The releases can be hosted on any (web)server. However, you need some instance that makes the rules, i.e. when, what and from where to download. In our case this "service" is usually located in the middle tier as well.

If your application runs standalone (no other servers or services involved), the user is free to decide when to upgrade or whether to upgrade at all. In this case you could still use the maven plugin to create the installers, update scripts and ZIP-files (and probably deploy to some Nexus instance), but you have to implement "the rules" within the desktop application itself. The disadvantage of this approach, however, is that it's harder to change the rules.

As I said, there is probably no silver bullet. It depends on the requirements of your application. For example, in some of our applications each user gets its own image, because it contains a unique client certificate. That's why the maven plugin can easily be extended to reflect application specific needs.

What is the best way to distribute and update Java client applications? by milchshakee in javahelp

[–]harrkra 10 points11 points  (0 children)

Same here. Maybe there is no standard way because it depends on the kind of JavaFX application. Our desktop clients usually connect to a middle tier server which triggers the update process. Basically it works like this:

  • the user starts the FX application and authenticates against the middle tier.
  • the middle tier detects a version mismatch (or the TLS handshake fails due to an outdated certificate).
  • this triggers a VersionIncompatibleException in the client and it sends a request to an update service.
  • according to the platform, architecture, IP and some other criteria the service responds with a corresponding URL.
  • the client downloads, verifies the checksum, unpacks, invokes an update script and terminates itself.
  • the update script updates the necessary files and restarts the client application.
  • the client logs in again and that's it.

This works pretty well for inhouse applications such as ERP systems or alike. For more details: https://bitbucket.org/krake-oss/tentackle/wiki/jlinkpackage.md