steve_barham

I did something similar a few years back, with a slightly different approach to declaration, using interfaces to denote the layout of the struct. Mutation was opt-in by exposing setters using the (of the time) standard JavaBeans layout and an annotation processor took care of the codegen of an implementing class, which could be used where you wanted an on-heap box of an off-heap structure.

One benefit of this approach was that by using the interface as the type you could fairly easily support a flyweight pattern, reducing GC pressure when working with large off-heap collections. The parallels between stateless interfaces and offheap structs was also quite pleasing.

I'd love to see a similar effort using more modern techniques than Unsafe et al.

They did have time-choice; they chose to allocate a substantial portion of it to having children.

Click Here to Skip Intro

Sure you can. Ctrl-Shift-A, type 'keymap', and you get a handy popup (same size as the 'recent files' switcher available with Ctrl-E) with the defined keymaps ready to use. Few seconds, maximum.

Regarding the 'checked exception issue'; an alternative technique to the method-wrapping-lambda is to use a default interface method to implement the non-exceptional interface, which delegates to the possibly-exceptional method. It's a bit fussy, but it's a nice technique to know:

    interface IOConsumer<T> extends Consumer<T> {
        @Override
        default void accept(T t) {
            try { 
                maybeAccept(t); 
            } catch (IOException ie) { 
                throw new RuntimeException(ie); }
            }

        void maybeAccept(T t) throws IOException;
    }

        try (Writer writer = new StringWriter()) {
            final IOConsumer<String> ioPrinter = writer::write;

            // hand ioPrinter off to something that expects a Consumer<String>
        }

    static <T> Consumer<T> maybe(IOConsumer<T> consumer) {
        return consumer;
    }

    try (Writer writer = new StringWriter()) {
        final Consumer<String> printer = maybe(writer::write);
    }

Not Invented Here syndrome, at all? Sure, I understand wanting to use Python for templates rather than relying on an external application. But why ignore the many, many existing template libraries? Some of those libraries have solved problems which you don't realise you have yet.

Case in point, are you planning to support this 'dead simple' template language for users of your hosting site? If so, what happens if I try to include something outside the site root, in a Dropbox area which I control? https://github.com/braceio/tags/blob/master/tags/tags.py#L13

Source? If you look at expenditure on pharmaceutical research and development in the UK vs. the US, you see that 9% of global R&D expenditure is UK based, and 49% is US based.

This very closely matches the population differences between the UK and US (at a population of 63M vs. 317M).

Within Europe, the UK represents 23% of all pharmaceutical R&D funding; France is only slightly lower at 20% of the total.

http://en.wikipedia.org/wiki/Pharmaceutical_industry_in_the_... http://en.wikipedia.org/wiki/Demographics_of_the_United_Stat... http://en.wikipedia.org/wiki/Demographics_of_the_united_king...

"I'm pretty sure in 10 years time I will read a post about how you need to switch your horrible old messy AngularJS app to XYZ which will fix all your problems."

More likely given the rapidity of churn in the JavaScript world, in about 10 weeks.

There's a certain irony in the poster dismissing Java with one hand:

    "In effect, to the developer it 'feels like writing Java,' which as we all know, is a terrible feeling"

    <graph class="visitor-graph"> 
        <axis position="left"></axis> 
        <axis position="bottom"></axis> 
        <line name="typical-week" line-data="model.series.typicalWeek"></line> 
        <line name="this-week" line-data="model.series.thisWeek"></line> 
        <line name="last-week" line-data="model.series.lastWeek"></line> 
    </graph>

    <cewolf:chart id="line" title="Page View Statistics" type="line" xaxislabel="Page" yaxislabel="Views"> 
        <cewolf:data> 
            <cewolf:producer id="pageViews"/> 
        </cewolf:data> 
    </cewolf:chart>

Lest angry Java-haters accuse me of trying to extol the virtues of JSPs, taglibs et al, this is not the point of my post. I'm indicating the commonalities between two modes of development separated by more than a decade, which in the churnful world of technology might as well be separate geologic eras.

It's interesting to compare these two things (particularly when a prior effort has fallen by the wayside) to determine if you are implementing the same concept in a new guise, or if you are removing the issues that people had with prior models which led to their lack of use.

I'm not sure why this article has been published in 2013; it seems to stem from the late 1990s, with it's speculation on the widespread use of technology 'by 2000':

"I wouldn’t want to push back the gestational age limit,” Shaffer says. ”I want to eliminate the damage.” He says he believes that this technology may become the standard. By the year 2000, these techniques may be available in large centers"

