Adam Bien's Weblog

You searched this site for "eclipse rcp". 271 entries found.

You can also try this same search on Google.

Showing 21 - 30 of total 271 search results

« Previous page | Main | Next page »

Using MicroProfile Rest Client For System Testing

A JAX-RS resource:


@Path("ping")
public class PingResource {

    @GET
    public String ping() {
        return "Enjoy Java EE 8!";
    }

}    
...can be system tested (checkout: http://javaeetesting.com) with MicroProfile Rest Client by describing the resource with an interface:

import javax.ws.rs.GET;
import javax.ws.rs.Path;
        
@Path("/restclient/resources/ping")
public interface PingClient {

    @GET
    String ping();
}
    
...and creating a proxy implementation with RestClientBuilder:

import java.net.MalformedURLException;
import java.net.URI;
import org.eclipse.microprofile.rest.client.RestClientBuilder;
import static org.junit.Assert.assertNotNull;
import org.junit.Test;


public class RestClientTest {

    @Test
    public void init() throws MalformedURLException {
        URI baseURI = URI.create("http://localhost:8080");
        PingClient client = RestClientBuilder.newBuilder().
                baseUri(baseURI).
                build(PingClient.class);                
        assertNotNull(client);
        String result = client.ping();
        assertNotNull(result);
    }
}

You will need the following dependencies to run the system test from your IDE / CLI:


<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-api</artifactId>
        <version>8.0</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-rs-mp-client</artifactId>
        <version>3.3.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>    

Project created with javaee8-essentials-archetype, the 3kB ThinWAR was built and deployed with: wad.sh in 2940ms

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

Optimizing for Humans, Not Machines--airhacks.fm podcast

Subscribe to airhacks.fm podcast via: RSS iTunes

An airhacks.fm conversation with Simon Harrer (@simonharrer) about:
Amstrad Laptop, first line of VB code was a commercial one, customers two desks away, Scheme is an excellent language to learn programming, Java is great - mainly because of the tool support, Eclipse was the first opensource IDE with decent refactoring support, Bamberg is the home of Schlenkerla, teaching is the best way to learn, therefore teaching is selfish, building portals for students with PHP and Joomla, building e-commerce shops for students with Ruby on Rails, 2006 everything had to be Rails, PhD about choreography and distributed transactions, too high expectations on workflow and rule engines, workflow engines are for developers and not for business people, central process view is still desirable, startups with Bosch, in Germany it is hard to find developers who are willing to join startups, Simon works for InnoQ and Stefan Tilkov, Computer Science University of Bamberg, the pragmatic book: Java by Comparison by The Pragmatic Bookshelf, in streams there are no exceptions, over-abstractions cause trouble, reviewing the code of thousands of students for six years, it is unusual for universities to promote pragmatic code, be strict about adding external libraries, clear separation between infrastructure and business logic helps with clean code, moving domain specific libraries into the infrastructure, human centered code, optimizing for machines, not for humans is problematic, writing bad code is often not intentional, "Abstract, If, Impl, Default, Bean Conventions - Just For Lazy Developers", don't write for reuse, reuse rarely happens, reuse as motivator for bad abstractions, do repeat yourself, than refactor, "How To Comment With JavaDoc", Book: Java by Comparison, Become a Java Craftsman in 70 Examples.
Simon Harrer on twitter: (@simonharrer).

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

MicroProfile: @Counted vs. @Gauge

MicroProfile Metrics comes with @Counted and @Gauge annotations:


@Path("ping")
public class PingResource {

    @GET
    @Counted(monotonic = true)
    public String ping() {
        return "Enjoy MicroProfile and Java EE 8";
    }

    @Gauge(unit = "correctness")
    public int answer() {
        return 42;
    }
}


According to the microprofile specification, the @Counted annotation:

"Denotes a counter, which counts the invocations of the annotated object."
with default unit: MetricUnits.NONE

In contrary, the @Gauge annotation:

"Denotes a gauge, which samples the value of the annotated object."
no default, must be supplied by the user.

Typical output (curl -H"Accept: application/json" http://localhost:9080/metrics/application):


    {
        "com.airhacks.ping.boundary.PingResource.answer":42,
        "com.airhacks.ping.boundary.PingResource.ping":1
}  

The @Counted annotation automatically counts the total invocations of the annotation method (monotonic=true), or the amount of parallel invoked methods at any time: (monotonic=false) (ConcurrentGauge will probably replace: (monotonic=false)).

On the other hand, the @Gauge exposes the return value of the annotated method as a metric.

@Gauge annotations are used to expose metrics with dedicated methods. The values have to be provided by the developer (e.g. number of orders in the DB) and the method is going to be invoked by the metrics infrastructure.

Business methods can be additionally annotated with: @Counted and their invocation count is going to be exposed as a metric.

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

More Conventions with Maven.next--airhacks.fm podcast

Subscribe to airhacks.fm podcast via: RSS iTunes

An airhacks.fm conversation with Robert Scholte (@rfscholte) and Sebastian Daschner (@DaschnerS) about:

"Convention over Configuration and Maven, strategies for the "default", dependency versions to "apache" maven plugins, maven default behaviours, configuration hierarchies, Maven and CI/CD like Jenkins, command line options, pom elements, pom properties, the Java EE-stic approach to Maven, upgrading or downgrading, Maven and Java 11+, Maven.next features, effective POMs, accessing default versions of the plugins, making Maven configuration as lean as Java EE, Configuration by Exception, listing the current default plugin versions, specifying the versions in POM and overriding them with CLI and system properties."

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

MicroProfile: @Metered vs. @Timed

MicroProfile Metrics comes with @Metered:


@Path("metered")
public class MeteredResource {

    @GET
    @Metered(name = "ping_metered")
    public String ping() {
        return "metered " + System.currentTimeMillis();
    }    
}

and @Timed:

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import org.eclipse.microprofile.metrics.annotation.Timed;

@Path("timed")
public class TimedResource {

    @GET
    @Timed(name = "ping_timed")
    public String ping() {
        return "timed " + System.currentTimeMillis();
    }    
}

annotations.

According to the microprofile specification, the @Metered annotation:

"Denotes a meter, which tracks the frequency of invocations of the annotated object."
with default unit: "per second"

In contrary, the @Timed annotation:

"Denotes a timer, which tracks duration of the annotated object."
with default unit: nanoseconds.

The output after a brief stress test:


{
    "com.airhacks.metrics.boundary.MeteredResource.ping_metered": {
        "count": 10,
        "fiveMinRate": 2.0,
        "oneMinRate": 2.0,
        "fifteenMinRate": 2.0,
        "meanRate": 1.1044614253525735
    },
    "com.airhacks.metrics.boundary.TimedResource.ping_timed": {
        "fiveMinRate": 1.9355159413581935,
        "max": 202722,
        "count": 20,
        "p50": 7658.0,
        "p95": 202722.0,
        "p98": 202722.0,
        "p75": 8228.0,
        "p99": 202722.0,
        "min": 5852,
        "fifteenMinRate": 1.9780232116334415,
        "meanRate": 0.9988264886468711,
        "mean": 23041.21494920979,
        "p999": 202722.0,
        "oneMinRate": 1.7175127368841634,
        "stddev": 47095.42163982647
    }
}    

The @Timed is useful to track the time spent in methods. Particularly the max attribute is useful to track possible performance problems.

On the other hand, the @Metered annotation exposes frequency / throughput, which can be directly used in stress tests / torture tests as thresholds.

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

Productive Clouds 2.0 with Serverless Jakarta EE--airhacks.fm podcast

Subscribe to airhacks.fm podcast via: RSS iTunes

An airhacks.fm conversation with Ondrej Mihályi about:

starting programming with Logo, Pascal, C, Pentium 386, Scratch, minecraft, delphi and Java, pointers and destructors, participating in programming competitions, learning programming with Java, GWT, JSF and Primefaces over GWT, Eclipse, NetBeans, Java EE 5 introduced Dependency Injection (DI), Nitra is the oldest City in Slovakia, "Enterprise needs to be complicated", code generation with xdoclet in J2EE, simplifications with Java EE 5 in 2006, starting at Payara, running a JUG in Prague, Sun Grid Engine, serverless WARs, ideas for productive Clouds 2.0, serverless Java EE applications, early clouds with Google App Engine, Docker and Kubernetes for application packaging, making cloud services injectable, AWS lambdas are distributed commands, improving developer experience in the clouds with DI instead of singletons, Payara Source To Image (S2I) for server configuration in the clouds, separating the immutable servers from application logic with docker and clouds, cloud vendors are evaluating microprofile, repeatable and reproducible builds with Java EE in private clouds, Java EE deployment model became accidentally "cloud ready", with ThinWARs there is nothing to (security) scan, with ThinWARs there is no conceptual difference to lambda functions, cloud vendors participation in Jakarta EE, GraalVM and native compilation. Ondro's blog and @OndroMih / twitter.

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

J2EE, Java EE, Jakarta EE, MicroProfile - and The Release Cadence

J2EE was released every 2 years, Java EE every 3-4 years:

  1. J2EE 1.2 (December 12, 1999)
  2. J2EE 1.3 (September 24, 2001) (2 years)
  3. J2EE 1.4 (November 11, 2003) (2 years)
  4. Java EE 5 (May 11, 2006) (3 years)
  5. Java EE 6 (December 10, 2009) (3 years)
  6. Java EE 7 (May 28, 2013) (4 years)
  7. Java EE 8 (August 31, 2017) (4 years)
[from: https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#cite_note-4]

With a Jakarta EE release in 2019 (status), the release cadence would come back to 2-years cycle of J2EE days. A Jakarta EE release in 2020 would be still aligned with the Java EE cadence. However: Jakarta EE plans to have more frequent releases.

All major application servers are already supporting both: Java EE 8 and MicroProfile at the same time (see matrix).

MicroProfile and most application servers are already released quarterly. Now you can write your ThinWAR applications against the stable Java EE 8 API and enjoy new MicroProfile features several times a year.

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

"Jakarta EE" Eclipse GlassFish 5.1 Docker Image is Available from Docklands and from Dockerhub

Eclipse GlassFish 5.1 docker image is available as Dockerfile from Docklands (glassfish) and docker image directly from dockerhub: airhacks/glassfish.

All projects created with the Java EE 8 Essential Archetype ship with a Dockerfile already pointing to airhacks/glassfish.

To create a project run:

mvn archetype:generate -DarchetypeGroupId=com.airhacks -DarchetypeArtifactId=javaee8-essentials-archetype -DarchetypeVersion=0.0.2 -DgroupId=com.airhacks -Dversion=0.0.1 -Darchetype.interactive=false --batch-mode -DartifactId=eclipsefish

to build:


cd eclipsefish
mvn clean install && docker build -t airhacks/eclipsefish .    
    

to run:

docker run -d -p 8484:8080 --name thinfish airhacks/thinfish

...and do smoke test:

curl http://localhost:8484/thinfish/resources/ping output:

HTTP/1.1 200 OK
Server: GlassFish Server Open Source Edition  5.1.0 
X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition  5.1.0  Java/Oracle Corporation/1.8)
Content-Type: text/plain
Content-Length: 16

Enjoy Java EE 8!%          

Checkout wad.sh for continuous deployments.

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

Maven Commitment -- a Podcast Episode with Robert Scholte

Subscribe to airhacks.fm podcast via: RSS iTunes

An airhacks.fm conversation with Robert Scholte (@rfscholte) about:

"CGI Java Netherlands, Maven Invoker, never mvn clean, apache maven commitment and committing, Watch and Deploy (wad.sh), Atari 800XL, hacking basic with 10 years, peeks and pokes, MS DOS and startup screens, JDK 1.4, illegal generics, Java EE on JBoss was good, not the build process, intelligent builds with Maven, Apache Jelly, Jason van Zyl, Maven vs. Ant, loosing information with Google Web Toolkit (GWT), parsing Java with qdox, Paul Hammant, Maven Release Plugin "Fix It" video , Using Java console for passwords and the bash history, Java 6 and password encryption, clarifying the development of Maven plugins (default values and expressions), going from Maven 1 to Maven 2 and the respository structure, from Maven 2 to Maven 3, Eclipse IDE wanted Maven 3, Maven 3.7 is (probably) going to optimize downloads, there will be no Maven 4, Maven 5 will rely on pom's model version 5, splitting pom into local and remote part, writing POM in alternative formats, takari.io, takari polyglot, Maven extensions,plexus classworlds is Maven's OSGi, what is the default version of apache Maven plugins, is it possible to pull "latest" apache maven plugins, Maven extensions for plugin version configuration, clean poms, WAD runs all the time, using GraalVM to make a native version of Maven, Maven Archetype always generates parents, Up For Graps, Maven 5.x: How to be prepared for the future?, Maven is probably the only build tool, with tight integration with Java Platform Module System, Gradle, Apache Buildr is EoL, Bezel, Apache Ant is not dead and supports Java 11, Robert is a freelancer, CEO of SourceGrounds and available for hire."

See you at Web, MicroProfile and Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home: airhacks.io.

2019 Predictions

  1. Oracle's move to opensource the entire JDK with tooling (even Java Mission Control) opened the market for third party companies like e.g. Amazon, RedHat or Azul Systems to provide support. Also innovations like GraalVM keep Java interesting. Java popularity in OpenSource and Tiobe Language index should grow in 2019.
  2. Serverless / Function as a Service is a fine-grained (Message Driven Bean / Command Pattern - like), interaction model. FaaS is widely overused, which causes complex applications to be designed as distributed command pattern architecture. Such applications are hard to build, deploy, debug and profile. It might be too early for a backlash, but I would expect at least some conference talks with titles like: "How to survive FaaS".
  3. Kotlin is the programming language of choice for android development, what also helps with general adoption. Kotlin could become more popular in 2019, except Google manages to release Fuchsia and Flutter and does not push Dart.
  4. There is no logical explanation for building and deploying megabyte-sized WARs/JARs, when only a few kB change in each iteration. ThinWARs gained popularity in 2018, in 2019 they could become even more popular. Making microprofile available on stock Java EE 8 application servers, makes the deployment units even smaller (microdeployments), faster and so more productive.
  5. Frequent releases, interesting innovation, conference presence will make microprofile even more popular.
  6. Jakarta EE is gaining momentum and the project makes significant progress. The availability of jakartablogs.ee, JNoSQL and Eclipse GlassFish 5.1.0 will keep Jakarta EE in the news.
  7. There is a common perception, that MicroProfile only works on esoteric runtimes. However, most "stock" application servers support Java EE 8 and MicroProfile without any additional setup, download or configuration. The popularity of Java EE / Jakarta EE + MicroProfile (fusion) should grow in 2019.
  8. After private cloud offerings (shipping servers to datacenters) Amazon's Outpost, Google's GKE, Microsoft's Azure Stack, private clouds should become more popular in 2019. I was too early with the predictions 10 years ago, but now you can buy private clouds from public cloud vendors.
  9. Microsoft, Google, Mozilla and others committed to use MDN as the canonical resource to describing WebStandards and Web API. The general availability of WebComponents, Service Workers, Grid Layout, Fetch API, WebSockets, and ES 6 modules makes JavaScript frameworks optional. In 2019 I expect more projects moving away from JavaScript frameworks into vanilla WebStandards.
  10. The innovation in Java and frequent train releases, will make other JVM languages like e.g. Scala, Clojure less popular.
  11. The use of external frameworks will further decrease in enterprise. Netflix stopped developing Hystrix, which will force many enterprise projects to migrate away from massive Hystrix-boilerplate code, to either MicroProfile Fault Tolerance or resilience4j. Because the ecosystem is so rich, I expect more projects to collapse. 2019 could become the year of YAGNI.
  12. Microsoft discontinued Edge and is going to use chromium what is a big move towards WebStandards in enterprise projects and also a reason to refactor exising projects by removing optional frameworks.
  13. kubernetes became the de-facto standard orchestrator. OpenShift is a popular kubernetes distribution, which is already surprisingly well adopted within enterprises. In 2019 OpenShift could gain further adoption, also driven by the IBM's acquisition of RedHat.
see also my 2018 predictions. 2018 predictions were already revisited in: 58th airhacks.tv

...the last 150 posts
...the last 10 comments
License