Picking one of the researchers named in the project (Yoshinori Kuwabara) suggests that the article originates somewhere between 1997 and 2000.

http://www.mhhe.com/biosci/genbio/olc_linkedcontent/bioethic...

- describes his artificial womb technology from 1997 - published in 2000 but indicates that the researcher has died

There is a detailed analysis of the feasibility of such systems in general on the following web page:

http://www.nigelhewitt.co.uk/diving/rant/#gills

Quote (following an explanation of the quantity of oxygen in solution in sea water at depth, vs. quantities required to breath, yielding a requirement of 2000L/minute of water to be processed):

"This raises three problems in my mind.

"Firstly is size. If the magic box is a reasonable size, say a volume of working water is the size of my scuba tank it will have 12L of water to work on at any one moment. So 2000L/minute means that the water must be in, processed and out in 12*60/2000 seconds. That's just over one third of a second to complete the whole process.

"Secondly there is the fact that 2000L/minute worries me when I consider that my old 20HP outboard had an 20cm diameter prop on it. To move 2000L/minute it would have to knock the water through at 2000/31.4=63m/s, otherwise 142mph in old numbers. So my second problem is that this is a huge amount of thrust for a diver who does not wish to zoom about like a torpedo and the third problem is that that sort of power isn't going to come from ordinary batteries."

Personally, I read the article as a typical design student 'concept' piece; certainly, if I were a battery manufacturer that had a product 30x more energy dense than the competition, which charged 1000x faster, I would not be looking at the scuba market to make my billions.

Seems a somewhat low barrier for entry, if a 'design concept' consists of putting an action button on a notification.

I'm with you on the type checking (although this particular library doesn't seem to offer much in that space). That said, I'd argue that modern tooling (e.g. IDEA, and by association the static analysis toolchain in Teamcity) are capable of identifying and validating embedded SQL, particularly when provided with database metadata.

Essentially, I'm deeply uneasy about embedding translators from one language into another. As an example, not many people like using BigDecimal to describe arithmetic operations, despite it having a fluent syntax and improved type safety (e.g. around implicit conversions) compared to just writing an expression.

I don't like this. I'm strongly of the opinion that SQL is a beautiful language, able to express in terse yet readable statements operations which would take many pages of Java to execute. Why try and wrap it up, and pretend that you are writing Java, when you're still writing SQL?

Please don't take this as a dig at you or your code - everyone has an itch to scratch, and I'm quite sure writing this was fun.

I want to test this product, and I'm in a position where I could spend real money on a purchase or subscription to this service in the event that it does what we need.

Unfortunately, as soon as I see that data is sent off-site, I immediately discard this as a product which my organisation can use.

Reasons

1. I am an engineer, working in a highly regulated environment. Regulated environments excel at buying things, or subscribing to things - we have whole teams of people that are delighted to spend money on our behalf. They also tend to have immense amounts of process overhead, whenever you interact with third parties on subjects relating to intellectual property or the confidentiality of client data.

Your assurances on encryption, confidentiality, etc. are irrelevant to me; you could have invented a perfect cryptosystem, but regulations would still prohibit me from exporting data outside of our organisation.

2. I don't want to build reliance on something which is outside of my control. This might be the greatest tool ever built, but if I'm building monitoring systems for production systems, I need to have confidence that they are available, irrespective of your schedule for upgrading / supporting / maintaining your product.

Why should a tool fail, just because the people that built the tool are no longer around?

Short takeaway - my suggestion is that you consider those of us who are not fortunate enough to work in unregulated industries, and produce a self-hosted version of your application (as GitHub do) which can be run on our own infrastructure. There's revenue there which is being ignored. You might feel that centralising your service means that crackers can't steal your tool and use it for free. I would argue that the people that actually care about running this locally are the sort of people that will be paying you, handsomely, for it.

As a fairly experienced Java developer, I don't agree with this article. It reads more like a desperate fantasy, than a reasoned argument.

The rapidity with which you can get started with other languages and frameworks has very little to do with the runtime performance, and a lot more to do with language flexibility and the 'sweet spot' which frameworks choose to occupy. I don't think Java is a bad language, but there's problems which I would not choose to solve in it.

The looming presence of Java 8 is likely to catalyze a new set of libraries, as people adjust to writing with lambdas, and the new power provided by the expanded type system and runtime. I'm anticipating a tsunami of lambda enabled crap, and some gems of design to emerge glistening from the initial torrent.

I don't think this will dramatically alter people's perceptions of Java as a language for rapid web development, though.